Spostato / bin contenuto in / usr / bin, è possibile annullare?

18

Con Ubuntu 17.04, stavo installando un software dalla distribuzione non repository, dovevo spostare il contenuto della cartella bin del software in / usr / bin (che era già un consiglio iffy)

È uno di quei giorni, quindi quello che ho fatto invece:

mv /bin/* /usr/bin

Quindi ho sbagliato e ho accidentalmente spostato tutti i file nel cestino in / usr / bin e / bin era vuoto. Poiché ritengo che / bin sia fondamentale per il sistema, per una rapida soluzione, ho copiato i contenuti / usr / bin su / bin.

Ora i miei contenuti / bin e / usr / bin sono identici ed entrambi contengono i file originariamente in / bin e / usr / bin separati.

Ubuntu è in uno stato rotto adesso? (Non ho ancora provato a riavviare il computer, in questo momento tutto sembra funzionare ancora)
C'è un modo per sapere quali file sono stati spostati / copiati in / usr / bin più di recente, così potrei semplicemente occuparmi manualmente della situazione? 2.1 Di solito ci sono file sovrapposti in / bin e / usr / bin
Esistono altri modi per annullare ciò che ho fatto?

Non ho Timeshift installato, quindi ripristinare i backup non è un'opzione, ma al momento non c'è nulla di critico sul computer, quindi potrei semplicemente ammettere di aver sbagliato a reinstallare l'intera partizione di Linux.

— uno di questi giorni
fonte

2

dpkg-query -l | awk '{system ("dpkg-query -L" $ 2 "| grep -E \" ^ / usr / bin /.*$ \ "")}' Questo ti darà tutti i file inizialmente in / usr / bin in base a i pacchetti installati

— Raman Sailopal,

7

@ SatōKatsura /binè fondamentale per il sistema. Il suo contenuto deve essere presente nelle prime fasi di avvio. Non si desidera creare un collegamento simbolico a una partizione ( /usrqui) che potrebbe non essere montata all'avvio.

— Xhienne,

1

@xhienne Non ho mai detto che sarebbe sopravvissuto al riavvio. È una soluzione temporanea per ottenere funzionalità sufficienti per poter riparare il sistema.

— Satō Katsura,

1

@xhienne dipende da come hai impostato la distribuzione. Arch, ad esempio, non mantiene un separato /binper impostazione predefinita. Il partizionamento predefinito di Ubuntu non crea /usrpartizioni separate . Sono curioso di sapere quante persone effettivamente fanno una separazione /usrcon una distribuzione moderna.

— Muru,

1

@muru Prendi il mio commento come generico. Puoi assumere quello che vuoi sul numero di partizioni, preferisco non farlo e sto avvisando di non collegare / usr / bin / * a / bin, che nella migliore delle ipotesi è completamente inutile e nella peggiore delle ipotesi potrebbe rendere il sistema inutilizzabile al prossimo avvio . Nessun sistema che segue l'FHS dovrebbe contenere collegamenti simbolici a / usr / bin. Invece è stato consigliato a OP di copiare i file.

— Xhienne,

19

Ubuntu è in uno stato rotto adesso?

Sì, il tuo Ubuntu è rotto

Hai incasinato qualcosa di importante per la gestione dei pacchetti .

Quindi, in pratica, esegui il backup dei tuoi dati importanti (almeno /etce /home), forse anche l'elenco dei pacchetti installati, ad esempio l'output di dpkg -l, e reinstalla Ubuntu.

^{(un non principiante potrebbe provare a gestire - come in altre risposte -, ma poi non avrebbe fatto un errore così grande e basilare)}

Potrei solo ammettere di aver sbagliato a reinstallare l'intera partizione di Linux.

Questo è probabilmente ciò che consumerebbe meno del tuo tempo. Mantenere il tuo sistema attuale con l'aiuto di altre risposte è mantenerlo in uno stato molto disordinato (che ti darebbe mal di testa in futuro).

Dato che stai riformattando il tuo disco, considera di inserire /homeuna partizione separata (quindi in futuro tali errori non perderanno i tuoi dati). Prima di fare che la stampa su carta l'output di df -he df -hie fdisk -l(che danno informazioni su -sia spazio su disco utilizzato e disponibile- ...). Sii saggio per avere una partizione di sistema abbastanza grande (il file system di root); se te lo puoi permettere 100 Gbytes è più che sufficiente.

Avrei dovuto spostare il contenuto della cartella bin del software in / usr / bin

(terminologia: Unix ha directory, non "cartelle").

Quello ( passare a /usr/bin/) è molto sbagliato. O migliorare il vostro $ PATH (preferibilmente) o al massimo aggiuntivi collegamenti simbolici in /usr/bin/e preferibilmente spostare (o aggiungere link simbolici) eseguibili /usr/local/bin/.

L'approccio saggio è quello di non cambiamento /usr/bin/, /bin, /sbin, /usr/sbin/ al di fuori degli strumenti di gestione dei pacchetti (per esempio dpkg, apt-get, aptitude, ecc ...). Leggi l' FHS .

— Basile Starynkevitch
fonte

4

Accettando questa risposta: sembra che dopo aver provato a ripristinarlo abbia funzionato fino al riavvio, che non è stato più in grado di avviare alcuna sessione di ambiente desktop. Invece di provare a risolverlo, ammetterò il mio errore totale e reinstallerò semplicemente la partizione Linux. Dato che tutto era sotto controllo della versione e avevo usato il sistema solo per una settimana, tutto ciò che persi davvero era la mia dignità e un piccolo attacco di panico, ma sembra normale quando la vita mi insegna una lezione.

— oneOfThoseDays

1

Dato /binche /usr/binsono identici, non sono sicuro del motivo per cui la gestione dei pacchetti verrebbe rovinata. Esiste davvero un caso in cui /bin/fooe /usr/bin/foosono entrambi fornito da un pacchetto (s). Altrimenti, ci sono solo alcuni file extra che fluttuano intorno.

— StrongBad,

3

@Basile no non sarebbe (essere infelice); la gestione dei pacchetti si preoccupa solo dei file di cui è a conoscenza, non si lamenterà dei file di cui non è a conoscenza. Anche per i file che non conoscono, non sarà particolarmente infastidito se hanno cambiato ...

— Stephen Kitt

2

@Basile, inoltre, non vorrei contare sull'ultima parte "(un non novizio potrebbe provare a gestire - come in altre risposte -, ma poi non avrebbe fatto un errore così grande e basilare)" essendo vero ;-). Anche gli esperti a volte scivolano via!

— Stephen Kitt,

1

FWIW la /partizione del mio sistema principale è di 12 GB e non ho mai avuto problemi di spazio nonostante lo usassi per lo sviluppo (leggi file di intestazione e molti strumenti) ufficio e design (leggi strumenti pesanti), su KDE (leggi non-sottile). Aggiungi 4 GB in più se non dividi /var, gonfia del 25% se vuoi un margine maggiore di me e a 20 GB sei più che buono.

— extra

36

Su Linux (e sulla maggior parte degli altri sistemi, sebbene POSIX non fornisca tale garanzia a meno che lo spostamento non sia avvenuto attraverso i file system), ciò avrebbe aggiornato il loro tempo di attività, quindi supponendo che nessuno degli altri in /usr/binè stato toccato nelle ultime 24 ore , dovresti essere in grado di spostarli indietro con:

find /usr/bin/. ! -name . -prune -ctime -1 -exec sh -c '
   echo mv -i "$@" /bin' sh {} +

Rimuovi echose sembra corretto. Si noti che non sarà possibile ripristinare i file esistenti con lo stesso nome in /bine /usr/bin(quelli originali in /usr/binsarebbero andati persi)

Un potenziale avvertimento: se alcuni file fossero strettamente collegati in entrambi /bine /usr/bin, tutti i collegamenti /usr/binreali verranno spostati in /bin.

Ora, potresti pensare che dato /binche /usr/binsono predefiniti $PATH, ed /binè disponibile /bootalmeno prima che /usrsia montato, non dovrebbe importare se sono presenti gli eseguibili /bininvece di /usr/bin.

Ma ciò trascurerebbe il fatto che molti comandi codificano i percorsi degli eseguibili e si aspettano che siano in un caso specifico. Un caso comune è la frangia. Tutti gli script che hanno:

#! /usr/bin/env bash

non funzionerà dopo di te mv /usr/bin/env /bin/env. A tale proposito, avere i comandi in entrambe le posizioni è più sicuro in quanto non romperà quegli script.

— Stéphane Chazelas
fonte

3

Come accennato in precedenza (ho rimosso il mio commento in quanto aveva un grave errore che avrebbe cercato di spostare tutto in una directory chiamata - iscusate a tale proposito!) Su sistemi GNU / Linux come Ubuntu uno può usare find /usr/bin/. ! -name . -prune -ctime -1 -exec echo mv -it /bin {} +dal momento che GNU Coreutilsmv supporta -t. Altri sistemi operativi generalmente non lo supportano , né funziona con l'alternativa mvfornita da BusyBox .

— Eliah Kagan,

17

L'installazione dovrebbe essere per lo più OK; non ci dovrebbero essere file diversi con lo stesso nome in /usre /usr/bin(che risponde alla tua 2.1), quindi avere tutti i file in entrambi /bine /usr/binnon romperà nulla (fino a quando non aggiorni i pacchetti). L'unico problema che potresti avere ora sono i collegamenti simbolici rotti, se hai sovrascritto un binario con un collegamento simbolico ad esso. Per risolvere questo problema, cerca collegamenti simbolici non funzionanti:
```
find -L /bin /usr/bin -type l -ls
```
e reinstalla tutti i pacchetti corrispondenti ai file elencati (ad esempio, se si /usr/bin/zshpresenta come rotto, dpkg -S /bin/zsh /usr/bin/zshti dirà da quale pacchetto proviene il file; reinstallalo con apt --reinstall install zsh).
Puoi mostrare e ordinare per ctime per vedere i file che sono stati recentemente modificati (che includerà i file che hai spostato):
```
ls -ltc /bin
```
L'approccio migliore per annullare ciò che hai fatto è usare il cruftpacchetto ed eliminare i file che trova /bino /usr/binche non provengono da un pacchetto:
```
sudo apt install cruft
sudo cruft -d "/ /usr"
```
a meno che i file non siano link simbolici ai file /etc/alternatives(nel qual caso dovresti lasciarli soli).

— Stephen Kitt
fonte

Tranne gli script che iniziano con #! /bin/sho simili.

— Satō Katsura,

@ SatōKatsura funzionerebbero comunque bene se si shtrovano in entrambi /bine /usr/bin(tutti i file sono duplicati ora).

— Stephen Kitt,

1

Un toolk speciale come cruftnon è necessario per questo lavoro perché il gestore pacchetti tiene traccia anche dei file installati. Vedi unix.stackexchange.com/questions/153260/… .

— Ned64,

1

comm -12 <(ls /bin) <(ls /usr/bin)mostra alcune voci su un sistema Ubuntu su cui l'ho provato. Alcuni con un /bin/foo -> /usr/bin/foomezzo foosarebbero andati persi.

— Stéphane Chazelas,

@ Stéphane ah sì, spostando il collegamento si verificherebbe l'originale ...

— Stephen Kitt,

6

Può essere educativo elaborare il motivo per cui il tuo sistema è, in misura maggiore o minore, "rotto".

Come sottolinea @ basile-starynkevitch, il sistema di gestione dei pacchetti ha il potenziale per confondersi terribilmente se trova binari /binquando dovrebbero trovarsi /usr/bin, e viceversa.
Alcuni script (forse importanti) possono essere cablati per trovare un determinato binario in una directory o nell'altra (in alcune circostanze è buona prassi, ad esempio dal punto di vista della sicurezza, non fare affidamento sul contenuto di $PATH).
Il motivo per cui esiste una distinzione tra /bined /usr/binè che il primo potrebbe essere potenzialmente su una partizione che è montata in una fase precedente dell'avvio. In questo contesto (ad esempio, all'avvio del sistema), non solo i /bin/xxxbinari verrebbero probabilmente indicati da un percorso completo, ma la directory /usr/binpotrebbe non essere disponibile sul sistema in quel momento. (Se tu df /bine df /usr/bin, potresti vedere lo stesso filesystem elencato o diversi; probabilmente la maggior parte delle installazioni predefinite, in questi giorni, lasciano entrambe le directory nella stessa partizione).

Quindi puoi senza dubbio vedere che, se hai gli stessi binari in entrambi /bine /usr/bin, quindi i problemi 2 e 3 non si verificano e il danno da 1 potrebbe essere minore. Ri 1, ad esempio, i pacchetti potrebbero non essere disinstallati correttamente se si tenta di rimuoverli; e gli aggiornamenti potrebbero diventare confusi, se l'aggiornamento tenta di aggiornare la copia nella posizione "corretta", ma ignora la copia nella posizione "errata". Pertanto, se i rimedi di cui sopra sembrano troppo drastici o complicati, è possibile cavarsela lasciando il sistema in questo stato.

Ma se si tratta di un sistema importante, non mi sarei davvero impegnato.

Una regola generale (ancora una volta facendo eco @ Basile-starynkevitch) non è mai di scimmia con /usr/bin, /bine amici - che 'appartengono' alla distribuzione - e un pacchetto che suggerisce di farlo come parte del suo normale installazione è ... non è un buon pacchetto.

Edit: Rilevante per punto 3, c'è una discussione nel contesto di systemd / Fedora e gli amici del perché ha senso per spostare tutti i contenuti di /bina /usr/bin, e symlink il primo al secondo. Questa non è una raccomandazione che tu faccia questo, tu stesso - quella pagina è indirizzata alle persone che fanno distribuzioni - ma include un po 'di storia sul perché esiste questa distinzione (e implicitamente perché ora è semplicemente una tradizione polverosa).

— Norman Grey
fonte