grub2 configfile

Debian GNU/Linux

Sziasztok!

 

Azzal a fura hibával találkoztam, hogy amikor a configfile-val megadok egy új konfigfájlt a grub-nak akkor csak simán újraindítja a gépet.

 

a 40_custom a következő:

 

menuentry "Debian13_chainload" {
        set root='hd0,gpt7'
        configfile /boot/grub/grub.cfg
}
 

Ezzel a sorral, több gépem is simán betölti az adott rendszer grub konfigját, de ezen  gépen simán újraindul és keződik előlről, ha kiválasztom ezt a menüpontot.

 

HP2170p laptop, UEFI boot, secure boot kikapcsolva, lemez gpt, debian 12.12 a fő rendszer külön boot partícióval, mert a root BTRFS, a 13.1 csak még mint tesztként telepítve ext4-es partícióra.

Van egy régebbi dell gépem, azon még csak BIOS/MBR boot van, ott simán megy ez a konfig, egy másik dellen is, az is uefis gpt-s lemez.

Amikor esc-vel kilépek a menüből akkor a set root='hd0,gpt7'   linux /vmlinuz   initrd /initrd.img   boot sorokkal elindítja a rendszert nyilván csak initramfs-ig mert nincs megadva a kernelnek a root fs. Tehát látja a grub a fájlrendszert és amikor a set root sor után megadom a configfile /boot/grub/grub.cfg-t akkor kis gondolkodás és újrindul a gép, nincs semmi üzenet.

Valami tippetek lehet, hogy mi a hiba, hogy ez a helyzet?

 

Lemezkiosztás:

MODEL          NAME   PTTYPE GROUP MOUNTPOINTS              LABEL                UUID

CT480BX500SSD1 sda    gpt    disk                                          
               ├─sda1 gpt    disk                                                                        ED91-DF59
               ├─sda2 gpt    disk                                          
               ├─sda3 gpt    disk                                               Windows_Root   D8EECCC3EECC9AE0
               ├─sda4 gpt    disk                                                                       B09206059205D0B0
               ├─sda5 gpt    disk  /home/jimmy/Windows_Data   Windows_Data   0ECC7BF86658CB1D
               ├─sda6 gpt    disk  [SWAP]                                  debian_swap      538735d4-bc77-4172-a2d7-bd67ba24453b
               ├─sda7 gpt    disk                                               Debian_13_test  4097b971-4d6e-45ef-b8de-8f4d183ede2c
               ├─sda8 gpt    disk  /                                            debian_root       c720cc50-d4cf-4358-904d-803fe108ec7b
               └─sda9 gpt    disk  /boot                                      Debian_BOOT    17e7cd4d-0bfa-40f9-8599-e4a18566d738
 

  • 714 megtekintés

( jimmy399 v | 2025. 10. 01., sze – 20:55 )

A google-t túrva se lettem okosabb sajnos.

Annyi még hogy az os-probert futtatva megtalálja a debian 13-at és indítható is a 12-es menüjéből de így configfile móddal nem lehet mert újraindítás lesz belőle.

Valamikor régen lehetett olyat hogy maga a grub ír ki debug kimenetet amikor bootol de nem találom sehol hogy hogyan lehetne bekapcsolni, hátha írna valamit min akad el.

( jimmy399 v | 2025. 10. 02., cs – 05:31 )

Elindítva a gépet és a google segedelmével beállítottam a grub parancssorban a set debug=all változót, ezeket írja mielőtt újraindulna a gép:

 

commands/wildcards.c:535: no expansion needed

commands/wildcards.c:594: paths[0] = '/boot/grub/grub.cfg'

kern/verifiers.c:214: string configfile  /boot/grub/grub.cfg, type: 2

commands/efi/tpm.c:235: log_event, pcr = 8, size = 0x1e, grub_cmd: configfile /boot/grub/grub.cfg

 

ezután megáll egy pillanatra és újraindul a gép. Nem ír semmit sem közben...

( Nextra | 2025. 10. 02., cs – 11:13 )

Nem vagy egyedül.
Nálam újraindítás során magát az UEFI BIOST tölti be. Viszont  ezzel a megoldással, ugyan betölti a megfelelő rendszer grubját, de magát a rendszert aztán nem. Tehát valami még hiányzik.
 

menuentry 'OpenMandriva (ezen: /dev/nvme0n1p9)' --class openmandriva $menuentry_id_option 'osprober-gnulinux-simple-913f45b3-4447-4e41-a040-e60473e0f4bc' {
    insmod part_gpt
    insmod ext2
#    search --no-floppy  --fs-uuid --set=root 913f45b3-4447-4e41-a040-e60473e0f4bc
#    configfile /boot/grub2/grub.cfg
    search --no-floppy --root-dev-only --fs-uuid --set=dev 913f45b3-4447-4e41-a040-e60473e0f4bc
    set prefix=($dev)/boot/grub2
    export $prefix
    configfile $prefix/grub.cfg
}

A Linux Mintet sem tölti be, viszont a Fedorát igen. A fő rendszerem a Mageia de keresem az alternatívát. Sajnos nagyon lemaradtak, holott stabil disztró szó se róla.

Persze, minden permutációban, amiben lehet és ami volt a google találatok és fórumok között, de semmi sem segített, elkezd tölteni megáll egy pillanatra és beadja a BIOS gyorsbillentyűket, hogy melyikkel mit lehet csinálni, mintha rendszerindításkor ESC gombot nyomnék. HP laptop.

( NevemTeve | 2025. 10. 05., v – 12:14 )

Ha sikerülne egy lilo-t tenni rá, akkor lenne némi esély...

( muszike | 2025. 10. 06., h – 05:27 )

Nem lehet, hogy a BIOS-ban be van állítva a Secure Boot?
Debian nincs aláírva...

( jimmy399 v | 2025. 10. 12., v – 00:23 )

Ami furcsa, hogy van egy másik UEFI-s és egy BIOS-os (MBR-es lemez) gép és ott csont nélkül megy a configfile konfigban a grub, ki érti ezt...

Szerintem csak simán elbaszott BIOS implementációról van szó. Anno, amikor a saját RAM-ból futó rendszeremet teszteltem, mindig akadt 5-ből egy (szar BIOS-ú) gép, amin nem bootolt be. Live rendszereknél is gyakran tapasztalható, van, hogy bootloader változtatással jó, vagy pl. előfordult, hogy a partíciót nem tudta kezelni, mert túlságosan "hátul" volt a lemezen. De pl. van, hogy 5 gépből egyen ugyanaz az USB eszköz nem bootol. Én tipikusan Acer és HP notikon emlékszem ilyenekre.

( Friczy v | 2025. 10. 12., v – 10:06 )

Nem lehet, hogy a chainloadolt grub.cfg-ben van valami, ami nem tetszik neki?

A generált grub.cfg rész egy az egyben megegyezik a 40_custom résszel? A grub leírása szerint a chainload valahogy így néz ki a grub.cfg-ben:

menuentry "Windows" {
	insmod chain
	insmod ntfs
	set root=(hd0,1)
	chainloader +1
}

Nyilván az insmod ntfs nem kell, az nem kérdés, és a chainloader sem ebben a formában, hanem úgy, ahogy nálad van, de kérdés, hogy az insmod chain nem hiányzik-e a generált .cfg file-ból.

Igen, egy az egyben megegyezik a 40_custom fájlba beírt résszel.

 

menuentry "Debian 13" {

                configfile (hd0,gpt5)/boot/grub.cfg

}

 

Ennyi lenne az egész, ami nem történik meg mert ahogy ez a sort kiválasztom a grub menüben, kis szünet és újraindul a gép és mintha megnyomtam volna a F11-et a boot menühöz, behozza az ideiglenes boot menüt.

( hrgy84 | 2025. 10. 12., v – 17:54 )

Szerkesztve: 2025. 10. 12., v – 17:55

Nekem van egy kicsit off kérdésem, de mégis ide kapcsolódik.

Van két rendszer a gépemen:

  • Arch Linux, natív partíciókon (sda2 mondjuk), ez a fő rendszerem
  • Gentoo Linux, LVM-en, ez egy játszós cucc

Mindkét rendszernek saját különálló disken saját /boot partíciója van (ext3 mindkettő), de a BIOS-om hülyesége miatt nem tudom a Gentoo-t EFI-vel bootoltatni, mert nem enged az "elsődleges" disken kívül máshonnan felvenni EFI boot entry-t, hiába van jól megformázva a másik disken a fájlrendszer meg megtagelve, meg apámfasza, nem ismeri fel, hiába van benn efibootmgr-ben, nem működik. Ezt nem kell megoldani, elfogadtam, hogy ez a gép ilyen.

Ami a problémám: eddig úgy bootoltunk, hogy az Arch szépen felismerte a Gentoo-nak a kerneleit, meg a Gentoo által generált grub.cfg-ből felvette a dolgokat, és bedolgozta a saját grub.cfg -jébe, a Gentoo egy teljesen first-class citizenként jelent meg az Arch boot menüjében.

Most újra kellett telepítenem az Archot, és ez valamiért már nem működik jól, és nem tudok rájönni, hogy miért. Az biztos, hogy az os-prober csak a gépen levő Windowst ismeri fel, valamiért a Gentoo-t nem.

Felraktam az LVM eszközeit is, aktív a volume, még fel is csatoltam neki, hogy hátha - de semmi.

A korábbi setupot kb 2 éve raktam össze, és nem emlékszem, hogy kellett volna vele mágiázni, működött magától.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Bocs, de erre literálisan leírtam a választ a kérdésben.

>  de a BIOS-om hülyesége miatt nem tudom a Gentoo-t EFI-vel bootoltatni, mert nem enged az "elsődleges" disken kívül máshonnan felvenni EFI boot entry-t

Nem szeretném, ha a Gentoo véletlenül összecseszné nekem az Arch EFI partícióját/mappáját, és ott már amúgy is Arch + Windows van, elég szűk sajnos a hely. Ráadásul macerásabbá is tenné a bootot, mert sose emlékszem melyik gépen mit kell nyomni az F11-F12-F8-akármi kombinációk közül (alsó hangon 2 különböző gépen dolgozok napi szinten, ezen felül +200 gépet adminisztrálok a melóban, +3-at pedig itthon, és sajnos van bőven választék, frászért nem tud ez standard lenni...). Eddig működött az, hogy az os-prober felismerte a Gentoo-t, ezt szeretném megoldani. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( NevemTeve | 2025. 10. 13., h – 10:12 )

Szerkesztve: 2025. 10. 13., h – 10:19

Nosztalgia: a nagy megkönnyítés előtt így ment: nincs (u)efi, nincs secure boot. BIOS-sal megbeszéljük, hogy melyik az elsődleges diszk. Amelyen még a Windows telepítése előtt/alatt/után létrehozunk egy dedikált 'boot' partíciót, ahová minden disztró kernelét (és initial-ram-diszkjét) tesszük. Lilo-nevű varázseszköznek elmagyarázzuk a lehetősékeket (/etc/lilo.conf), azután öröm-boldogság. (Bővebben itt a #111 környéke: https://forum.index.hu/Article/showArticle?t=9028250 )