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:
- ștergeți tot conținutul
/boot
,
- dezinstalează orice
imagine linux
, antetul linux
și module-linux
fișiere pe care nu am avut de gând să le folosesc,
- ștergeți toate directoarele reziduale în
/usr/lib/modules
, și apoi
- 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.
- Apoi am fugit
update-grub
după reinstalarea acelor fișiere și confirmarea /boot
a fost populat corect.
- 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 chroot
ed 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.