Apt-get bloqué à 0% [Fonctionnement]

Lorsque j'essaie de faire quoi que ce soit avec l' apt-getutilisation d'un terminal, le apt-getreste bloqué 0% [Working].

Je suis arrivé sur cette page via une recherche Google de haut niveau, mais ces réponses ne m'ont pas aidé. Au lieu de cela, j'ai vidé mon référentiel local des fichiers de package récupérés avec:

apt-get clean

Vous pouvez essayer de vérifier le cache et de nettoyer le répertoire du cache.
Dans l'ordre (chaque étape est plus profonde, alors arrêtez-vous lorsque vous trouvez une solution):

• sudo apt-get clean( Mettre à jour ) sur les versions récentes, il effacera le référentiel local des fichiers de package récupérés. Ce sera suffisant la plupart du temps. Ce n'est (n'était) pas le cas dans les versions antérieures.

  Il supprime tout sauf le fichier de verrouillage de / var / cache / apt / archives / et / var / cache / apt / archives / partial /.

• Regardez à l'intérieur, /var/lib/apt/lists/partial/il doit être vide.
  Sinon, vous pouvez décider de le vider sudo rm /var/lib/apt/lists/partial/*éventuellement, vous devrez peut-êtresudo rm -f /var/lib/apt/lists/partial/*

• sudo apt-get check

  il met à jour le cache du package et vérifie les dépendances cassées.

• Réduisez à un nombre normal (pas énorme) de référentiels la liste de /etc/apt/sources.list.
  S'ils sont trop nombreux, votre système peut se bloquer dans la tentative de génération de l'arborescence des dépendances.
  Vous pouvez créer un ensemble minimal de référentiels à partir du site Ubuntu Sources List Generator et après cela vous sauvegardez le /etc/apt/sources.list(avec par exemple sudo cp -i /etc/apt/sources.list /etc/apt/sources.list.000) vous pouvez le coller au lieu de votre liste actuelle.

• vous pouvez éventuellement vérifier si vous avez un fichier de listes source avec https plutôt qu'avec http, mais qu'il apt-transport-httpsn'est pas installé (voir le commentaire ).
• réessayez sudo apt-get updateet en cas d'échec
• sauvegarder votre /var/lib/apt/listsrépertoire avec sudo cp -r -p -i /var/lib/apt/lists ${HOME}/temp_apt_listset aprèssudo rm -R /var/lib/apt/lists/*
• courir à sudo apt-get updatenouveau

Il est possible que vous deviez nettoyer à la main certains des répertoires suivants (vous pouvez toujours les sauvegarder et seulement après avoir supprimé les fichiers à l'intérieur):

• /etc/apt/sources.list.d/
  Fragments de fichier pour les emplacements où récupérer les packages. Élément de configuration: Dir :: Etc :: SourceParts.
• etc / apt / preferences.d /
  Fragments de fichier pour les préférences de version. Élément de configuration: Dir :: Etc :: PreferencesParts.
• / var / cache / apt / archives / partial /
  Zone de stockage pour les fichiers de package en transit. Élément de configuration: Dir :: Cache :: Archives (une partie sera implicitement ajoutée)
• / var / lib / apt / lists / partial / Zone de stockage des informations d'état en transit. Élément de configuration: Dir :: State :: Lists (une partie sera implicitement ajoutée)
• / var / lib / apt / lists / Zone de stockage des informations d'état pour chaque ressource de package spécifiée dans sources.list (5) Élément de configuration: Dir :: State :: Lists.

PS> Si vous avez réussi, pensez à supprimer la copie de sauvegarde dont vous n'avez plus besoin, mais ce n'est pas sources.list.000toujours le cas!
Vous pouvez trouver des conseils supplémentaires dans la réponse associée comme celle-ci .

Mise à jour
Il y avait un vieux bug parce que le paquet squid-deb-proxy-client ne nettoie pas toutes ses modifications, résolu ainsi:

Suppression de la ligne:
Acquire :: http :: ProxyAutoDetect "/ usr / share / squid-deb-proxy-client / apt-avahi-Discover";

de:
/etc/apt/apt.conf.d/30autoproxy

Peut-être peut être utile ce fil de bogue

Plus drastique, retirez le paquet si cela est possible.

J'ai également constaté que cela m'arrivait lorsque je suis passé à un référentiel https. apt doit apt-transport-httpsêtre installé pour fonctionner (ce qui peut naturellement être un problème lorsque vous essayez de télécharger des trucs).

Assurez-vous que vous pouvez envoyer une requête ping depuis votre propre réseau et, plus important encore, vers le réseau Ubuntu, c'est-à-dire

 ping us.archive.ubuntu.com
 OR
 ping security.ubuntu.com

Vous devriez obtenir une sortie similaire à:

 PING security.ubuntu.com (91.189.88.161) 56(84) bytes of data.
 64 bytes from keeton.canonical.com (91.189.88.161): icmp_seq=1 ttl=52 time=127 ms
 64 bytes from keeton.canonical.com (91.189.88.161): icmp_seq=2 ttl=52 time=128 ms

  --- security.ubuntu.com ping statistics ---
  2 packets transmitted, 2 received, 0% packet loss, time 1000ms
  rtt min/avg/max/mdev = 127.325/127.952/128.579/0.627 ms

essayez d'abord de le mettre à jour en

aptitude update

puis exécutez apt-get

ou devrais changer votre miroir pour le plus proche de chez vous, regardez ceci - Comment puis-je être capable d'utiliser un miroir près de moi, ou choisir un miroir plus rapide?

Cela peut également être dû au fait d'être derrière un proxy qui bloque l'accès. Parfois, j'ai une erreur NODATA ... parfois, elle est restée 0% [Working...].

si vous avez changé d'emplacement, changez également votre serveur de téléchargement:

sudo software-properties-gtk

cliquez sur autre puis sélectionnez le meilleur serveur:

après cela, sélectionnez et supprimez tous les autres référentiels logiciels:

enfin:

sudo apt-get update
sudo apt-get upgrade

Vérifiez si votre réseau est accessible ou non. Dans mon cas, j'ai réinstallé mon Raspiberry-Pi. J'ai vérifié la date et l'heure de mon RPi, il n'a pas été mis à jour. J'ai donc changé la date manuellement,

sudo date -s "2019 Mar 20 02:42"

Et redémarrez. Maintenant, mon RPi fonctionne bien.

Dans debian 9, mon apt était bloqué à 0% [de travail] pendant un certain temps avant d'effectuer une tâche nécessitant un accès à Internet. Après avoir essayé de nombreuses autres méthodes, lorsque j'ai désactivé le gestionnaire de réseau et commencé à utiliser systemd-networkd à la place, ce problème a finalement été résolu.

Une réponse que je n'ai trouvée nulle part sur Internet mais que je l'ai trouvée sur la base d'une commande que j'ai exécutée il y a quelques heures. Un exemple d'une telle commande est

echo "deb http://dl.bintray.com/tproenca/pmsarm7 jessie main" | sudo tee /etc/apt/sources.list.d/pms.list

Après quoi un fichier est ajouté à /etc/apt/sources.list.d/. Dans ce répertoire, des sources pourraient également être ajoutées. Dans mon cas, c'était Teamviewer qui contenait sa propre liste qui avait une URL non valide. Par conséquent, ma mise à jour a échoué. Ce sont les commandes que j'ai exécutées.

Remarque: teamviewer.list m'a causé des problèmes mais cela peut être n'importe quoi pour vous dans ce répertoire. Essayez-le et faites des sauvegardes!)

cd /etc/apt/
cp sources.list.d/* sources.list.d.backup/
rm sources.list.d/teamviewer.list
apt-get clean
apt-get check
apt-get update

J'espère que cela sauve quelqu'un des heures que cela aurait pu me sauver!

J'ai le même problème, mais je l'ai résolu comme ceci:

sudo systemctl restart networking

j'espère que cela peut aider.

Ce problème peut également être dû à un système de fichiers en lecture seule .

Vous pouvez vérifier cela en utilisant la commande suivante:

mount | grep "on / "

Si la sortie contient l' roun des indicateurs de montage, votre système de fichiers racine est en mode lecture seule. Vous devrez remonter votre système de fichiers en lecture-écriture avant de apt-get updatecontinuer.

Ressources sur la façon de remonter votre système de fichiers:

• https://linux.die.net/man/8/mount
• Comment remonter un système de fichiers en lecture / écriture?

L'installation d' apt-transport-https m'a aidé sur la nouvelle Debian 9.

sudo apt-get install apt-transport-https