Supprimé accidentellement / bin. Comment puis-je le restaurer?

Je travaillais sur un répertoire nommé bin. Une fois que j'ai eu terminé, à cause de la propriété de binet de certains fichiers, j'ai accidentellement couru:

sudo rm -r /bin

Au lieu de:

sudo rm -r bin

Il semble que mes mains ajoutaient un /devant tout ce que je tape.

Comment puis-je restaurer mon /binrépertoire?

Je veux les mêmes fichiers qui appartiennent à mon Ubuntu, je n'aime pas les copier et les coller à partir d'un disque live ou d'un autre système en cours d'exécution.

C'est possible?

Eh bien, la plupart des utilitaires les plus triviaux et les plus importants sont installés /bin, et vous avez maintenant perdu l’accès à tous. En fait, si vous redémarrez, votre système ne pourra plus démarrer.

Quoi qu'il en soit, nous allons résoudre le problème et rendre /binle contenu aussi proche que possible de l'endroit où il se trouvait. La seule différence serait des liens symboliques que nous corrigerons également.

Comment?

Tout d’abord, nous devrions chrootintégrer votre système défectueux, mais avec une différence mineure ! Après cela, nous obtiendrons une liste des packages installés sur votre système contenant un fichier dans le /binrépertoire, puis nous ne téléchargerons que les packages nécessaires et en extrairons les fichiers nécessaires /bin. Ensuite, nous aurons fini.

Par exemple, après chroot, nous pouvons obtenir une liste des paquets qui ont des fichiers installés en /binutilisant:

dpkg --search /bin | cut -f1 -d: | tr ',' '\n'

Et nous pouvons aussi utiliser:

dpkg --listfiles PACKAGE-NAME | grep "^/bin/" # or awk '$0 ~ "^/bin/

pour lister les fichiers installés par ces paquets dans /bin.

Ensuite, nous créons simplement une liste de tous les packages nécessaires, puis nous les téléchargeons et les extrayons /binavec quelque chose comme:

xargs apt download < list-packages
dpkg-deb -x PACKAGE .
mv ./bin/* /bin

Cependant, nous devons utiliser un script pour vérifier tous les packages installés sur notre système, car le faire manuellement est une folie.

J'ai donc écrit un script qui fait tout ce dont nous avons besoin. Il trouve tous les packages nécessaires à restaurer /bin, nous indique le nom de chaque package et les fichiers associés auxquels il appartient /bin. Voici une capture d'écran:

À la fin, nous choisissons de réinstaller tous les packages ou seulement de télécharger et d'extraire les fichiers nécessaires dans /bin(ce qui est l'option recommandée):

Vous pouvez récupérer une copie de ce script ou le télécharger directement .

Commençons

chroot

Démarrez votre système avec un disque live ayant la même architecture que votre Ubuntu installé, ouvrez un terminal et obtenez un accès root:

sudo -i

Montez votre rootsystème de fichiers (pour moi c'est /dev/sda1):

mount /dev/sda1 /mnt

Nous aurons besoin d'une connectivité à Internet, alors copiez resolv.confdepuis Ubuntu en direct sur votre partition racine montée:

cp /etc/resolv.conf /mnt/etc/resolv.conf

Maintenant, copiez le script quelque part sur la partition montée, par exemple:

cp /media/ubuntu/usb/restore-bin.sh /mnt/restore-bin.sh

ou vous pouvez le télécharger en utilisant wget, etc. comme:

wget https://git.io/v9fRm -O /mnt/restore-bin.sh

Montez les autres chemins nécessaires:

mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount -t proc /proc /mnt/proc

Et voici la différence mineure : comment pouvons-nous chrootcréer un système défectueux alors qu’il n’ya pas de /binrépertoire dans ce répertoire? Quel shell devrions-nous exécuter?

Créez donc un répertoire bin temporaire. Exemple: nommé bintmpdans la racine de votre système endommagé:

mkdir /mnt/bintmp

Ensuite, liez le live /bindans ça:

mount --bind /bin /mnt/bintmp

Chroot dans le système en définissant le /bintmp/bashcomme shell de connexion:

chroot /mnt /bintmp/bash

Exportez la /bintmpcomme PATHvariable d’environnement:

export PATH=/bintmp:$PATH

Donnez au script le bit exécutable:

chmod +x restore-bin.sh

Exécutez le script:

./restore-bin.sh

Attendez que la recherche soit terminée, puis répondez à la question que nous avons vue dans la capture d'écran. Il va commencer à restaurer le /binet nous avons presque fini.

Ensuite, utilisez CTRL+ Dpour sortir de l’ chrootenvironnement et démonter les chemins montés:

umount -R /mnt

Redémarrez le système.

Restaurer les liens au sein /bin

Maintenant, presque tous les fichiers du /binrépertoire sont de retour, sauf environ 5 liens symboliques gérés par update-alternatives.

Dans votre système en cours d'exécution, exécutez:

sudo update-alternatives --all

Il te pose quelques questions; vous pouvez simplement appuyer ENTERpour les accepter tous.

Et maintenant nous avons fini.

Si votre système actuel a toujours un shell et un accès Internet en cours d'exécution, vous pouvez le faire à l'aide d'outils existants ailleurs sur le système. Je suppose que vous avez seulement supprimé /bin. /binbien sûr, l'utilitaire le plus pratique que vous puissiez utiliser dans une telle situation (busybox), mais sans cela, nous devrons faire preuve d'un peu de créativité.

Puisque vous avez déjà un shell en cours d’exécution, et depuis sudolors /usr/bin, obtenons-nous un shell racine en cours d’exécution avant d’endommager davantage. Mais /bin/bashet la plupart des autres coquilles ont disparu! Heureusement, Linux a toujours une copie en mémoire du shell que vous utilisez. Alors:

sudo /proc/$$/exe

À proprement parler, nous n’avons pas besoin d’un shell root pour la majeure partie de ce qui suit. Mais peu importe.

Maintenant, dpkgfonctionne toujours, au moins pour trouver quels paquets ont des fichiers dans /bin:

dpkg -S /bin

Nous pouvons utiliser awkpour le traiter et obtenir les noms de paquets, et xargset apt-getpour télécharger les paquets (tous entrés /usr/bin). Si vous avez un répertoire temporaire que vous pouvez utiliser, cdlà - bas, car votre répertoire actuel va devenir un peu brouillon:

dpkg -S /bin | awk -F '[, :]' '{NF--}1' | xargs apt-get download

Maintenant, le plus gros problème que nous ayons, c'est qu'il /bin/tarmanque, et sans cela, dpkgnous ne pouvons pas extraire les archives. Nous pouvons obtenir les deux tiers du chemin, car:

1. .debles fichiers sont en fait des ararchives (encore une fois dans /usr/bin):

   ar x tar_*.deb
   

2. Constitué de deux .tar.*archives dataet control:

   $ echo *.tar.*
   control.tar.gz data.tar.xz
   

3. Pendant que les utilitaires gzip sont dans /bin, unxzc'est dans /usr/bin:

   unxz data.tar.xz
   

Nous avons maintenant un data.tarfichier sans taren extraire tar.

Python à la rescousse ! C'est là sudoqu'il faut vraiment:

$ sudo python -c 'import tarfile; tarfile.open("data.tar").extractall("/")'
$ echo /bin/*
/bin/tar

Nous pouvons maintenant utiliser dpkgpour extraire les fichiers deb restants pour obtenir un résultat raisonnablement complet /bin:

for i in *.deb; do dpkg-deb -x "$i" /; done

Cependant, nous devons toujours faire une installation correcte des fichiers deb, afin que les liens symboliques, etc., créés par les paquetages soient recréés:

sudo apt install --reinstall ./*.deb

Ou:

sudo dpkg -i *.deb
sudo apt-get install -f

Remarques:

1. Nous ne pouvons pas utiliser Python 2 pour extraire directement le data.tar.xzfichier, car Python 2 ne prend en charge que la compression gzip et bzip2. Python 3, cependant, le supporte, vous pouvez donc utiliser directement Python 3 sans unxz:

   sudo python3 -c 'import tarfile; tarfile.open("data.tar.xz").extractall("/")'
   

2. Après le retour /bin/tar, vous devez encore extraire certains des fichiers deb avant de pouvoir les utiliser apt-get: les shells, les coreutils, etc. Il est plus facile de simplement les extraire tous et de les réinstaller ultérieurement.

Vous pouvez placer temporairement des fichiers d'un CD live ou d'un autre système dans votre ordinateur /binpour les rendre utilisables, puis les remplacer par des fichiers de votre installation Ubuntu en exécutant apt-get install --reinstalldes paquetages contenant des éléments /bin.

Quelques ajouts à cette excellente réponse , après avoir rencontré ce problème (avec la suppression /boot, /etc, /libet /lib64):

• chrootexige /libet /lib64être présent; sinon, vous obtiendrez le message d'erreur suivant:
  failed to run command ‘/bin/bash’: No such file or directory
  je les ai copiées à partir du système d'exploitation LiveCD et je n'ai rencontré aucun problème de restauration. YMMV en fonction des packages que vous avez installés sur le système
• Je ne peux pas éditer la réponse mentionnée ci-dessus, mais il y a une faute de frappe:
  cp /etc/resolv.conf /mnt/etc/resolv.cof
  devrait être
  cp /etc/resolv.conf /mnt/etc/resolv.conf
• /bootpeut facilement être restauré à l'aide des outils grub. Voir ici .
• Comme le recommande cette réponse , apt install --reinstall <package>c’est un excellent moyen de restaurer les fichiers manquants /bin, /libet /lib64.
  • Certains paquets nécessaire en raison de : libaio1, mysql-server, openvpn,vsftpd

Note to self:
rm -rf folder /*n'est pas la même chose querm -rf folder/*