Dopo aver rinominato / usr accidentalmente, come posso rinominarlo?

62

Ho rinominato accidentalmente la directory /usrin /usr_bak.

Voglio cambiare di nuovo, così ho aggiungere il percorso /usr_bak/binper $PATHpermettere al sistema di trovare il comando sudo.

Ma ora sudo mv /usr_bak /usrmi dà l'errore:

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

C'è un modo per rinominare il /usr_bakcome /usr, oltre la reinstallazione del sistema?

— Yves
fonte

2

Quale sistema operativo è questo? Mi chiedo come sudosia arrivato allo stadio della libreria, di solito è /usr/bin/e avrebbe dovuto fallire con un errore di comando non trovato. Inoltre, hai impostato una password di root?

— muru

3

@muru È Ubuntu. Hai ragione, ho ricevuto l'errore circa not foundprima, quindi ho aggiunto il nuovo percorso /usr_bak/bina $PATHe ora ottengo l'errore nel mio post qui ...

— Yves

2

@ user1717828 è complicato. Devo compilare un progetto, sviluppato su Ubuntu 16.04, su Ubuntu 17.10. Quindi sto pensando se posso semplicemente copiare /usrUbuntu 16.04 per sovrascrivere /usrUbuntu 17.10 ...

— Yves

6

Hai mai pensato di utilizzare una macchina virtuale per compilare il progetto invece di tali cambiamenti drastici?

— Kevin,

3

Puoi eseguire virtualbox in modalità senza testa . Potrebbe essere più semplice impostare un guest su un altro computer o ottenerne uno preconfigurato.

— Kevin,

109

Dato che hai impostato una password per root, usa sue busybox, installato di default in Ubuntu. Sono presenti tutte sule librerie richieste /lib. Busybox è una raccolta di utility collegate staticamente, quindi le librerie mancanti non dovrebbero essere un problema. Fare:

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

(Mentre Busybox stesso ha anche suun'applet, il /bin/busyboxbinario non è setuid e quindi non funziona se non eseguito come root.)

Se non hai una password di root, ~~probabilmente potresti usare la soluzione di Gilles usando quiLD_LIBRARY_PATH , o~~ (Gilles dice che non funzionerà con binari setuid come sudo) riavviare e modificare il menu di GRUB con cui avviare init=/bin/busyboxcome parametro del kernel e spostare la cartella indietro.

— Muru
fonte

73

Ora, non rinominare accidentalmente /lib.

— slittino

5

LD_LIBRARY_PATHnon aiuterebbe a eseguire sudo poiché sudoè setuid. Se le sue librerie non sono nel posto giusto, sudo non funzionerà finché root non lo riparerà.

— Gilles 'SO- smetti di essere malvagio' il

3

Nota storica di @Yves: vecchie versioni di Unix (che sono molto più vecchie di Linux) includevano una piccola raccolta di file binari collegati staticamente /sbinproprio per quel tipo di scenario: "Sto facendo alcune attività in cui le librerie di runtime saranno giocoleria ma devi ancora manipolare i file ". Fondamentalmente lo stesso approccio prima dell'invenzione di Busybox. (Il numero di comandi disponibili in questo modo era molto limitato, perché quei binari collegati staticamente inghiottono spazio su disco.)

— Ti Strga

8

@Yves se hai rinominato /lib, probabilmente dovresti riavviareinit=/bin/busybox

— muru

3

@Yves: avvia da una chiavetta USB, con una distribuzione live che può montare i tuoi filesystem e sei pronto per riparare qualsiasi cosa. Anche scaricando i file sostitutivi dai mirror dei pacchetti se hai eliminato qualcosa.

— Peter Cordes,

33

Oltre alla risposta di Muru :

avresti potuto usare una chiave USB di avvio di ripristino per riparare il tuo sistema; ad esempio, se il tuo sistema è un po 'di Debian o Ubuntu, avvia la chiave USB di installazione in modalità di salvataggio e fai il comando appropriato mounte mve umount.
essere in grado di riparare più facilmente tali errori, io generalmente anche installare un guscio statico con diversi comandi incorporati (in particolare con alcune cp, rm, mvbuiltins -come) come sash(è confezionato in Debian e Ubuntu, ed anche disponibile come telaio-3.8. tar.gz in formato sorgente) e avvia con init=/bin/sashpassato a Grub.

^{PS: sashè leggermente difettoso e non completamente conforme a Posix, ma comunque molto utile.}

— Basile Starynkevitch
fonte

Potresti spiegare come installare una shell statica con diversi comandi integrati? C'è del manuale?

— Yves

1

Su Debian o Ubuntu: apt-get install sash. Ma puoi anche scaricare sash-3.8.tar.gz e compilarlo.

— Basile Starynkevitch

Tengo un liveiso sul disco fisso con una voce grub personalizzata per problemi come questo. Non c'è bisogno di complicarsi, basta avviare un sistema operativo dal vivo e manipolare i file liberamente :)

— FreeSoftwareServers

3

Penso che il modo più sicuro sia riavviare usando un sistema operativo USB, CD o DVD (Debian, Ubuntu, Suse, ecc.). Quindi montare l'unità contenente i problemi ed eseguire la ridenominazione.

Più sicuro dell'avvio in un campo minato con / usr o / lib effettivamente mancanti.

— Larry
fonte

1

Puoi avviare un ISO direttamente da Grub / HDD senza bisogno di USB / DVD ecc. Grub abbastanza carino ha il loopback delle chiamate.

— FreeSoftwareServers il

0

Mi sono imbattuto in un problema simile in cui ho rinominato /usr/binper /usr/bin_bkpun po 'di test e quindi non ero in grado di rinominare (come il comando non ha trovato il sudonella directory standard, che è /usr/bin) e poi sono andato alla /usr/bin_bkpdirectory manualmente (utilizzando File manager ) e la maggior parte delle funzioni (incluso il nome) del tasto destro sono disabilitate.

Quindi ho provato il seguente comando e risolto il problema

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

Ho invocato il sudo dal percorso corrente e ha funzionato, ora tutto è tornato alla normalità.

Sistema operativo: Xubuntu 14.04

— disadattato
fonte

-3

Non posso provarlo ora (e non sono sicuro che lo vorrei), ma sembra che dovrebbe funzionare per creare un nuovo "/ usr" come un hard link (non un soft link) al tuo " / usr_bak, quindi elimina "/ usr_bak"

ln /usr_bak /usr
rm /usr_bak

Il collegamento reale creato da "ln" ( senza argomento "-s") nel file system dovrebbe rendere entrambi le directory usr e usr_bak ugualmente valide per le directory in questione. "rm" rimuove solo il collegamento che gli è stato chiesto di rimuovere, non entrambi. Poiché esiste ancora un collegamento valido ai contenuti, dovrebbero rimanere accessibili tramite il collegamento rimanente in "/ usr".

— TED
fonte

5

Avevo l'impressione che Linux (o almeno Ubuntu) non consentisse collegamenti diretti alle directory. Ad esempio, askubuntu.com/questions/210741/…

— Chris Bouchard,

4

@Chris: Giusto, Linux non consente i collegamenti hard della directory (oltre a .e .., quindi il conteggio dei collegamenti su una directory indica il numero di sottodir di primo livello). Inoltre, rmnon funziona su directory, dovresti usare rmdir. ( lne rmlavoriamo su collegamenti simbolici alle directory, ma stiamo parlando di una directory reale). Inoltre, questo non risolve il problema, perché richiede rootproprio come mv, a causa delle autorizzazioni su/ . Se potessi farlo, potresti correre mvinvece come una persona normale.

— Peter Cordes,

2

I collegamenti diretti alle directory non sono supportati sulla maggior parte degli (tutti?) Unice perché è troppo difficile per il software eseguire una scansione ricorsiva del file system per rilevare loop infiniti. È possibile se il software tiene traccia di tutti gli inode visitati e sta eseguendo la scansione di un filesystem inode (cioè non FAT32 / NTFS), ma controllare i collegamenti simbolici e non attraversarli è molto più semplice. Tutto ciò che serve è una rapida chiamata a lstat (2) per verificare il tipo di file.

— penguin359

2

@Pryftan, il mio ln(1)su Debian lo dice per l' opzione -d/ -F/ --directory: "consenti al superutente di tentare di collegare le directory hard link (nota: probabilmente fallirà a causa delle restrizioni del sistema, anche per il superutente)" . Quindi sei libero di provare, ma il tuo filesystem probabilmente non te lo permetterà.

— Toby Speight,

1

@TobySpeight Un altro pensiero: vedi anche symlink (7) che dice: I collegamenti reali potrebbero non riferirsi alle directory (per prevenire la possibilità di cicli all'interno dell'albero dei filesystem, che confonderebbero molti programmi) e potrebbero non riferirsi ai file su diversi filesystem (perché i numeri di inode non sono univoci tra i filesystem). Questo mi fa pensare che il tentativo di collegamento reale potrebbe effettivamente essere il modo di formulare qualcos'altro che accade, vale a dire che la funzione viene chiamata ma fallisce esattamente perché è una directory. (Il riferimento al filesystem è quello a cui stavo pensando in un altro commento)

— Pryftan,