Puncte:2

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

drapel de

Î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?

Organic Marble avatar
drapel us
Mi-a făcut plăcere să citesc asta, dar pentru a se potrivi cu formatul acestui site trebuie să fie o întrebare și răspuns. Cele mai multe dintre acestea se citesc mai degrabă ca un răspuns. Este bine să răspunzi la propria întrebare; luați în considerare o modificare pentru a face din aceasta o întrebare și răspuns.
Artur Meinild avatar
drapel vn
Buna ziua.S-ar putea să ai mai mult noroc dacă ai putea fi mai precis cu privire la problema exactă la care ai nevoie de un răspuns. Există mult text și îmi este greu să văd ce părți sunt relevante pentru problema dvs. specifică.
AveryFreeman avatar
drapel de
Bună, da, cam asta era ideea. Nu la început, dar apoi am rezolvat problema în timp ce puneam întrebarea. Voi încerca să o scurtez puțin.
Organic Marble avatar
drapel us
Votul apropiat a fost retras.
Puncte:2
drapel de

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.

  1. Apoi am fugit update-grub după reinstalarea acelor fișiere și confirmarea /boot a fost populat corect.
  2. 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.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.