Arch Linux

[tlw. gelöst] Grub-EFI hängt bei Loading initial ramdisk

Werner

Seit einigen Wochen habe ich ein merkwürdiges Problem bei einem Desktop-Rechner mit Grub-EFI-Installation.
Ohne mir ersichtlichen Grund scheitert im Abstand von einigen Tagen der Bootvorgang, er bleibt an dieser Stelle hängen:

Loading initial ramdisk...

Er bleibt plötzlich immer dann hängen, wenn ich den Default-Eintrag Archlinux per Enter-Taste auswähle. Warte ich die 5 Sekunden Timeout ab, läuft der Bootvorgang fehlerfrei durch.
Leider gibt es an dieser Stelle ja noch keine Logs und ich versuche dem per try and error vergebens auf die Spur zu kommen.

mkinitcpio -p linux

repariert es nicht.
Starte ich von einer Live-CD und installiere via arch-chroot Grub-EFI komplett neu, kann ich erst einmal (einige Tage) wieder mit der Enter-Taste starten. Dann tritt das gleiche Problem jedoch wieder auf.

Ich habe versuchsweise mal den systemd-HOOK in die mkinitcpio.conf aufgenommen:

HOOKS="base udev systemd autodetect modconf block filesystems keyboard fsck"

Das schien zunächst einmal wirksam zu sein, aber seit ~~gestern~~ heute morgen habe ich das Problem ohne für mich erkennbaren äußeren Anlass erneut.

In der Kernelzeile von /etc/default/grub habe ich keine Besonderheiten:

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""

Diese Laufwerke/Partitionen sind vorhanden:

$ lsblk -o 'NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT,MODEL'
NAME     SIZE FSTYPE      TYPE MOUNTPOINT MODEL
sda    238,5G             disk            Samsung SSD 850
├─sda1    35G ext4        part /
├─sda2   200G ext4        part /home
└─sda3   512M vfat        part /boot
sdb      1,8T crypto_LUKS disk            WDC WD20EZRX-00D
sr0     1024M             rom             iHAS124   F

Habt ihr eine Idee, wo ich weiter ansetzen könnte?
Könnte das ein Problem mit dem aktuellen Kernel sein? Sollte ich testweise mal auf LTS wechseln?

Im Prinzip sind die 5 Sekunden Timeout ja kein großer Verlust an Lebenszeit 🙂
Aber ich würde doch sehr gerne herausfinden, woran es liegt.

Gruß, Werner

Greg

LTS kernel kannst du probieren. Durch die Installation hast du dann 2 kernel zur Auswahl.

Statt mit grub zu booten könntest du vielleicht gummiboot bzw systemd-boot benutzen. Auch das dürfte den Uefieintrag von grub nicht zerstören.
Ich gehe mal davon aus, dass deine /dev/sda3 eine efiboot vom Typ ef00 ist.

========
systemd Loader installieren:
bootctl install

Datei anlegen:
nano /boot/loader/loader.conf Hinweis: diese Datei wird nur benutzt zum Laden des default Linux.

timeout3
default uefi_arch

Achtung bei default uefi_arch muss eine dazugehörige Datei angelegt werden mit uefi_arch.conf

Datei anlegen:
nano /boot/loader/entries/uefi_arch.conf

title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=/dev/sda1 rw

Für fallback anlegen:
/boot/loader/entries/uefi_arch_fallback.conf

title Arch Linux fallback
linux /vmlinuz-linux
initrd /initramfs-linux-fallback.img
options root=/dev/sda1 rw
====

Werner

Greg schriebIch gehe mal davon aus, dass deine /dev/sda3 eine efiboot vom Typ ef00 ist.

Ja, das ist alles OK. Und eine Grub-EFI-Neuinstallation läuft fehlerfrei durch:

# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=arch_grub --recheck --debug

Ich hatte auch schon gedacht, ob es an diesem Bug FS#47941 liegen könnte. Kann aber m. E. nicht sein, da /boot/initramfs-linux.img und /boot/intel-ucode.img an Ort und Stelle liegen.

Greg schriebStatt mit grub zu booten könntest du vielleicht gummiboot bzw systemd-boot benutzen. Auch das dürfte den Uefieintrag von grub nicht zerstören.

Die Idee, es mit systemd-boot zu versuchen, gefällt mir sehr gut. Da ich bisher ausschließlich mit Grub gearbeitet habe, stehe ich aber trotz deiner präzisen Anleitung noch etwas auf der Leitung…
Ich starte also von der Live-CD, wechsele in‘s arch-chroot und arbeite deine Anleitung ab, richtig? Aber was mache ich mit grub? Muss ich grub nicht vor dem bootctl install deinstallieren?

Gruß, Werner

Greg

Wenn du dein Sytem zum laufen bekommen würdest, dann könntest du das direkt von da aus machen. Da es aber nicht läuft kannst du das über die chrootgeschichte machen.
Uefi hat jetzt eine Eintragung von grub. Diese bleibt erhalten auch nach der Installation des systemd-loaders. Es kommt die systemd-loader Eintragung nach bootctl install hinzu. So hättest du danach die Wahl ob du per grub oder systemd-loader starten willst. Der systemd-loader bietet auch die Möglichkeit mehrere Booteinträge einzurichten und diese dann auszuwählen. z.b: Arch-Linux normaler Kernel, Arch-Linux normaler kernel fallback und Arch-Linux lts kernel ... Ob dann auf dieser Ebene auch der grub drinsteht kann ich leider nicht sagen. Versuch macht kluch. Du kannst das Resultat ja hier mal posten.

Zum Schluss kannst du noch mit efibootmgr die Eintragungen auflisten lassen. Dann wirst du auch den Grubeintrag sehen. efibootmgr mußt du noch zusätzlich installieren.

Eine komplette Kurzanleitung ist noch hier beschrieben:
https://forum.archlinux.de/viewtopic.php?pid=343265#p343265

Gruß aus DN
Greg

Werner

Vielen Dank Greg!

Der Start mit systemd-boot läuft im Vergleich zu grub rasend schnell – aber irgendwo ist noch der Wurm drin.
Ich erhalte kein Auswahlmenü, auch nicht via Space-Taste. Und der Eintrag vom Timeout 3 Sekunden wird aus irgendeinem Grund nicht übernommen:

# efibootmgr
BootCurrent: 0006
Timeout: 1 seconds
BootOrder: 0006,0000,0007,0003,0001
Boot0000* arch_grub
Boot0001* Hard Drive
Boot0003* CD/DVD Drive
Boot0006* Linux Boot Manager
Boot0007* UEFI OS

Hast du ‘ne Idee, wo der Fehler liegen könnte?

Gruß, Werner

Greg

Werner schrieb...Hast du ‘ne Idee, wo der Fehler liegen könnte? Gruß, Werner

Ist wirklich die Raute vorne weg? (Hat schonmal einer vergessen bzw nicht beachtet).
====
Datei anlegen:
nano /boot/loader/loader.conf Hinweis: diese Datei wird nur benutzt zum Laden des default Linux.

timeout3
default uefi_arch

====
Am Sonsten poste mal die Dateien hier rein.

Das das schneller als bei grub ist, liegt daran, dass der kernel direkt geladen wird. Das soll ja auch der größte Vorteil von UEFI sein.

Werner

Greg schriebIst wirklich die Raute vorne weg? (Hat schonmal einer vergessen bzw nicht beachtet).

Ja, solche Flüchtigkeitsfehler kenne ich von mir gut 🙂

# bootctl status
System:
     Firmware: UEFI 2.31 (American Megatrends 4.655)
  Secure Boot: disabled
   Setup Mode: user

Loader:
      Product: systemd-boot 228
    Partition: /dev/disk/by-partuuid/8979f1cc-921b-4982-8c6c-28ca00f881c1
         File: └─/EFI/SYSTEMD/SYSTEMD-BOOTX64.EFI

Boot Loader Binaries:
          ESP: /dev/disk/by-partuuid/8979f1cc-921b-4982-8c6c-28ca00f881c1
         File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 228)
         File: └─/EFI/Boot/BOOTX64.EFI (systemd-boot 228)

Boot Loader Entries in EFI Variables:
        Title: Linux Boot Manager
           ID: 0x0006
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/8979f1cc-921b-4982-8c6c-28ca00f881c1
         File: └─/EFI/SYSTEMD/SYSTEMD-BOOTX64.EFI

        Title: arch_grub
           ID: 0x0000
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/8979f1cc-921b-4982-8c6c-28ca00f881c1
         File: └─/EFI/ARCH_GRUB/GRUBX64.EFI

        Title: UEFI OS
           ID: 0x0007
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/8979f1cc-921b-4982-8c6c-28ca00f881c1
         File: └─/EFI/BOOT/BOOTX64.EFI

# nano /boot/loader/loader.conf
timeout 3
default uefi_arch

Sowohl "timeout3" als auch "timeout 3" probiert.

# nano /boot/loader/entries/uefi_arch.conf
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=/dev/sda1 rw

# # nano /boot/loader/entries/uefi_arch_fallback.conf
title Arch Linux fallback
linux /vmlinuz-linux
initrd /initramfs-linux-fallback.img
options root=/dev/sda1 rw

Gruß, Werner

Greg

Moin Werner,
jetzt weiß ich auch nicht mehr weiter. Vielleicht ist bei deinem uefi im Rechner noch eine Stellschraube drin.
Ich habe mal die Virtualbox mit uefi angeschmissen. Auch noch mit grub drauf. Das sieht alles wie bei dir aus.

#efibootmgr
BootCurrent:0001
BootOrder:0000,0001,0002,0003
Boot0000* EFI DVD/CDROM
Boot0001* EFI Hard Drive
Boot0002* EFI Internal Shell
Boot0003* arch_grub

Wobei der EFI Hard Drive das angelegte Zeug vom systemd-loader ist.

bootctl status
System:
Firmware:...
Secure Boot: disabled
Setup Mode: user

Loader:
Product: systemd-boot 228
Partition: /dev/disk/by-partuuid/...
File: /EFI/BOOT/BOOTX64.EFI

Boot Loader Binaries:
ESP: /dev/disk/by-partuuid/...
File: /EFI/systemd/systemd-bootx64.efi (systemd-boot 228)
File: /EFI/boot/BOOTX64.EFI (systemd-boot 228)

Boot Loader Entries in EFI Variables:
 Title: arch_grub
ID: 0x0003
Status: active, boot-order
Partition: /dev/disk/by-partuuid/...
File: /EFI/arch_grub/grubx64.efi
#

Zwischen grub und systemd loader kann ich nur im uefi bootmanager auswählen. grub taucht nicht beim systemd loader auf. Wobei der grub bei mir auch nicht funktioniert.

error: no such device: ad....
loading Linux core repo kernel ...
error: no such partition.
loading initial ramdisk ...
alloc magic is broken at ..
aborted. Press any key to exit.

Ich habe gedacht, das es an lvm liegen könnte. Mit dem experimentiere ich gerade was rum. Uefi ,lvm und systemd-boot funktionieren bei mir sehr gut ohne grub.

Gruß Greg

Nachtrag:
Ich kann noch einen draufsetzen:
Weitere Bootmöglichkeit wäre mit efistub. Falls man den zusätzlich einrichtet, so stört auch dieser den zuvor gemachten Eintragungen nicht. Also systemd-boot, grub bleiben erhalten.
Man kann dann das jeweilige Booten per uefimanager des Mainboards aussuchen so wie es auch zwischen grub und systemd der Fall ist.

Eintrag für Arch Linux per uefistub:

efibootmgr -c -d /dev/sda -p 1 -l \vmlinuz-linux -L "Arch Linux efistub" -u "initrd=/initramfs-linux.img root=/dev/disk/by-label/p_arch rw"

Eintrag für Arch Linux fallback per uefistub:

efibootmgr -c -d /dev/sda -p 1 -l \vmlinuz-linux -L "Arch Linux efistub" -u "initrd=/initramfs-linux-fallback.img root=/dev/disk/by-label/p_arch rw"

Wobei ich hier mit der Rootbezeichnung die Labels verwendet habe. Die Rootpartition ist mit p_arch bezeichnet worden.
So nebenbei, Das benutzen von Labels hat den Vorteil, dass es kein Unterschied gibt zwischen reellen Partitionen und den Partitionen per lvm.
Wer lvm benutzt soll noch an die Hooks Eintragung denken. (siehe wiki lvm)

Werner

Danke für deinen Aufwand, Greg!

Greg schriebDas sieht alles wie bei dir aus.

Wobei der efibootmgr bei dir kein gar kein Timeout auswirft…
Im englischen Forum habe ich einen Thread gefunden, in dem jemand in etwa das gleiche Problem beschreibt – mit dem Unterschied, dass bei mir das Menü hartnäckig nicht erscheint. Ich habe mir gedacht, ich setze den Timeout mal mit dem efibootmgr. Also alles nochmal auf Anfang:

# bootctl install
Created "/boot/EFI/systemd".
Created "/boot/EFI/Boot".
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/EFI/systemd/systemd-bootx64.efi".
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/EFI/Boot/BOOTX64.EFI".
Created EFI boot entry "Linux Boot Manager".

# efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0002,0006,0000,0007,0003,0001
Boot0000* arch_grub
Boot0001* Hard Drive
Boot0002* Linux Boot Manager
Boot0003* CD/DVD Drive
Boot0006* Linux Boot Manager
Boot0007* UEFI OS

# efibootmgr -t 5
BootCurrent: 0000
Timeout: 5 seconds
BootOrder: 0002,0006,0000,0007,0003,0001
Boot0000* arch_grub
Boot0001* Hard Drive
Boot0002* Linux Boot Manager
Boot0003* CD/DVD Drive
Boot0006* Linux Boot Manager
Boot0007* UEFI OS

Der Timeout bleibt so auch nach Neustart erhalten. Aber statt Auswahlmenü bleibt der Bildschirm 5 Sekunden schwarz, dann geht‘s mit einem freundlichen "Welcome to Linux!" weiter.
Im Moment bin ich ratlos, bleibe aber dran. Ich glaube, wenn's erstmal richtig läuft, gefällt mir systemd-boot sehr gut. Solange nutze ich die Möglichkeit, es parallel zu Grub einfach an- und ausschalten zu können, um dem Grub-Problem weiter auf die Spur zu kommen.

Wenn’s überhaupt an Grub liegt…
Die Meldung "Initiale Ramdisk wird geladen …" kommt ja auf jeden Fall von Grub. Danach sollte es mit der Meldung "Systemd 228… weitergehen (geht mir zu schnell zum vollständigen Lesen). Hat der Kernel an der Stelle bereits übernommen?

Merkwürdig finde ich jedenfalls, dass der Start im Grub-Auswahlmenü per Enter-Taste erstmal vorübergehend wieder funktioniert, sobald ich Grub-EFI erneut frisch installiert habe. Im Moment versuche ich, ob das Problem mit einem Neuschreiben der grub.cfg vor dem Ausschalten/Neustarten ausbleiben wird:

alias neustart='sudo grub-mkconfig -o /boot/grub/grub.cfg && reboot'

Gruß, Werner

PS: Oh, deinen Nachtrag habe ich gerade erst gesehen – da muss ich mich erstmal reindenken. Im Laufe des Nachmittags muss ich zur Arbeit und werde meinen Desktoprechner erst am Mittwoch wieder greifbar haben – inschallah… 🙂

Edit:
Ein Teilerfolg! Im UEFI des Asus-Mainboards war die Anzeige des Boot-Logo deaktiert. Nur wenn es aktiviert ist, wird auch das systemd-boot Auswahlmenü erfolgreich angezeigt. Schade, weil der Vorteil des schnellen Starts von systemd-boot ist durch die pausierende Anzeige des Asus-Splashscreens verspielt…

Greg

Ha, efibootmgr -t 5 kannte ich noch garnicht.
Hat aber mit dem timeout des systemd-boot nichts zu tun. Da das an anderer Stelle steht, nämlich in /boot/loader/loader.conf
Habe ich direkt ausprobiert.
Funktioniert aber in der virtualbox nicht. Der rutscht direkt zum ersten Booteintrag ohne zu warten. Eigenart von virtualbox???
Vielleicht kriege ich das auch noch raus an was das liegt.

Werner

Ja, stimmt. Da ich jetzt das systemd-boot-Auswahlmenü habe, sehe ich auch, dass die Einstellungen in der /boot/loader/loader.conf tatsächlich übernommen worden sind – egal, was der efibootmgr angibt.
Lösche ich den Timeout mit "efibootmgr -T", ist der Timeout-Eintrag erstmal verschwunden und steht nach Neustart wieder auf "Timeout: 1 seconds". Das Bootmenü zeigt jedoch unabhängig davon die in der loader.conf festgelegten 3 Sekunden an.

Gruß, Werner

Edit 20.02.2015: Das System läuft nun einige Tage mit systemd-boot und das Problem tritt auch nach diversen Neu- und Kaltstarts nicht mehr auf. Außerdem gefällt mir systemd-boot sehr gut; die Einfachheit und friedliche Koexistenz mit grub finde ich beeindruckend.
Was das eigentliche grub-Problem anbetrifft, warte ich mit erneuten Tests erstmal auf den Kernel 4.5.

Vielen Dank nochmal!