Fórumok
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.
Hozzászólások
A
ugye symlink? Mert ha nem, le fogja törölni, s akkor a paraméterül megadott file hiányozni fog.
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
/boot/grub/grubenv: data
Nem változtattam rajta semmit, így volt a rendszerben.
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 végén lecserélem a Grub-ot Lilo-ra.
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
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.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Mióta kezeli a systemd a grub-ot? Miről maradtam le?
Majd' negy eve mar volt ra bugreport - mar az adott service-re -, tovabb nem kerestem: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1823391
mintupgrade volt?
www.pingvinpasztor.hu
Nem, mert ez csak Mint 20-on belüli frissítés.
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
www.pingvinpasztor.hu
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.