Après avoir renommé accidentellement / usr, comment puis-je le renommer?

62

J'ai accidentellement renommé le répertoire /usren /usr_bak.

Je veux changer le dos, donc j'ajouter le chemin /usr_bak/binà $PATHpermettre au système de trouver la commande sudo.

Mais maintenant sudo mv /usr_bak /usrme donne l'erreur:

sudo: error while loading shared libraries: libsudo_util.so.0: cannot open shared object file: No such file or directory

Existe-t-il un moyen de renommer l’ /usr_bakas en /usrplus de la réinstallation du système?

Yves
la source
2
De quel OS s'agit-il? Je me demande comment, sudomême au stade de la bibliothèque, il est généralement entré /usr/bin/et aurait dû échouer avec une erreur de commande introuvable. Aussi, avez-vous un mot de passe root défini?
Muru
3
@muru, c'est Ubuntu. Vous avez raison, j'ai déjà eu l'erreur not foundauparavant alors j'ai ajouté le nouveau chemin /usr_bak/bind' accès $PATHet maintenant j'ai l'erreur dans mon message ici ...
Yves
2
@ user1717828 c'est compliqué. Je dois compiler un projet, développé sous Ubuntu 16.04, sous Ubuntu 17.10. Je pense donc que si je pouvais simplement copier celui /usrd'Ubuntu 16.04 pour écraser celui /usrd'Ubuntu 17.10 ...
Yves
6
Avez-vous envisagé d'utiliser un ordinateur virtuel pour compiler le projet au lieu de changements aussi radicaux?
Kevin
3
Vous pouvez exécuter virtualbox en mode sans tête . Il peut être plus simple de configurer un invité sur un autre ordinateur ou d’en obtenir un préconfiguré.
Kevin

Réponses:

109

Puisque vous avez défini un mot de passe pour root, utilisez suet busybox, installé par défaut dans Ubuntu. Toutes sules bibliothèques requises sont en /lib. Busybox est un ensemble d’utilitaires liés statiquement. Les bibliothèques manquantes ne devraient donc pas poser de problèmes. Faire:

su -c '/bin/busybox mv /usr_bak /usr'

(Bien que Busybox ait également une suapplet, le /bin/busyboxbinaire n'est pas setuid et ne fonctionne donc que s'il est exécuté en tant que root.)

Si vous n'avez pas de mot de passe root, vous pouvez probablement utiliser la solution de Gilles ici en utilisantLD_LIBRARY_PATH , ou (Gilles dit que cela ne fonctionnera pas avec les binaires setuid comme Sudo), redémarrez et éditez le menu GRUB avec lequel démarrer init=/bin/busyboxcomme paramètre du noyau et déplacez-le. le dossier en arrière.

muru
la source
73
Maintenant, ne pas renommer accidentellement /lib.
sleblanc
5
LD_LIBRARY_PATHne serait pas utile pour exécuter sudo puisque sudoest setuid. Si ses bibliothèques ne sont pas au bon endroit, sudo ne fonctionnera pas tant que root ne l’aura pas réparé.
Gilles, arrête de faire le mal. »
3
@Yves note historique: vieilles versions d'Unix (qui sont beaucoup plus vieux que Linux) inclus une petite collection de fichiers binaires liés statiquement dans /sbinprécisément ce genre de scénario: « Je fais une activité où les bibliothèques d'exécution seront jonglé autour mais besoin de toujours manipuler des fichiers ". Fondamentalement, la même approche avant Busybox a été inventée. (Le nombre de commandes disponibles de cette façon était très limité, car ces binaires liés de manière statique engloutissent l'espace disque.)
Ti Strga
8
@Yves Si vous avez renommé /lib, alors vous devrez probablement redémarrerinit=/bin/busybox
muru
3
@Yves: Démarrez à partir d'une clé USB, avec une distribution en direct pouvant monter vos systèmes de fichiers, et vous êtes prêt à tout réparer. Même en téléchargeant des fichiers de remplacement à partir de miroirs de packages si vous supprimez quelque chose.
Peter Cordes
33

En plus de la réponse de muru :

  • vous auriez pu utiliser une clé USB de secours pour réparer votre système; Par exemple, si votre système utilise une version de Debian ou Ubuntu, démarrez la clé USB d'installation en mode de secours et effectuez les opérations appropriées mountet mvet umount.

  • pour être en mesure de réparer plus facilement ces erreurs, j'installe généralement aussi une coquille statique avec plusieurs commandes internes (notamment avec certains cp, rm, mvbuiltins -comme), comme sash(il est emballé dans Debian et Ubuntu, et également disponible en châssis-3.8. tar.gz sous forme source) et bootez avec init=/bin/sashpassé à Grub.

PS: sashest légèrement buggé, et pas tout à fait conforme à Posix, mais reste très utile.

Basile Starynkevitch
la source
Pourriez-vous s'il vous plaît expliquer comment installer un shell statique avec plusieurs commandes intégrées? Y a-t-il un manuel?
Yves
1
Sur Debian ou Ubuntu: apt-get install sash. Mais vous pouvez aussi télécharger sash-3.8.tar.gz et le compiler.
Basile Starynkevitch
Je garde un live sur le disque dur avec une entrée personnalisée pour les problèmes de ce type. Pas besoin d'être compliqué, il suffit de démarrer un OS live et de manipuler des fichiers librement :)
FreeSoftwareServers
3

Je pense que le meilleur moyen de le faire est de redémarrer à l’aide d’un système d’exploitation démarré par USB, CD ou DVD (Debian, Ubuntu, Suse, etc.). Montez ensuite le lecteur contenant les problèmes et renommez-le.

Plus sûr que de démarrer dans un champ de mines sans / usr ou / lib.

Larry
la source
1
Vous pouvez démarrer une image ISO directement à partir de Grub / HDD sans avoir besoin d’USB / DVD, etc. Le truc assez astucieux de grub comporte une boucle d’appel.
FreeSoftwareServers
0

Je suis tombé sur un problème similaire où je retitré /usr/binà /usr/bin_bkpun certain test, puis je ne suis pas en mesure de renommer (comme la commande n'a pas trouvé le sudodans le répertoire standard qui est /usr/bin), puis je suis allé au /usr/bin_bkprépertoire manuellement ( en utilisant le gestionnaire de fichiers ) et la plupart des fonctions (y compris le changement de nom) du clic droit sont désactivées.

Puis j'ai essayé la commande suivante et cela a résolu le problème

$/usr/bin_bkp/sudo mv /usr/bin_bkp/ /usr/bin/

J'ai invoqué le sudo depuis le chemin actuel et cela a fonctionné, maintenant tout est revenu à la normale.

Système d'exploitation: Xubuntu 14.04

geek
la source
-3

Je ne peux pas essayer cela pour le moment (et je ne suis pas sûr de vouloir le faire), mais il semble que cela devrait fonctionner pour vous créer un nouveau "/ usr" en tant que lien dur (et non pas un lien en douceur) vers votre " / usr_bak, puis supprimez le "/ usr_bak"

ln /usr_bak /usr
rm /usr_bak

Le lien physique créé par "ln" ( sans l' argument "-s") dans le système de fichiers doit faire en sorte que les répertoires usr et usr_bak soient des liens également valides vers les répertoires en question. "rm" supprime simplement le lien que vous avez demandé de supprimer, pas les deux. Comme il existe toujours un lien valide vers le contenu, il doit rester accessible via le lien restant à "/ usr".

TED
la source
5
J'avais l'impression que Linux (ou au moins Ubuntu) n'autorisait pas les liens physiques vers des répertoires. Par exemple, askubuntu.com/questions/210741/…
Chris Bouchard
4
@Chris: D'accord, Linux n'autorise pas les liens physiques dans les répertoires (à l'exception de .et .., le nombre de liens sur un répertoire vous indique le nombre de sous-répertoires de premier niveau). En outre, rmne fonctionne pas sur les répertoires, vous devrez utiliser rmdir. ( lnet rmtravaillez sur des liens symboliques vers des répertoires, mais nous parlons d’un répertoire réel). En outre, cela ne résout pas le problème, car il nécessite rootsimplement mv, à cause des autorisations sur/ . Si vous pouviez exécuter ceci, vous pourriez courir à la mvplace comme une personne normale.
Peter Cordes
2
Les liens durs vers les répertoires ne sont pas pris en charge sur la plupart des Unices (tous?), Car il est trop difficile pour les logiciels effectuant une analyse récursive du système de fichiers de détecter des boucles infinies. Il est possible que le logiciel garde la trace de tous les inodes visités et qu'il analyse un système de fichiers compatible avec les inodes (c'est-à-dire non FAT32 / NTFS), mais il est beaucoup plus facile de rechercher des liens symboliques et de ne pas les parcourir. Un simple appel à lstat (2) suffit pour vérifier le type de fichier.
Penguin359
2
@Pryftan, ma ln(1)sur Debian dit ceci pour l' option -d/ -F/ --directory: "autoriser le superutilisateur à tenter de créer des liens physiques (note: cela va probablement échouer à cause des restrictions système, même pour le superutilisateur)" . Vous êtes donc libre d'essayer, mais votre système de fichiers ne vous le permettra probablement pas.
Toby Speight
1
@TobySpeight Autre pensée: voir aussi symlink (7) qui dit: Les liens physiques ne peuvent pas faire référence à des répertoires (pour éviter la possibilité de boucles dans l’arborescence du système de fichiers, ce qui risquerait d’embrouiller de nombreux programmes) et ne peut pas faire référence à des fichiers situés sur différents systèmes de fichiers (car les numéros d'inode ne sont pas uniques d'un système de fichiers à l'autre). Cela me fait penser que la tentative de lien dur pourrait en fait être le moyen de formuler quelque chose d'autre, à savoir que la fonction est appelée mais qu'elle échoue exactement car il s'agit d'un répertoire. (La référence au système de fichiers est ce à quoi je pensais dans un autre commentaire)
Pryftan