Je travaillais sur un répertoire nommé bin
. Une fois que j'ai eu terminé, à cause de la propriété de bin
et 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 /bin
ré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.
command-line
restore
Ravexina
la source
la source
/bin
Ubuntu, n’est-ce pas simplement un lien symbolique vers/usr/bin
ces jours-ci? Donc, tout ce que vous devez faire est de rétablir le lien symbolique?/bin
n'est pas un lien symbolique à/usr/bin
ici, je pense que ce serait contre leFHS
. aussi si nous vérifions un paquet trivial commecoreutils
danszesty
(ici) . nous pouvons voir que beaucoup de choses vont être installées à/bin
côté du/usr/bin
, mais ça peut quand même être un lien, je ne le sais pas./bin
, j'ai envisagé quelque chose qui pourrait arriver à quelqu'un d'autre (d'après une autre question à laquelle j'ai répondu), puis j'ai écrit une instruction pour partager mes connaissances avec les autres :), bien que j'apprécie tous les commentaires, ils sont également utiles aux autres personnes qui viennent lire cette question. Merci à tous;)Réponses:
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
/bin
le 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
chroot
inté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/bin
ré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/bin
utilisant:Et nous pouvons aussi utiliser:
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
/bin
avec quelque chose comme: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:
Montez votre
root
système de fichiers (pour moi c'est/dev/sda1
):Nous aurons besoin d'une connectivité à Internet, alors copiez
resolv.conf
depuis Ubuntu en direct sur votre partition racine montée:Maintenant, copiez le script quelque part sur la partition montée, par exemple:
ou vous pouvez le télécharger en utilisant
wget
, etc. comme:Montez les autres chemins nécessaires:
Et voici la différence mineure : comment pouvons-nous
chroot
créer un système défectueux alors qu’il n’ya pas de/bin
répertoire dans ce répertoire? Quel shell devrions-nous exécuter?Créez donc un répertoire bin temporaire. Exemple: nommé
bintmp
dans la racine de votre système endommagé:Ensuite, liez le live
/bin
dans ça:Chroot dans le système en définissant le
/bintmp/bash
comme shell de connexion:Exportez la
/bintmp
commePATH
variable d’environnement:Donnez au script le bit exécutable:
Exécutez le script:
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+ Dpour sortir de l’
chroot
environnement et démonter les chemins montés:Redémarrez le système.
Restaurer les liens au sein
/bin
Maintenant, presque tous les fichiers du
/bin
répertoire sont de retour, sauf environ 5 liens symboliques gérés parupdate-alternatives
.Dans votre système en cours d'exécution, exécutez:
Il te pose quelques questions; vous pouvez simplement appuyer ENTERpour les accepter tous.
Et maintenant nous avons fini.
la source
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
./bin
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 depuis
sudo
lors/usr/bin
, obtenons-nous un shell racine en cours d’exécution avant d’endommager davantage. Mais/bin/bash
et la plupart des autres coquilles ont disparu! Heureusement, Linux a toujours une copie en mémoire du shell que vous utilisez. Alors:À proprement parler, nous n’avons pas besoin d’un shell root pour la majeure partie de ce qui suit. Mais peu importe.
Maintenant,
dpkg
fonctionne toujours, au moins pour trouver quels paquets ont des fichiers dans/bin
:Nous pouvons utiliser
awk
pour le traiter et obtenir les noms de paquets, etxargs
etapt-get
pour télécharger les paquets (tous entrés/usr/bin
). Si vous avez un répertoire temporaire que vous pouvez utiliser,cd
là - bas, car votre répertoire actuel va devenir un peu brouillon:Maintenant, le plus gros problème que nous ayons, c'est qu'il
/bin/tar
manque, et sans cela,dpkg
nous ne pouvons pas extraire les archives. Nous pouvons obtenir les deux tiers du chemin, car:.deb
les fichiers sont en fait desar
archives (encore une fois dans/usr/bin
):Constitué de deux
.tar.*
archivesdata
etcontrol
:Pendant que les utilitaires gzip sont dans
/bin
,unxz
c'est dans/usr/bin
:Nous avons maintenant un
data.tar
fichier sanstar
en extrairetar
.Python à la rescousse ! C'est là
sudo
qu'il faut vraiment:Nous pouvons maintenant utiliser
dpkg
pour extraire les fichiers deb restants pour obtenir un résultat raisonnablement complet/bin
: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:
Ou:
Remarques:
Nous ne pouvons pas utiliser Python 2 pour extraire directement le
data.tar.xz
fichier, 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 sansunxz
:/bin/tar
, vous devez encore extraire certains des fichiers deb avant de pouvoir les utiliserapt-get
: les shells, les coreutils, etc. Il est plus facile de simplement les extraire tous et de les réinstaller ultérieurement.la source
/usr/bin
, j'ai dit tout ce que je vais avec chroot ... Génial./proc/$$/exe
un lien/bin/bash
? comment ça marche quand/bin
est enlevé? (Cela fonctionne, mais comment), j'ai pensé que ce devrait être un lien brisé ... c'est pourquoi j'ai abandonné cette idée.Vous pouvez placer temporairement des fichiers d'un CD live ou d'un autre système dans votre ordinateur
/bin
pour les rendre utilisables, puis les remplacer par des fichiers de votre installation Ubuntu en exécutantapt-get install --reinstall
des paquetages contenant des éléments/bin
.la source
Quelques ajouts à cette excellente réponse , après avoir rencontré ce problème (avec la suppression
/boot
,/etc
,/lib
et/lib64
):chroot
exige/lib
et/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
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 .apt install --reinstall <package>
c’est un excellent moyen de restaurer les fichiers manquants/bin
,/lib
et/lib64
.libaio1
,mysql-server
,openvpn
,vsftpd
Note to self:
rm -rf folder /*
n'est pas la même chose querm -rf folder/*
la source