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

Est-ce possible?

Eh bien, la plupart des utilitaires triviaux et importants sont installés dans /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 le contenu de /bin aussi proche que possible de celui où il se trouvait. La seule différence serait des liens symboliques que nous corrigerons aussi.

Comment?

Premièrement, nous devrions chroot dans votre système endommagé, mais avec une différence mineure ! Après cela, nous obtiendrons une liste des paquetages installés sur votre système contenant un fichier installé dans le répertoire /bin . Nous allons seulement télécharger les paquetages nécessaires et extraire les fichiers nécessaires dans /bin . Ensuite, nous aurons fini.

Par exemple, après chroot , nous pouvons obtenir la liste des paquetages contenant des fichiers installés dans /bin en utilisant:

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

Et nous pouvons aussi utiliser:

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

pour répertorier les fichiers installés par ces packages dans /bin .

Ensuite, nous créons simplement une liste de tous les paquetages nécessaires, puis nous les téléchargeons et les extrayons dans /bin avec 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 à la restauration de /bin , nous indique le nom de chaque package et leurs fichiers associés appartenant à /bin . Voici une capture d'écran:

Àlafin,nousavonschoisideréinstallertouslespaquetagesouseulementdetéléchargeretd'extrairelesfichiersnécessairesdans/bin(cequiestl'optionrecommandée):

Vouspouvezrécupérer une copie de ce script ou téléchargez-le directement .

Permet de commencer

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 système de fichiers root (pour moi c’est /dev/sda1 ):

mount /dev/sda1 /mnt

Nous aurons besoin de la connectivité à Internet. Copiez donc resolv.conf de Ubuntu en direct sur votre partition racine montée:

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

Copiez maintenant 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 chroot accéder à un système en panne alors qu'il n'y a pas de répertoire /bin dans ce répertoire? Quel shell devrions-nous exécuter?

Créez donc un répertoire bin temporaire. par exemple: nommé bintmp dans la racine de votre système endommagé:

mkdir /mnt/bintmp

Liez ensuite le live /bin à celui-ci:

mount --bind /bin /mnt/bintmp

Connectez-vous au système en définissant /bintmp/bash comme shell de connexion:

chroot /mnt /bintmp/bash

Exportez le /bintmp en tant que variable d’environnement PATH :

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 /bin et nous avons presque fini.

Ensuite, utilisez CTRL + D pour sortir de l'environnement chroot et démonter les chemins montés:

umount -R /mnt

Redémarrez le système.

Restauration des liens dans /bin

Maintenant, presque tous les fichiers du répertoire /bin 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 vous pose quelques questions. vous pouvez simplement appuyer sur ENTER pour les accepter tous.

Et maintenant nous avons fini.

Si votre système actuel possède toujours un shell et un accès Internet en cours d'utilisation, vous pouvez le faire à l'aide d'outils existant ailleurs sur le système. Je suppose que vous n’avez supprimé que /bin . /bin a bien 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 que sudo est dans /usr/bin , obtenons nous-mêmes un shell root en cours d'exécution avant de causer d'autres dommages. Mais /bin/bash et la plupart des autres obus ont disparu! Heureusement, Linux a toujours une copie en mémoire du shell que vous utilisez. Donc:

sudo /proc/$$/exe

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

Maintenant, dpkg fonctionne toujours, au moins pour rechercher les paquetages contenant des fichiers dans /bin :

dpkg -S /bin

Nous pouvons utiliser awk pour le traiter et obtenir les noms des paquetages, et xargs et apt-get pour télécharger les packages (tous dans /usr/bin ). Si vous avez un répertoire temporaire que vous pouvez utiliser, cd ici, 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 avons est que /bin/tar est manquant et sans cela, dpkg ne peut pas extraire les archives. Nous pouvons obtenir les deux tiers du chemin, car:

1. Les fichiers .deb sont en réalité ar archives (encore une fois dans /usr/bin ):

   ar x tar_*.deb
   

2. Composé de deux .tar.* archives, data et control :

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

3. Alors que les utilitaires gzip sont dans /bin , unxz est dans /usr/bin :

   unxz data.tar.xz
   

Nous avons maintenant un fichier data.tar sans tar pour en extraire tar .

Python à la rescousse ! C’est là que sudo est vraiment nécessaire:

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

Maintenant , nous pouvons utiliser dpkg pour extraire les fichiers deb restants afin d'obtenir un /bin raisonnablement complet:

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., qui seraient créés par les paquetages soient recréés:

sudo apt install --reinstall ./*.deb

Ou:

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

Notes:

1. Nous ne pouvons pas utiliser Python 2 pour extraire directement le fichier data.tar.xz , 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 avoir récupéré /bin/tar , vous devez encore extraire certains fichiers deb avant de pouvoir utiliser apt-get : les shells, coreutils, etc. Il est plus facile d'extraire tous ces fichiers et de les réinstaller ultérieurement.

Vous pouvez temporairement mettre des fichiers d'un CD live ou d'un autre système dans votre /bin pour le rendre utilisable, puis les remplacer par des fichiers de votre installation Ubuntu en exécutant apt-get install --reinstall pour les paquets avoir des choses dans /bin .

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

• chroot requiert que /lib et /lib64 soient présents; sinon, vous obtiendrez l'erreur suivante:
  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 référencé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
• /boot peut facilement être restauré à l'aide des outils grub. Voir ici .
• Comme cette réponse est recommandée, apt install --reinstall <package> est un excellent moyen de restaurer les fichiers manquants dans /bin , /lib et /lib64 .
  • Certains packages nécessitant une réinstallation: libaio1 , mysql-server , openvpn , vsftpd

Note personnelle: rm -rf folder /* n'est pas identique à rm -rf folder/*