Boot error ins BIOS

[hendrikL]

ähm, ja.

Boot Reihenfolge ändern?

sdb als erstes dann sda?

[Penyelam]

Dann müsste ich Grub auf sdb1 installieren?

[hendrikL]

Ne, wo ist den /boot/efi beheimatet, auf welcher Festplatte, ist dies nirgends so nutzt das System kein UEFI, sondern legacy BIOS, dann müsste grub-install /dev/sdX ausgeführt werden, wobei sdX halt entsprechende Festplatte ist von der gebootet wird und das BIOS entsprechend eingestellt werden, in diesem falle halt csm bzw, legacy.

[Penyelam]

Beim fdisk -l kommt folgende Meldung, auch nach einem fdisk /dev/sdb mit write kommt sie wieder.

Code: [Select]

Device          Start        End    Sectors   Size Type
/dev/sdb1        4096     618495     614400   300M EFI System
/dev/sdb2      618496 1808593063 1807974568 862,1G Linux filesystem
/dev/sdb3  1808593064 1953520064  144927001  69,1G Linux swap
GPT PMBR size mismatch (6416023 != 61439999) will be corrected by write.
The backup GPT table is not on the end of the device.
könnte das was damit zu tun haben?

[hendrikL]

Es scheint ja grub installiert worden zu sein, und zwar nach sdb.

Ich würde jetzt erst einmal im BIOS nachschauen, ob auch sdb als Erstes genommen wird, bzw das efi welches dort hin installiert ist, also die Bootreihenfolge anschauen!

[hendrikL]

Was noch helfen könnte, ist es uns die Ausgabe von "lsblk -l"  und "efibootmgr -v" zu zeigen.

[Penyelam]

Danke, mache ich wenn ich wieder Zuhause bin.
Bin gerade für drei Wochen in Urlaub, hatte gehofft den Rechner vorher zum Laufen zu bringen.

[Penyelam]

Melde mich aus dem Urlaub zurück 
Hier die Ausgabe:

Code: [Select]

root@chroot-helper:/# lsblk -l
NAME  MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0   7:0    0     3G  1 loop
loop1   7:1    0     4K  1 loop
sda     8:0    0 931,5G  0 disk
sda1    8:1    0   300M  0 part /boot/efi
sda2    8:2    0 862,1G  0 part /
sda3    8:3    0  69,1G  0 part
sdb     8:16   0   3,6T  0 disk
sdb1    8:17   0     3T  0 part /home/manfred/data
sdb2    8:18   0   654G  0 part
sdc     8:32   1  29,3G  0 disk
sdc1    8:33   1   154K  0 part
sdc2    8:34   1   2,8M  0 part
sdc3    8:35   1   3,1G  0 part
root@chroot-helper:/# efibootmgr -v
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0004,0000,0003,0002,0005,0006
Boot0000* siduction_2019.1.0    HD(1,GPT,a48ff773-6774-e642-a579-7d5e5785a217,0x1000,0x96000)/File(\EFI\SIDUCTION_2019.1.0\GRUBX64.EFI)
Boot0002* siduction     HD(1,GPT,a48ff773-6774-e642-a579-7d5e5785a217,0x1000,0x96000)/File(\EFI\SIDUCTION\GRUBX64.EFI)
Boot0003* UEFI OS       HD(1,GPT,a48ff773-6774-e642-a579-7d5e5785a217,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0004* UEFI: Intenso Alu Line 8.07, Partition 2      PciRoot(0x0)/Pci(0x1,0x3)/Pci(0x0,0x0)/USB(10,0)/HD(2,GPT,dc3243a7-854f-4c05-a7fd-94540304da60,0x174,0x1680)..BO
Boot0005* Hard Drive    BBS(HD,,0x0)/VenHw(5ce8128b-2cec-40f0-8372-80640e3dc858,0200)..GO..NO..........S.a.n.D.i.s.k. .S.S.D. .G.5. .B.I.C.S.4...................\.,.@.r.d.=.X..........A.................................>..Gd-.;.A..MQ..L.0.2.5.2.7.1.0.8.7.4.8.1. . . . . . . . ........BO..NO..........W.D.C. .W.D.4.0.E.Z.R.Z.-.0.0.G.X.C.B.0...................\.,.@.r.d.=.X..........A.................................>..Gd-.;.A..MQ..L. . . . .W. .-.D.C.W.7.C.6.K.X.R.6.6.F.X........BO
Boot0006* USB KEY       BBS(HD,,0x0)/VenHw(5ce8128b-2cec-40f0-8372-80640e3dc858,0b00)..GO..NO........o.I.n.t.e.n.s.o. .A.l.u. .L.i.n.e. .8...0.7...................\.,.@.r.d.=.X..........A.............................&..Gd-.;.A..MQ..L.9.D.7.6.4.E.1.0........BO
root@chroot-help


[ro_sid]

BootOrder: 0004,0000,0003,0002,0005,0006
Boot0000* siduction_2019.1.0    HD(1,GPT,a48ff773-6774-e642-a579-7d5e5785a217,0x1000,0x96000)/File(\EFI\SIDUCTION_2019.1.0\GRUBX64.EFI)
Boot0002* siduction     HD(1,GPT,a48ff773-6774-e642-a579-7d5e5785a217,0x1000,0x96000)/File(\EFI\SIDUCTION\GRUBX64.EFI)
Boot0003* UEFI OS       HD(1,GPT,a48ff773-6774-e642-a579-7d5e5785a217,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0004* UEFI: Intenso Alu Line 8.07, Partition 2      PciRoot(0x0)/Pci(0x1,0x3)/Pci(0x0,0x0)/USB(10,0)/HD(2,GPT,dc3243a7-854f-4c05-a7fd-94540304da60,0x174,0x1680)..BO
Boot0005* Hard Drive    BBS(HD,,0x0)/VenHw(5ce8128b-2cec-40f0-8372-80640e3dc858,0200)..GO..NO..........S.a.n.D.i.s.k. .S.S.D. .G.5. .B.I.C.S.4...................\.,.@.r.d.=.X..........A.................................>..Gd-.;.A..MQ..L.0.2.5.2.7.1.0.8.7.4.8.1. . . . . . . . ........BO..NO..........W.D.C. .W.D.4.0.E.Z.R.Z.-.0.0.G.X.C.B.0...................\.,.@.r.d.=.X..........A.................................>..Gd-.;.A..MQ..L. . . . .W. .-.D.C.W.7.C.6.K.X.R.6.6.F.X........BO
Boot0006* USB KEY       BBS(HD,,0x0)/VenHw(5ce8128b-2cec-40f0-8372-80640e3dc858,0b00)..GO..NO........o.I.n.t.e.n.s.o. .A.l.u. .L.i.n.e. .8...0.7...................\.,.@.r.d.=.X..........A.............................&..Gd-.;.A..MQ..L.9.D.7.6.4.E.1.0........BO

BootOrder: 4=Intenso - und wenn der nicht eingesteckt ist?
Vermutlich würden/werden nur 0=siduction_2019.1.0 und 2=siduction "grub" booten (und damit Siduction).
3=UEFI OS scheint auf "Secure Boot" getrimmt zu sein, könnte aber vielleicht auch "grub" booten.
Bei 3,4,5,6 verstehe ich die Bedeutung von ..BO am Ende der Zeile nicht.

Falls die BootOrder nicht gleich geändert werden soll, würde ich die Tastenkombination suchen, die eine (UEFI-)Bootselection  aus dem UEFI/BIOS heraus erlaubt (bei Thinkpads oft F12) und früh in der Rechner-Boot-Phase drücken. Dann sollten alle Optionen von 0 bis 6 (außer 1, das scheint zu fehlen, vielleicht deinstalliert/gelöscht) zur Auswahl stehen = alle mit "*" markierten.

"siduction_2019.1.0" und "siduction" sollten dann das entsprechende Betriebssystem (sauber) booten. Falls das klappt, kann man dann mit "efibootmgr" die Reihenfolge neu/anders anordnen.

[Penyelam]

Wenn im Bios UEFI ausgewählt ist, habe ich nur eine Platte zur Auswahl:
"UEFI Hard Disk: siduction_2019.1.0"

Was mich irritiert, ist dass der chroot helper mal die Datenplatte als sda und mal als sdb sieht.
Während die Systemplatte (SSD) keinen Identifier hat.
Normalerweise ist die SSD sda und die Datenplatte sdb.
  [ You are not allowed to view this attachment ]  

[ro_sid]

Was mich irritiert, ist dass der chroot helper mal die Datenplatte als sda und mal als sdb sieht.

Ist zwar nicht schön, kann aber vorkommen. Je nachdem welche HD "zuerst" gesehen wird. Kann an (verschiedenen) Controllern oder "Hochlauf-Eigenschaften" (z.B. Kaltstart/Warmstart) etc. liegen.

Während die Systemplatte (SSD) keinen Identifier hat.

Ist sie denn per SATA angeschlossen? Falls ja, verstehe ich es nicht, falls nein, wird vielleicht nur NVME nicht angezeigt.

Was mich irritiert, ist, daß nur eine Boot-Variante angeboten wird, obwohl beide "Siduction-Boots" auf derselben EFI-Partition liegen.
Nach einem erfolgreichen Boot bitte einfach mal nachsehen, ob auch Pfad und Datei (/boot/efi)/EFI/SIDUCTION/GRUBX64.EFI existieren. Falls nicht würde das erklären, warum der zweite Eintrag fehlt.
Genauso sollte "UEFI OS" angeboten werden, wenn dort /EFI/BOOT/BOOTX64.EFI existiert.

[Penyelam]

Hab's nochmal versucht, jetzt wird das EFI Verzeichnis nicht gefunden.

Code: [Select]

root@chroot-helper:/# ls -l /boot/efi/EFI
insgesamt 12
drwx------ 2 root root 4096 22. Dez 2020  boot
drwx------ 2 root root 4096 18. Sep 10:32 siduction
drwx------ 2 root root 4096 22. Dez 2020  siduction_2019.1.0

root@chroot-helper:/# ls -l /boot/efi/EFI/siduction
insgesamt 136
-rwx------ 1 root root 139264 12. Okt 12:11 grubx64.efi

root@chroot-helper:/# ls -l /boot/efi/EFI/siduction_2019.1.0/
insgesamt 128
-rwx------ 1 root root 131072 22. Dez 2020  grubx64.efi

root@chroot-helper:/# grub-install
x86_64-efi wird für Ihre Plattform installiert.
grub-install: Fehler: EFI-Verzeichnis kann nicht gefunden werden.

Aber der anschließende update-grub läuft ohne Fehlermeldung.

Code: [Select]

root@chroot-helper:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.5.2-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.5.2-1-siduction-amd64
Found linux image: /boot/vmlinuz-6.4.14-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.4.14-1-siduction-amd64
Found linux image: /boot/vmlinuz-6.4.9-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.4.9-1-siduction-amd64
Found linux image: /boot/vmlinuz-6.4.7-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.4.7-1-siduction-amd64
Found linux image: /boot/vmlinuz-6.4.6-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.4.6-1-siduction-amd64
Found memtest86+ 64bit EFI image: /boot/memtest86+x64.efi
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings

Nach Neustart kommt aber immer noch:
"error: symbol `grub_is_lockdown` not found."

Die SSD ist übrigens eine M.2 SATA

[ro_sid]

Gut, danke.

Hab's nochmal versucht, jetzt wird das EFI Verzeichnis nicht gefunden.

Das verstehe ich nicht. In den folgenden "ls" taucht es doch jeweils auf!? Sieht auch richtig aus.
[Wenn alles wieder funktioniert würde es sich lohnen, das /EFI/boot Verzeichnis nach (/boot/efi)/BOOT zu kopieren (generischer Boot der Festplatte auch ohne Eintrag in den UEFI Variablen).]

Und ein paar neue Erkenntnisse:
grubx64.efi in EFI/siduction ist neu(er) (12. Oktober) als die Datei in EFI/siduction_2019.1.0 (20 Dez 2020).

Wenn im Bios UEFI ausgewählt ist, habe ich nur eine Platte zur Auswahl:
"UEFI Hard Disk: siduction_2019.1.0"

Wenn das weiterhin so ist wird also das "alte" grubx64.efi gebootet und daher der Fehler

"error: symbol `grub_is_lockdown` not found."

Er "paßt" nicht zur "Grub-Installation" in /boot/grub. Dasselbe dürfte derzeit für "BOOTX64.EFI" in /EFI/boot gelten!
Ich habe allerdings keine Idee, warum "siduction" (ohne 2019) nicht im UEFI Boot-Menu auftaucht. Dort ist ja der neue "grub".

grub-install: Fehler: EFI-Verzeichnis kann nicht gefunden werden.

Auch das verstehe ich nicht. Gerade vorher wurde es doch beim "ls" an der "richtigen Stelle" /boot/efi gefunden!
Aber wenn "grub-install" funktioniert, wie gerade vorher einmal (12. Oktober), wird es per Default unter dem Namen "siduction" im Verzeichnis "siduction" (nicht siduction_2019.1.0) installiert. Das ist "normal". Man müßte Parameter anpassen, damit es unter dem Namen "siduction_2019.1.0" in gleichnamigen Verzeichnis installiert wird.

Im jetzigen Zustand wäre es wichtig, den UEFI "siduction"-Eintrag booten zu können! Der ist (einigermaßen) aktuell.

Die SSD ist übrigens eine M.2 SATA

Dann muß sie auch als ein /dev/sd? "Device" in /dev auftauchen. Oh Moment, mein Fehler. Sie ist vermutlich das jeweils "andere" "sd?" Gerät? Es gibt keine zweite (HD-)Festplatte? Dann verstehe ich lediglich nicht, warum bei der SSD (jeweils) kein "sd?" auftaucht. Das ist aber (zumindest derzeit) wohl vernachlässigbar.

Als nächstes muß "siduction" beim Booten auftauchen!
Falls gar nichts anderes hilft, mit Hilfe von "efibootmgr" in "BootOrder" "0002" vor "0000" einsortieren.
[Der siduction_2019.1.0 Eintrag dürfte für nichts mehr gut sein - zu alter grub. Ich würde ihn derzeit aber noch nicht löschen.]

Eine nachträgliche Idee: Falls grub-install nach/in(!) einem "chroot" ausgeführt wird, muß /boot/efi (auch) dort, also im neuen /(root) unter /boot/efi auftauchen!

Viel Erfolg!

[Penyelam]

Danke für die Tipps,
mit ".. nicht gefunden" hab ich mich auf die Meldung von grub-install bezogen, sorry hab ich mich wohl schlecht ausgedrückt.

Ich hab mal grub64.efi von siduction nach siduction_2019.1.0 kopiert.
Jetzt kommt immerhin schon mal ein Boot-Menü. Leider mit uralten Kernels zur Auswahl, die nicht mehr existieren.

Wenn ich mit efibootmgr die Reihenfolge ändere, wird sie zwar angezeigt, aber nach Neustart hab ich wieder die alte.

[ro_sid]

Ich hab mal grub64.efi von siduction nach siduction_2019.1.0 kopiert.
Jetzt kommt immerhin schon mal ein Boot-Menü. Leider mit uralten Kernels zur Auswahl, die nicht mehr existieren.

Normalerweise - und ich vermute, das ist hier genauso - sucht grub nach /boot/grub/grub.cfg für das Bootmenu. Wenn /boot nicht in eine Partition ausgelagert ist, was möglich ist, aber nicht oft praktiziert wird und worauf das "lsblk -l" keinen Hinweis liefert, befindet sich /boot in der Partition des /(root)-Verzeichnisses. Da der unten dargestellte grub-Verlauf ganz offensichtlich neue Kernel installiert, die aber wohl im Menu nicht auftauchen, muß das /(root)-Verzeichnis von siduction_2019.1.0 ein anderes sein, als das von siduction.
Wenn es also gelingt entweder "siduction" doch anzuzeigen (bevorzugt!) oder "siduction_2019.1.0" das /(root)-Verzeichnis von "siduction" unterzuschieben, sollten die neuen Kernel auswählbar sein.

Wenn ich mit efibootmgr die Reihenfolge ändere, wird sie zwar angezeigt, aber nach Neustart hab ich wieder die alte.

Das "darf" nicht sein. Ich weiß, das ist wenig tröstlich, da es hier ja passiert, deutet für mich aber auf ein Problem beim Eintragen der UEFI Variablen hin. Mir paßt es ja auch nicht , daß "siduction" gar nicht auftaucht. Ist eventuell "secure boot" aktiviert und verhindert eine Änderung der UEFI Variablen?

Nach einer Änderung per efibootmgr, welcher Art auch immer, muß diese erhalten bleiben, bis sich ein anderes Betriebssystem - oder auch eine Selektion im UEFI Setup - daran zu schaffen macht. Sonst bedeutet das, daß die Änderung gar nicht durchgeführt wurde.

Vielleicht führt das zu neuen Erkenntnissen.