Linux Mint 20 Ulyana apt dist-upgrade után a követkző hibaüzenetet adja a grub-common csomagnál:
Job for grub-initrd-fallback.service failed because the control process exited with error code.
See "systemctl status grub-initrd-fallback.service" and "journalctl -xe" for details.
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Job for grub-common.service failed because the control process exited with error code.
See "systemctl status grub-common.service" and "journalctl -xe" for details.
invoke-rc.d: initscript grub-common, action "restart" failed.
● grub-common.service - Record successful boot for GRUB
Loaded: loaded (/lib/systemd/system/grub-common.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2023-01-30 23:30:29 CET; 8ms ago
Process: 5914 ExecStartPre=/bin/sh -c [ -s /boot/grub/grubenv ] || rm -f /boot/grub/grubenv; mkdir -p /boot/grub (code=exited, status=0/SUCCESS)
Process: 5916 ExecStart=/usr/bin/grub-editenv /boot/grub/grubenv unset recordfail (code=exited, status=1/FAILURE)
Main PID: 5916 (code=exited, status=1/FAILURE)
jan 30 23:30:29 Mint systemd[1]: Starting Record successful boot for GRUB...
jan 30 23:30:29 Mint grub-editenv[5916]: /usr/bin/grub-editenv: hiba: érvénytelen környezetblokk.
jan 30 23:30:29 Mint systemd[1]: grub-common.service: Main process exited, code=exited, status=1/FAILURE
jan 30 23:30:29 Mint systemd[1]: grub-common.service: Failed with result 'exit-code'.
jan 30 23:30:29 Mint systemd[1]: Failed to start Record successful boot for GRUB.
dpkg: hiba a csomag feldolgozásakor: grub-common (--configure):
installed grub-common package post-installation script subprocess returned error exit status 1
dpkg: függőségi problémák miatt nem állítható be: os-prober:
os-prober függőségek: grub-common; ám:
grub-common csomag még beállítatlan.
/lib/systemd/system/grub-common.servic -ben be van állítva
ExecStart=/usr/bin/grub-editenv /boot/grub/grubenv unset recordfail
teljes path-ra. De ez nem oldotta meg a fenti hibát. Nincs több grub-editenv a rendszerben csak a /usr/bin/ helyen.
- 196 megtekintés
Hozzászólások
A
/boot/grub/grubenv
ugye symlink? Mert ha nem, le fogja törölni, s akkor a paraméterül megadott file hiányozni fog.
Nincs több grub-editenv a rendszerben csak a /usr/bin/ helyen.
De nem is ez a baj. Az fut, csak nyafog a kapott paraméter miatt. Annak a grubenv-nek valahol léteznie kellene, amelyre mutat a /boot/grub/grubenv symlink.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
/boot/grub/grubenv: data
Nem változtattam rajta semmit, így volt a rendszerben.
- A hozzászóláshoz be kell jelentkezni
Bocs, én tévedtem! :( A -s size, nem pedig symlink. Az a -h lenne. Szóval a 0 hosszúságú file-t törli.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
A végén lecserélem a Grub-ot Lilo-ra.
- A hozzászóláshoz be kell jelentkezni
Nem a grubbal van a baj, hanem a systemd-vel. Fedorán nekem is okozott felfordulást. Nézz körül a neten, hogyan lehet hatástalanítani a systemd-boot-ot.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Nekem úgy tűnik, hogy inkább csak a systemd adott service-ével van baj. A systemd-boot egy teljesen külön dolog, sokáig én se tudtam, hogy igazából semmi köze nincs a systemd-hez, nem is azok a fejlesztők fejelsztik, akár még systemd nélkül is megy. Egy korábban gummiboot néven fejlesztett, nagyon egyszerű bootolási módszer, ami a bootctl-es telepítéssel a bootx64.efi-t tölti be (ez lényegében a bootmanager), és ez tud a /boot/loader/entries alatt indítóbejegyzéseket kezelni. Tök egyszerű az egész, kiválóan működik, mindenféle GRUB nélkül is, ráadásul portable módban akár több rendszert is tud indítani, én Arch-on még újratelepítéskor sem teszem újra, mert bootolja az újonnan telepített rendszert (feltéve, hogy nem particionálok újra, tehát a neki megadott PARTUUID-k nem változnak).
Sajnos ez a hátránya a generic disztróknak, hogy mindenkire rátolják ezt a GRUB-ot, ami túl komplex, csak a baj van vele. Azért csinálják, mert ha valaki titkosított, meg spéci fájlrendszeres, komplikált RAID-es rendszerről akar bootolni, akkor kellenek a feature-ei. De a normál userek 99%-a egyszerű, titkosítatlan, nem secure boot-os ext4-ről bootol, nekik overkill, tökéletesen elég lenne egy sokkal egyszerűbb lilo (MBR CSM bootnál) vagy systemd-boot (UEFI bootnál). Csak mivel a disztró generic, ezért a legbonyásabb felhasználást veszi közös nevezőnek, hiszen minden igényt le kell fedjen.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni
Mióta kezeli a systemd a grub-ot? Miről maradtam le?
“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”
― Philip K. Dick
- A hozzászóláshoz be kell jelentkezni
Majd' negy eve mar volt ra bugreport - mar az adott service-re -, tovabb nem kerestem: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1823391
- A hozzászóláshoz be kell jelentkezni
Nem, mert ez csak Mint 20-on belüli frissítés.
- A hozzászóláshoz be kell jelentkezni
20 és a 20.1 között elvileg csak az usrmerge a lényegi különbség, annak nem kellene összekócolnia a grubot
- A hozzászóláshoz be kell jelentkezni
Egyetértek és nem tudom mire vélni a dolgot. Okkal utálják annyian a systemd-t, mert valóban egy átláthatatlan szörnyeteg tákolmány. Ha problémát okoz elég nehéz javítani. A szóban forgó Mint 20 virtuális gépek alapját képező rendszer, ebből vannak klónozva majd feladatra szabva azok a rendszerek ahol ezt használom. Több előző snapshotolt, sőt külön felhőbe mentett állapotát is próbáltam frissíteni, azonos hiba volt az eredmény.
Közel egy éve volt utoljára bekapcsolva, mivel a Mint 19 megfelelőbb volt a feladatra. Most viszont már kelleni fog a Mint 20 és előjött a leírt probléma.
- A hozzászóláshoz be kell jelentkezni