Ricordi, ti ho parlato di un laptop incasinato? Bene, elaboriamo, vero? Stavo facendo alcuni test con il software di imaging e ripristino e, una volta terminato, volevo vedere quanto fosse andato bene il processo. Non bene, si è scoperto. GRUB era lì, ma inizialmente nessuna voce nel menu funzionava. Una volta che l'ho prontamente risolto, ho visto che Windows 10 non si avviava e non si riparava automaticamente e metà delle distribuzioni sul sistema (su otto totali) nella configurazione di avvio multiplo non si avviava neanche , entrando in modalità di emergenza. Stiamo parlando dell'intera quota di distribuzioni, fai la tua scelta.
Ora, il ripristino di GRUB è stato piuttosto complicato:nessuno dei metodi a cui potevo pensare ha funzionato e ho finito per installare una distribuzione di prova solo per configurare correttamente il bootloader. Quindi, ho avviato una delle distribuzioni che funzionavano e ho notato che non c'era perdita di dati. Tutto era lì, tutte le partizioni erano sane e intere, ei file erano al posto giusto, Linux e Windows inclusi. In questo articolo, vorrei mostrarti come ho risolto questo problema e come l'ho risolto e nel seguito faremo lo stesso per Windows 10. Un esercizio utile. Seguimi.
Problema in dettaglio
Ho fatto il seguente esercizio con neon come antipasto, ma si applica praticamente a tutte le distro dal 2011 al 2012 circa. Quindi quello che succede è che KDE neon inizia ad avviarsi e poi cade nella shell di emergenza. Il sistema mi ha detto che dovrei eseguire journalctl -xb per vedere il registro di avvio e capire cosa c'era che non andava. Ora, questa non è la prima volta che incontriamo questo. Ho gestito un problema simile con Fedora non molto tempo fa.
Ma qui, il problema era leggermente diverso. Sì, il registro di avvio ha mostrato problemi con /boot/efi, ma il motivo per cui ciò è accaduto derivava da un altro problema. Se ti stai chiedendo come ho ottenuto e copiato i log nella sessione di emergenza (se hai bisogno di qualcosa del genere), puoi copiare il contenuto in un file e poi recuperarlo tramite una sessione live (con redirect> o usando il comando tee ), oppure una volta risolto il problema, puoi scaricare l'ultimo meno un log con journalctl -x --boot=-1. Questa è la tecnologia moderna per te.
06 dic 12:57:09 tester systemd[1]:Dipendenza non riuscita per il controllo del file system su /dev/disk/
-- Oggetto:Unit systemd-fsck@dev-disk-by\x2duuid-641C\x2d39CE. servizio non riuscito
-- Definito da:systemd
-- Supporto:http://www.ubuntu.com/support
--
-- Unità systemd-fsck@ dev-disk-by\x2duuid-641C\x2d39CE.service non è riuscito.
--
-- Il risultato è RISULTATO.
06 dic 12:57:09 tester systemd[1]:dipendenza non riuscita per /boot/efi.
-- Oggetto:Unità boot-efi.mount non riuscita
-- Defined-By:systemd
-- Supporto:http://www.ubuntu.com/support
--
-- L'unità boot-efi.mount non è riuscita.
Soluzione
Mi chiedevo cosa poteva essere andato storto. L'intero dev-disk-by è stato un grande suggerimento. Ricordi quando ti ho mostrato come risolvere i problemi di avvio lento quando l'UUID della partizione di swap è stato modificato? Sembrava proprio così, tranne che /boot/efi è fondamentale nel processo di avvio del sistema.
Ho aperto /etc/fstab e, in effetti, l'UUID elencato per la partizione di swap (dev/sda10) NON era corretto. Il file ha anche un commento che dice che la voce della partizione era il numero del dispositivo, e poi è stata cambiata nella presunta sciocchezza UUID "moderna" e "utile" che causa solo problemi.
# swap era su /dev/sda10 durante l'installazione
UUID=8140c8d0-1e33-42c1-8c3c-828449adfe08 nessuno swap swap 0 0
Ho cambiato le cose UUID in /dev/sda10, riavviato e tutto era perfetto!
Comandi necessari per farlo
Ora, rallentiamo un secondo. Quindi questo è il modo in cui puoi verificare se il tuo sistema sta utilizzando i numeri o gli identificatori di dispositivo corretti. Innanzitutto, puoi elencare le partizioni con fdisk -l. Questo comando ti darà una panoramica di tutte le diverse partizioni e dei loro filesystem. In questo modo puoi ottenere una comprensione di base del tuo sistema. In particolare, è necessaria la partizione di root (/), potresti avere una partizione /boot separata, come spesso accade sui sistemi UEFI, potresti utilizzare una /home separata e potresti anche avere una partizione di swap opzionale e separata. Questi saranno contrassegnati con numeri di dispositivo, come /dev/sda2, /dev/sda8, ecc.
Il problema inizia nel modo in cui le versioni più recenti delle distribuzioni Linux mappano i dispositivi in /etc/fstab, un file che viene analizzato all'avvio del sistema per informazioni su quali dispositivi devono essere montati automaticamente. In passato, i dispositivi erano referenziati come fa fdisk, dev/XdYZ, dove X indicava il tipo di disco (di solito lettere h o s), Y sarebbe la lettera del dispositivo (come ordinato dal BIOS di sistema, ad es. a, b o simili) e Z sarebbe il numero della partizione. Ad esempio, /dev/sdb3 indica la terza partizione sul secondo disco con il tipo di connessione SATA/SCSI/PCI-E.
In effetti, le distribuzioni "moderne" usano UUID:questa è una stringa umana di numeri e lettere senza significato, qualcosa come a45f-cc9a, pensata per mappare in modo univoco le partizioni, quindi se l'ordine del disco viene in qualche modo modificato, il sistema può ancora avviarsi. Forse ha senso in azienda, ma nell'ambiente domestico, questa è una sciocchezza assoluta e completa, come praticamente OGNI soluzione "moderna", come systemd, nuova convenzione di denominazione dell'interfaccia di rete, nuovi strumenti di gestione della rete e così via. Più avanti sulla filosofia.
Ora, se hai un UUID sbagliato elencato in /etc/fstab, il sistema non può montare queste partizioni - il meccanismo è super traballante, perché non ha la capacità di controllare, cercare o riparare una configurazione rotta - potresti finire con un non avviabile sistema. Anche questa situazione è impossibile da risolvere rapidamente, perché le stringhe UUID sono totalmente inutili per gli esseri umani.
Puoi verificare l'elenco degli UUID del dispositivo con il comando blkid, ad esempio:
blkid
/dev/mapper/sda3_crypt:UUID="TpZGKB-31Lq-U1Ap-BZJCcX" TYPE="LVM2_member"
/dev/mapper/kubuntu--vg-root:UUID="dcae17fd-7cfe -c0b721e" TYPE="ext4"
Devi confrontare visivamente e poi capire cosa manca. E poi correggi manualmente /etc/fstab.
Moderno, continui a usare quella parola...
La semplice realtà è la seguente:lavoro con Linux da più di 15 anni. Ad un certo punto della vita, stavo gestendo una bellissima configurazione HPC con circa 50.000 server fisici distribuiti su circa 40 data center. Avevo la mia quota di sistemi aziendali e domestici, con vecchie e nuove tecnologie.
Ho riscontrato sistemi rotti principalmente da quando siamo passati dal vecchio BIOS + MBR + GRUB + init al nuovo UEFI + GPT + GRUB2 + systemd. Non c'è niente di magico, resiliente o migliorato in queste soluzioni. Risolvono alcuni reali limiti tecnici nel settore, è vero. Ma introducono anche una configurazione molto meno robusta che è infinitamente più difficile da eseguire il debug e la risoluzione dei problemi da parte degli esseri umani. Ad esempio, non ho MAI MAI visto un sistema rotto perché l'ordine del disco è stato incasinato. Ma ho visto MOLTI esempi di sistemi danneggiati dall'uso dell'UUID invece della semplice notazione del numero di dispositivo.
La correzione di GRUB è stata una cosa banale di copiare 512 byte di dati qua o là nel peggiore dei casi e modificare un file di testo. Ora, è quasi una religione scientifica accedere alle nuove interfacce, lavorare con EFI e simili. Riparare l'avvio rotto di Linux non era un problema, e ora devo analizzare i log binari in testo, e poi capire perché i miei sistemi potrebbero essere traballanti, solo per scoprire che è tutto perché sono costretto a usare "soluzioni "a problemi che non esistono. Ad esempio, la cosa UUID. L'ip contro la cosa ifconfig. Perché enp0s0, o qualunque sia il nuovo identificatore della scheda di rete, è migliore, più intelligente o più intuitivo di eth0? Un tempo era logico, ethernet =eth.
Qual è lo scenario in cui gli utenti domestici devono aggiungere o rimuovere frequentemente i dischi rigidi dentro e fuori le loro scatole o giocare con le impostazioni del BIOS? Non è. Allora perché i sistemi domestici sono dotati di soluzioni inadeguate? Perché Linux non è intrinsecamente pensato per essere una soluzione domestica e mi sento un idiota.
E questo è solo l'inizio. Col passare del tempo, avremo più astrazione, astrazione, astrazione, automazione, merda ottimizzata per la macchina e dovrai fare affidamento e dipendere dalla misericordia di qualunque entità stia pompando il loro ultimo Qualunque cosa come servizio. Verrà un punto in cui tutta questa sciocchezza esploderà, perché non è possibile eseguire il debug. Oppure sarà lasciato alle macchine da gestire da sole, usando i loro brutti protocolli che gli esseri umani non avrebbero mai dovuto vedere o sperimentare in primo luogo. A proposito di design scadente.
Conclusione
Innanzitutto, spero che tu possa trovare utile questo articolo. Nella maggior parte dei casi in cui un sistema Linux non si avvia, probabilmente stai riscontrando problemi con qualcosa a che fare con /boot o /boot/efi. Se ciò accade, dovresti essere abbastanza sicuro di leggere i log, quindi provare a capire se hai componenti mancanti o rotti, come ti ho mostrato con i bug initrd e initramfs (collegati sopra), o la configurazione del sistema è errata e sta cercando di fare riferimento a risorse inesistenti. Nel nostro caso, come il problema dell'avvio lento, il colpevole era l'uso di falsi UUID per le partizioni.
Questo dovrebbe essere risolto a livello di sistema. Ma come ho notato molte volte prima, la convalida non è una cosa in Linux. Gli sviluppatori fanno le loro cose e vanno avanti. Nessuno si preoccupa di pensare al quadro più ampio, alla filosofia. Ma questo è il pensiero del software:funzione -> output. A nessuno importa cosa vive al di fuori della funzione e ne incapsula la funzionalità.
Un sistema robusto esaminerebbe effettivamente i dispositivi e i filesystem esistenti e proverebbe a capire se c'è un problema nella configurazione. Un sistema robusto avrebbe un backup dei file critici e proverebbe a farvi riferimento. Un sistema robusto tenterebbe qualcosa in diversi modi e correla le cose prima di fallire in modo significativo. Niente di tutto ciò esiste oggi, non in Linux o in qualsiasi altro sistema, perché è più economico mantenere un'orda di tecnici poveri che inventare meccanismi intelligenti di auto-guarigione. E se ti succede a casa tua, beh, sei solo una garanzia. Quindi, quando le persone parlano di libertà e open source, stanno parlando della cosa sbagliata. A cosa serve l'open source se viene utilizzato per sviluppare soluzioni offuscate? Sono triste. Fuori devo piangere.