Aterizare în promptul de urgență systemd după un proces lung de reparare a pornirii. Problemă: lipsește FS în fișierul fstab

Îmi dau seama că au fost mai multe întrebări de la oameni care au avut deja probleme de pornire, dar cred că al meu este un caz destul de particular, așa că postez încă o întrebare în speranța de a aborda unele probleme noi.

Am reparat procesul de pornire al unui VM care avea un initramfs (initrd.img și vmlinuz fișiere în /boot) din nuclee care nu mai erau instalate și încă încerca să pornească din ele.

Sunt foarte aproape de a fi terminat, dar continuă să repornească systemdlui modul de urgență (unde scrie:)

Sunteți în modul de urgență. După autentificare, tastați „journalctl -xb” pentru a vedea jurnalele de sistem, „systemctl reboot” pentru a reporni, „systemctl default” sau „exit” pentru a porni în modul implicit.
Dați parola root pentru întreținere
(sau apăsați Control-D pentru a continua):

Am pornit de pe un live CD, am montat cele 3 partiții pertinente /mnt, crootat la /mnt:

montați /dev/sda3 /mnt
montați /dev/sda2 /mnt/boot
montați /dev/sda1 /mnt/boot/efi
pentru i în proc dev dev/pts sys tmp run; do mount --bind /$i /mnt/$i; Terminat
chroot /mnt

Mi-am făcut reparațiile și am repornit.

Acum al meu fstab nu îmi montează partițiile. Am crezut că a fost configurat corect - UUID-urile sunt copiate direct din blkid | grep /dev/sda. Nu credeam că îi lipsește nimic.

Iată erorile pe care le văd chiar înainte de a ajunge la solicitarea modului de urgență:

[FAILED] Nu s-a putut monta /boot
Consultați „systemctl status boot.mount” pentru detalii.
[DEPEND] Dependența a eșuat pentru sistemele de fișiere locale
[DEPEND] Dependența a eșuat pentru Oprirea upgrade-urilor nesupravegheate
[DEPEND] Dependența a eșuat pentru /boot/efi

Deci, bineînțeles că m-am uitat systemctl status boot.mount, dar este activ (verde) și spune că este încărcat, deși my /boot folderul este gol, cu excepția cazului în care montez manual /dev/sda2.

Pare foarte ciudat. De ce ar fi boot.mont spune că se încarcă /boot partiție dacă este clar că nu?

Așa că de fapt mi-am dat seama de problemă în timp ce scriam întrebarea. După cum puteți vedea din ceea ce am scris la început, a fost un proces foarte lung (luceam la el de vreo 2 zile până am ajuns să vreau să cer ajutor).

Dacă te uiți la sfârșitul Q, am primit acest mesaj de la dmesg în timpul procesului de pornire:

[FAILED] Nu s-a putut monta /boot
Consultați „systemctl status boot.mount” pentru detalii.

Deci, bineînțeles că am încercat systemctl status boot.mount să văd ce spunea, dar spunea boot.mont este activ (verde), este încărcat și funcționează corect, chiar dacă /boot era gol, cu excepția cazului în care am montat manual /dev/sda2 (ceea ce este exact opusul a ceea ce m-aș aștepta).

Așa că am început să mă gândesc că ar putea fi ceva în neregulă cu serviciul. am dezactivat boot.mont chiar dacă acesta spus a functionat corect:

systemctl disable --now boot.mount

Am încercat să-l reactivez, dar am primit o eroare:

systemctl enable --now boot.mount
Unitatea nu a putut fi activată: unitatea /run/systemd/generator/boot.mount este tranzitorie sau generată

OK, asta are sens, este declanșat prin procesul de pornire și nu poate fi invocat printr-o comandă de utilizator. Așa că am încercat să remontez toate dispozitivele cu:

monte -a

Și am văzut că a fost o eroare în /etc/fstab fişier:

eroare: rw,relatime nu este un sistem de fișiere valid

(sau ceva în acest sens).

Cheia aici este că, dacă nu aș fi încercat să montez sistemul de fișiere manual, nu aș fi primit niciodată acest feedback. Mesajul de eroare de la monte -a se ajunge când fstab conține sintaxă necorespunzătoare este incredibil de utilă. Mult mai util decât:

[FAILED] Nu s-a putut monta /boot
Consultați „systemctl status boot.mount” pentru detalii.

... și apoi văzând o unitate systemd „funcțională” pentru boot.mont când /boot nu se montează (chiar dacă făcut duce-mă la locul potrivit în cele din urmă).

Așa că am editat fstab și a introdus informațiile despre sistemul de fișiere pentru /boot partiția care nu s-a montat, apoi am rulat din nou monte -a (care face în esență același lucru ca boot.mont) și a primit un răspuns pozitiv.

Acum cele două partiții se montează corect după o repornire și totul este bine în țara hreanului și marmeladei.

Dacă acest lucru nu abordează niciuna dintre problemele dvs., iată câteva note suplimentare despre procesul prin care am trecut înainte de a ajunge la punctul de mai sus în care căutam ajutor (nu ezitați să nu mai citiți după ce ajungeți la problema dvs.):

Problema inițială pe care o aveam acum două zile a fost sistemul care încerca să pornească din nuclee care nu mai erau în sistem. Deci, după ce am pornit cu live CD-ul, am șters /boot conținutul folderului (unde sunt toate initrd fișierele sunt localizate).

M-am gândit că voi recrea doar initramfs folosind update-initramfs -c -k toate din nucleele actuale pe care le instalasem, dar apoi am aflat că nu pot re-crea config sau Sistem.hartă fisiere cu depmod singur. Acest lucru s-a dovedit a fi puțin mai supărător decât mă chinuisem.

Am găsit că cea mai simplă modalitate de a regenera sau de a achiziționa toate aceste fișiere este:

1. ștergeți tot conținutul /boot,
2. dezinstalează orice imagine linux, antetul linux și module-linux fișiere pe care nu am avut de gând să le folosesc,
3. ștergeți toate directoarele reziduale în /usr/lib/modules, și apoi
4. reinstala imagine linux, module-linux și antete linux fișierele pe care intenționam să le folosesc (cele mai recente două versiuni generice)

Notă: reinstalați aceste 3 tipuri de fișiere totul in acelasi timp așa am reușit să obțin /boot/System.map și /boot/config fișierele înapoi - înainte doar de a reinstala fișierul imagine linux fișierele nu au făcut-o. Este posibil să fie incluse cu module (modulele ar avea sens), sau antete pachete, dar asta a funcționat pentru mine.

5. Apoi am fugit update-grub după reinstalarea acelor fișiere și confirmarea /boot a fost populat corect.
6. am alergat si eu instalare bootctl și /etc/kernel/postinst.d/zz-udpate-systemd-boot, așa că aș fi făcut-o systemd-boot instalat ca alternativă.

La un moment dat, după o repornire, a trebuit să reconfigurez sistem.ţintă la multi-utilizator.tinta în loc de grafică.ţintă, probabil din cauza a avea chrooted cu toate acele monturi într-un CD grafic live pentru a rula reparare cizme program acum câteva zile, care necesită grafică (și cred /dev/pts /tmp și /alerga au fost obligați să obțină afișaj: 0.0 a munci):

systemctl set-default multi-user.target

Ok cam asta e. Sper că asta ajută pe cineva.