[erledigt] UEFI-Installation: "grub-install dummy" hängt

Du kommst mit der Installation nicht voran oder willst noch was nachfragen? Schau auch in den "Tipps und Tricks"-Bereich.
NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von NAB » 20.03.2018 21:55:34

So wie dein Text sich liest, hat das options snd-hda-intel model=auto das Touchpad kaputt gemacht. Ein Zusammenhang will mir zwar nicht einleuchten ... aber vielleicht gibt es einen?

Der Herr aus dem Amazon Review berichtet, dass "F2" bei ihm wieder ging, nachdem er alle Partitionen gelöscht hat. Das halte ich für übertrieben. Ich vermute, irgendwas in der Efi ESP Partition stört das UEFI. Was tummelt sich da denn bei dir so? ls -laR /boot/efi/*

Hast du das BIOS-Update noch im Hinterkopf? Win10 als Testversion gäbe es gratis ...
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von hikaru » 20.03.2018 22:20:05

NAB hat geschrieben: ↑ zum Beitrag ↑
20.03.2018 21:55:34
So wie dein Text sich liest, hat das options snd-hda-intel model=auto das Touchpad kaputt gemacht. Ein Zusammenhang will mir zwar nicht einleuchten ... aber vielleicht gibt es einen?
Ja, sollte auch so klingen - als vage Vermutung.
Es war allerdings letztendlich PEBKAC. Fn+F8 ist Mute, Fn+F7 ist Touchpad abschalten. Letzteres überlebt Reboots. Und da bin ich versehentlich draufgekommen als ich die Lautsärketasten durchprobiert habe.
NAB hat geschrieben: ↑ zum Beitrag ↑
20.03.2018 21:55:34
Der Herr aus dem Amazon Review berichtet, dass "F2" bei ihm wieder ging, nachdem er alle Partitionen gelöscht hat. Das halte ich für übertrieben. Ich vermute, irgendwas in der Efi ESP Partition stört das UEFI. Was tummelt sich da denn bei dir so? ls -laR /boot/efi/*
Das kann ich momentan leider nicht prüfen, denn der Herr hat mich dazu inspiriert, die EFI-Partition von Xubuntu aus zu löschen. Jetzt geht F2 ins UEFI wieder, aber ich brauche jetzt auch wieder rEFInd um Debian zu booten.
Kann ich irgendwie eine neue funktioniernde EFI-Partition anlegen ohne Debian neuinstallieren zu müssen? Mit Gparted eine neue Fat32-Partition anzulegen und von Debian aus grub-install --removable [--no-nvram] (mit und ohne geladene efivars/efivarfs) abzusetzen hilft offenbar nicht. rEFInd bietet dazu auch keine offensichtliche Methode.
NAB hat geschrieben: ↑ zum Beitrag ↑
20.03.2018 21:55:34
Hast du das BIOS-Update noch im Hinterkopf? Win10 als Testversion gäbe es gratis ...
Windows kommt mir nicht mehr in's Haus.
Da würde ich das Gerät eher wieder zurückgeben, falls ich ein UEFI-Update machen müsste für das ich Win10 brauche.

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von smutbert » 20.03.2018 22:38:27

Das BIOS-Setup aufrufen funktioniert auch nicht aus grub ("System Setup" oder fwsetup in der Grub-shell)?
Gibt es vielleicht eine einfache Möglichkeit das BIOS/UEFI zurückzusetzen samt cmos/nvram-Reset?


Wenn du doch wieder ins BIOS kommst und das einen Punkt zum Update bietet, dann findest du das neue BIOS oft in Form einer *.bin-Datei, wenn du das Windows-BIOS-Updateinstallationsprogramm in einem Archivmanager aufmachst (oft auch verschachtelt in einem weiteren zip-Archiv oder eine exe-Datei in dem ganzen heruntergeladenen Windows-BIOS-Updateinstallationsprogramm).
hikaru hat geschrieben: ↑ zum Beitrag ↑
20.03.2018 22:20:05
Kann ich irgendwie eine neue funktioniernde EFI-Partition anlegen ohne Debian neuinstallieren zu müssen? Mit Gparted eine neue Fat32-Partition anzulegen und von Debian aus grub-install --removable [--no-nvram] (mit und ohne geladene efivars/efivarfs) abzusetzen hilft offenbar nicht. rEFInd bietet dazu auch keine offensichtliche Methode.
Eine Partition anlegen, Typ auf ef00 setzen, mit FAT formatieren, in die fstab einen neuen Eintrag für die (neue) UUID und den Mountpoint /boot/efi schreiben und das Dateisystem mounten – danach sollte dem grub-install eigentlich nichts mehr im Wege stehen.
(ich mach das mit gdisk, aber mit gparted sollte es genauso funktionieren. Ob der richtige Partitionstyp überhaupt eine Rolle spielt hängt von der konkreten UEFI-Implementierung ab.)

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von hikaru » 20.03.2018 23:26:47

smutbert hat geschrieben: ↑ zum Beitrag ↑
20.03.2018 22:38:27
Eine Partition anlegen, Typ auf ef00 setzen, mit FAT formatieren, in die fstab einen neuen Eintrag für die (neue) UUID und den Mountpoint /boot/efi schreiben und das Dateisystem mounten – danach sollte dem grub-install eigentlich nichts mehr im Wege stehen.
Bis auf den Partitionstyp hatte ich das vorher schon so. Die Partition hatte ich in gparted angelegt und mit fat32 formatiert. Der Partitionstyp ließ sich dort nicht festlegen.
Jetzt habe ich mit cfdisk den Partitionstyp (wurde in cfdisk als "Windows basic data" angezeigt) in "EFI system" geändert und Debian ist jetzt wieder bootfähig. Allerdings ist nun das UEFI nicht mehr aufrufbar. Wenn ich in cfdisk den Partitionstyp auf "Windows basic data" (oder "MBR partition scheme", oder "Microsoft reserved") zurücksetze, dann bleibt Debian weiterhin bootfähig, aber das UEFI trotzdem unzugänglich.

Hier ist noch der aktuelle Stand von fdisk -l:

Code: Alles auswählen

# fdisk -l
Disk /dev/sda: 119,2 GiB, 128035676160 bytes, 250069680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 4C2AAA8E-E3BB-48E1-8367-A4BF56E02A17

Device      Start      End  Sectors  Size Type
/dev/sda1    2048   999423   997376  487M EFI System
/dev/sda2  999424 20531199 19531776  9,3G Linux filesystem


GPT PMBR size mismatch (976773167 != 976773166) will be corrected by w(rite).
The backup GPT table is corrupt, but the primary appears OK, so that will be used.
Disk /dev/sdb: 465,8 GiB, 500107861504 bytes, 976773167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 7A108545-D817-4626-8617-D6689B367060

Device         Start       End   Sectors   Size Type
/dev/sdb1       2048    129023    126976    62M EFI System
/dev/sdb2     129024    131071      2048     1M BIOS boot
/dev/sdb3     131072 962322431 962191360 458,8G Linux root (x86-64)
/dev/sdb4  962322432 970711039   8388608     4G Linux swap
/dev/sdb5  970711040 976773119   6062080   2,9G Lenovo boot partition
sda ist die interne Debian-SSD, sdb die per USB angeschlossene Endless-HDD (die trotz der korrupten Backup-GPT bootet).

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von NAB » 21.03.2018 00:43:06

hikaru hat geschrieben: ↑ zum Beitrag ↑
20.03.2018 23:26:47
Die Partition hatte ich in gparted angelegt und mit fat32 formatiert. Der Partitionstyp ließ sich dort nicht festlegen.
Gparted nennt das "Flag" (Partition -> Manage Flags). In diesem Fall das Boot-Flag (auch wenn es bei GPT kein Flag mehr ist).

Ich vermute, es ist irgendwas auf deiner "EFI System" Partition, das das UEFI stört, sobald es das entdeckt. Eventuell in Verbindung mit einem NVRAM-Eintrag, den es automatisch erstellt.

Schau doch mal nach, was auf deiner "EFI System" Partition drauf ist.

Und frag mal efibootmgr, was es im NVRAM so entdeckt.

Interessant wäre weiterhin, was auf der "EFI System" Partition der Endless Platte drauf ist (genauer gesagt, wo es ist)

Deine Endless Platte hat übrigens in der Tat eine BIOS Boot Partition - neben der EFI Partition. Warum auch immer ...
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von hikaru » 21.03.2018 08:16:12

Das ist auf der Debian-EFI-Partition:

Code: Alles auswählen

# find /boot/efi/ -exec ls -l {} +
-rwx------ 1 root root 121856 Mär 20 23:06 /boot/efi/EFI/BOOT/BOOTX64.EFI

/boot/efi/:
insgesamt 4
drwx------ 3 root root 4096 Mär 20 21:44 EFI

/boot/efi/EFI:
insgesamt 4
drwx------ 2 root root 4096 Mär 20 21:44 BOOT

/boot/efi/EFI/BOOT:
insgesamt 120
-rwx------ 1 root root 121856 Mär 20 23:06 BOOTX64.EFI
Und das auf der von Endless:

Code: Alles auswählen

# find /mnt/ -exec ls -l {} +
-rwxr-xr-x 1 root root 1157984 Mai 13  2017 /mnt/EFI/BOOT/bootx64.efi
-rwxr-xr-x 1 root root   71616 Mai 13  2017 /mnt/EFI/BOOT/fallback.efi
-rwxr-xr-x 1 root root     118 Mai 13  2017 /mnt/EFI/endless/BOOT.CSV
-rwxr-xr-x 1 root root 6390480 Mai 13  2017 /mnt/EFI/endless/grubx64.efi
-rwxr-xr-x 1 root root 1160592 Mai 13  2017 /mnt/EFI/endless/MokManager.efi
-rwxr-xr-x 1 root root 1157984 Mai 13  2017 /mnt/EFI/endless/shim.efi

/mnt/:
insgesamt 2
drwxr-xr-x 4 root root 2048 Mai 13  2017 EFI

/mnt/EFI:
insgesamt 4
drwxr-xr-x 2 root root 2048 Mai 13  2017 BOOT
drwxr-xr-x 2 root root 2048 Mai 13  2017 endless

/mnt/EFI/BOOT:
insgesamt 1202
-rwxr-xr-x 1 root root 1157984 Mai 13  2017 bootx64.efi
-rwxr-xr-x 1 root root   71616 Mai 13  2017 fallback.efi

/mnt/EFI/endless:
insgesamt 8510
-rwxr-xr-x 1 root root     118 Mai 13  2017 BOOT.CSV
-rwxr-xr-x 1 root root 6390480 Mai 13  2017 grubx64.efi
-rwxr-xr-x 1 root root 1160592 Mai 13  2017 MokManager.efi
-rwxr-xr-x 1 root root 1157984 Mai 13  2017 shim.efi
efibootmgr von Debian aus:

Code: Alles auswählen

# efibootmgr 
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,2001,2002,2003
Boot0000* HDD: SanDisk SDSSDHP128G
Boot2001* EFI USB Device
Boot2002* EFI DVD/CDROM
Boot2003* EFI Network
und von Endless:

Code: Alles auswählen

$ sudo efibootmgr
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0000,2001,2002,2003
Boot0000* HDD: SanDisk SDSSDHP128G
Boot0001* Linux
Boot2001* EFI USB Device
Boot2002* EFI DVD/CDROM
Boot2003* EFI Network

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von NAB » 21.03.2018 16:06:18

Schade ... ich hatte "gehofft", dass sich auf deiner EFI Partition mehrere Bootloader befinden und einer davon stört, aber da ist nur ein einziger, im removable media path EFI/BOOT/BOOTX64.EFI

Unter Debian findet sich auch kein zusätzlicher Eintrag im NVRAM, den ich als Störer in Verdacht hatte.

Endless OS geht auf Nummer Sicher, das hat einen Bootloader im removable media path EFI/BOOT/bootx64.efi, einen eigenen unter EFI/endless/grubx64.efi und sogar einen Secure Boot Bootloader unter EFI/endless/shim.efi. Ich vermute weiterhin, dass es auch einen BIOS Bootloader installiert. Aber welchen es nutzt, lässt sich an den Dateien nicht ablesen.

Interessant ist, dass Endless OS irgendwie einen zusätzlichen Boot-Eintrag ins NVRAM zaubert:
Boot0001* Linux
Mit efibootmgr --verbose könntest du dir anzeigen lassen, wo der hinführt, aber ich wüsste nicht, wie uns das weiterbringen sollte.

Somit macht Endless OS eigentlich alles, vom dem ich den Verdacht hatte, dass es dein UEFI stört - ohne es zu stören. Debian hingegen macht nichts davon ... und ich tappe weiterhin im Dunkeln.

Der einzige Unterschied, den ich sehe:
Debian:
EFI/BOOT/BOOTX64.EFI
Endless:
EFI/BOOT/bootx64.efi

Debian könnte man natürlich mal in Kleinbuchstaben umbenennen, aber das wär schon arg blöde, wenn es daran liegt.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von smutbert » 21.03.2018 16:16:20

Bei efibootmgr hilft der Schalter -v damit ausgegeben wird, welche .efi-Datei geladen wird.

Soweit ich mir das (als weitgehend "Secure Boot Unkundiger") zusammenreime, verweist der Linux-Booteintrag auf das signierte shim.efi, das seinerseits versucht ein signiertes grubx64.efi zu starten, für dessen Signatur es eine eigene Anwendung zur Schlüsselverwaltung gibt, die sich ebenfalls vom uefi aus aufrufen lässt (MokManager.efi).
fallback.efi wird wahrscheinlich aufgerufen, wenn shim.efi am Laden eines (signierten) grub scheitert, aber ich habe keine Idee was das dann machen könnte.

Zur möglichen Problemlösung habe ich nichts gefunden und leider auch keine Idee. Unter Ubuntu gab es offensichtlich dasselbe Problem [1] und dort wie auch in anderen Threads ist der häufigste Vorschlag den BIOS-Modus/CSM zu verwenden.
Das einzige, was ich sonst noch gefunden, habe ist der Vorschlag die grubx64.efi nach EFI/Boot/fallback.efi zu kopieren. Ich glaube aber nicht, dass das etwas mit dem Problem zu tun hat, verstehe aber auch nicht warum das hier [2] auch bei deaktiviertem Secure Boot als Lösungsvorschlag empfohlen wird (vielleicht ist es einen Versuch wert?).


[1] https://forum.ubuntuusers.de/topic/grub ... nstallati/
[2] https://wiki.ubuntuusers.de/EFI_Problem ... fi-Fehlers

edit:
Entschuldigung, wenn ich einiges wiederholt habe, was NAB bereits geschrieben hat, aber ich den letzten Beitrag übersehen.

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von NAB » 21.03.2018 16:29:22

smutbert hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 16:16:20
Zur möglichen Problemlösung habe ich nichts gefunden und leider auch keine Idee. Unter Ubuntu gab es offensichtlich dasselbe Problem [1]
smutbert, worauf willst du hinaus? Wenn ich das richtig verstanden habe, gibt es kein Boot-Problem mehr. Debian bootet über den removable media path.

Dafür gibt es ein F2-Problem (das UEFI lässt sich nicht aufrufen).

P.S.: hikaru, ein simples "Akku raus" wäre natürlich mal einen Versuch wert.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von smutbert » 21.03.2018 16:42:57

Ja, aber das F2-Problem muss doch an irgendeinem der Unterschiede am Inhalt der ESP liegen und die offensichtlichen Unterschiede, dass Endless OS Secure Boot bietet und dafür automatisch ein Booteintrag angelegt wird, erscheint mir als Ursache weiter hergeholt. als die Möglichkeit, dass das Acer-UEFI gerne eine fallback.efi auf der ESP hätte.
(wenn ich mir das was ich schreibe noch einmal durchlese glaube ich es selbst auch nicht mehr, aber irgendetwas muss es sein)

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von hikaru » 21.03.2018 16:57:44

NAB hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 16:06:18
Interessant ist, dass Endless OS irgendwie einen zusätzlichen Boot-Eintrag ins NVRAM zaubert:
Boot0001* Linux
Mich irritiert, dass beide Male die interne Sandisk-SSD angezeigt wird, obwohl doch Endless von der externen HDD (Seagate glaube ich) gebootet wird.
NAB hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 16:06:18
Mit efibootmgr --verbose könntest du dir anzeigen lassen, wo der hinführt, aber ich wüsste nicht, wie uns das weiterbringen sollte.
[..]
Debian könnte man natürlich mal in Kleinbuchstaben umbenennen, aber das wär schon arg blöde, wenn es daran liegt.
Probiere ich nachher beides, und auch das:
smutbert hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 16:16:20
Das einzige, was ich sonst noch gefunden, habe ist der Vorschlag die grubx64.efi nach EFI/Boot/fallback.efi zu kopieren. Ich glaube aber nicht, dass das etwas mit dem Problem zu tun hat, verstehe aber auch nicht warum das hier [2] auch bei deaktiviertem Secure Boot als Lösungsvorschlag empfohlen wird (vielleicht ist es einen Versuch wert?).
NAB hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 16:29:22
P.S.: hikaru, ein simples "Akku raus" wäre natürlich mal einen Versuch wert.
Wird umständlich bei dem Gerät. [1] So verzweifelt bin ich noch nicht. Ich bin ja eigentlich der Meinung, dass selbst der schlimmstmöglichst verhunzte Bootloader nicht das BIOS/UEFI beeinträchtigen darf, bzw. falls doch, die Sache handwerklich einfach zu lösen sein sollte. Aber vielleicht bin ich da einfach zu altmodisch.
30 Sekunden Powerknopf drücken habe ich schon diverse Male probiert.


[1] https://nl.hardware.info/reviews/7490/4 ... e-techniek

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von smutbert » 21.03.2018 17:09:02

hikaru hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 16:57:44
[…]
Mich irritiert, dass beide Male die interne Sandisk-SSD angezeigt wird, obwohl doch Endless von der externen HDD (Seagate glaube ich) gebootet wird.[…]
Booteintrag Boot0000, also "HDD: SanDisk SDSSDHP128G" dürfte der automatisch erstellte Booteintrag zum Booten des removeable media path sein. (Mangels eines besseren Namens nimmt das UEFI eben als Bezeichnung für diesen Booteintrag das Gerät auf dem der removeable media path gefunden wurde. "efibootmgr -v" sollte also zeigen, dass Boot0000 auf EFI/BOOT/BOOTX64.efi auf der internen SSD verweist.)

Im Beispiel mit dem gebooteten Endless OS sieht man anhand von BootOrder auch, dass zuerst vom wohl ebenfalls automatisch erstellten Boot0001 gebootet wird und erst der zweite Versuch mit dem removeable media path erfolgt wäre.
Boot0001 sollte also auf EFI/endless/shim.efi oder die Kopie EFI/BOOT/bootx64.efi auf der externen HDD verweisen.

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von NAB » 21.03.2018 17:18:18

smutbert hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 16:42:57
Ja, aber das F2-Problem muss doch an irgendeinem der Unterschiede am Inhalt der ESP liegen
Oder an deren Größe, Offset oder irgendeiner anderen Kuriosität ...
smutbert hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 16:42:57
als die Möglichkeit, dass das Acer-UEFI gerne eine fallback.efi auf der ESP hätte.
(wenn ich mir das was ich schreibe noch einmal durchlese glaube ich es selbst auch nicht mehr, aber irgendetwas muss es sein)
Ah, doch, stimmt, an irgendwas muss es ja liegen. Ich würd's dann nur systematisch angehen und Datei für Datei von Endless rüberkopieren. Und vorher mal EFI/BOOT/BOOTX64.EFI da wegschieben, so dass die Partition völlig leer ist, und schauen, was dann passiert (hikaru müsste dann wieder mit refind booten).

Mich wundert noch das hier:
viewtopic.php?f=12&t=169061&start=15#p1168694
irgendwas muss sich das UEFI irgendwo merken, auch wenn die EFI-Partition keine EFI-Partition mehr ist.
hikaru hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 16:57:44
Ich bin ja eigentlich der Meinung, dass selbst der schlimmstmöglichst verhunzte Bootloader nicht das BIOS/UEFI beeinträchtigen darf,
Tut's aber manchmal, bis hin zum Totalschaden, grad wieder passiert:
https://itsfoss.com/ubuntu-17-10-bios-bug/

P.S.:
smutbert hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 17:09:02
Im Beispiel mit dem gebooteten Endless OS sieht man anhand von BootOrder auch, dass zuerst vom wohl ebenfalls automatisch erstellten Boot0001 gebootet wird und erst der zweite Versuch mit dem removeable media path erfolgt wäre.
Boot0001 sollte also auf EFI/endless/shim.efi oder die Kopie EFI/BOOT/bootx64.efi auf der externen HDD verweisen.
Wenn der Boot-Eintrag wirklich automatisch erstellt wird, woher weiß das UEFI dann, dass er "Linux" heißt? (Könnte natürlich ein Feature von Secure-Boot sein, das ich nicht kenne). Und wenn der Boot-Eintrag automatisch erstellt wird, warum wird er nicht erstellt, wenn Debian bootet? (Ich gehe davon aus, dass die Endless HDD dabei weiterhin am USB-Port hing)

hikaru, wie bootest du überhaupt das Endless OS, wenn F2 nicht geht?
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von hikaru » 21.03.2018 19:00:34

smutbert hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 17:09:02
"efibootmgr -v" sollte also zeigen, dass Boot0000 auf EFI/BOOT/BOOTX64.efi auf der internen SSD verweist.)
Sieht wohl so aus:

Debian:

Code: Alles auswählen

BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,2001,2002,2003
Boot0000* HDD: SanDisk SDSSDHP128G      PciRoot(0x0)/Pci(0x12,0x0)/Sata(0,0,0)/HD(1,GPT,f72ce1d4-210b-4267-9d64-34e991a61ef7,0x800,0xf3800)RC
Boot2001* EFI USB Device        RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network   RC
Endless:

Code: Alles auswählen

BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0000,2001,2002,2003
Boot0000* HDD: SanDisk SDSSDHP128G	ACPI(a0341d0,0)PCI(12,0)03120a00000000000000HD(1,800,f3800,f72ce1d4-210b-4267-9d64-34e991a61ef7)RC
Boot0001* Linux	HD(1,800,1f000,7e4d7ae3-0837-41bb-8f04-4c61291b261e)File(\EFI\endless\shim.efi)RC
Boot2001* EFI USB Device	RC
Boot2002* EFI DVD/CDROM	RC
Boot2003* EFI Network	RC
Secure Boot ist im UEFI abgeschaltet und während der Debian-Ausgabe war die Endless-HDD nicht angeschlossen, ebensowenig wie beim update-grub oder grub-install von Debian aus.


Es sieht so aus, als ob sich das UEFI am /boot/efi/EFI/BOOT/BOOTX64.EFI auf der Debian-Partition stört. Nehme ich nur die Datei unter dem Namen weg, dann komme ich in's UEFI, aber Debian bootet nicht mehr. Gleiches, wenn ich die Datei in FALLBACK.EFI umbenenne.
Den Namen in Kleinbuchstaben zu ändern ändert hingegen nichts, ebensowenig wie ein Kopieren der Datei auf fallback.efi.
Was ich nicht verstehe ist, dass doch genau das aber gestern den größten Teil des Abends funktioniert haben muss. Ich habe mich da noch nicht für die Inhalte von /boot/efi interessiert, aber die müssen doch auch von Debians grub-install gestammt haben und da ging sowohl UEFI als auch Booten.
NAB hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 17:18:18
hikaru hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 16:57:44
Ich bin ja eigentlich der Meinung, dass selbst der schlimmstmöglichst verhunzte Bootloader nicht das BIOS/UEFI beeinträchtigen darf,
Tut's aber manchmal, bis hin zum Totalschaden, grad wieder passiert:
https://itsfoss.com/ubuntu-17-10-bios-bug/
Ja, das weiß ich auch. Aber wer entwickelt einen Standard in dem sowas überhaupt möglich ist und traut sich dann auch noch, den zu veröffentlichen? Und was haben die Leute geraucht, die diesen Standard dann auch noch implementieren?
NAB hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 17:18:18
hikaru, wie bootest du überhaupt das Endless OS, wenn F2 nicht geht?
Ganz zu Anfang, als ich Secure Boot im UEFI abgeschaltet habe, habe ich auch das F12-Bootmenü aktiviert. Dieses funktioniert unabhängig davon, ob ich gerade mit F2 in's UEFI komme oder nicht.

owl102

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von owl102 » 21.03.2018 19:08:13

hikaru hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 19:00:34
Aber wer entwickelt einen Standard in dem sowas überhaupt möglich ist und traut sich dann auch noch, den zu veröffentlichen?
Der Standard ist (IMHO) ok. Nur die Umsetzung ist bei manchen Herstellern mangelhaft oder gar ungenügend. Ich persönlich finde es erschreckend, einen so ungetesteten und unausgereiften Quark auch noch an die PC-Hersteller zu verticken. Und die liefern das auch noch aus, vermutlich ohne eigene Tests. Ist ja auch alles egal, hauptsache MS-Windows bootet. :roll:

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von smutbert » 21.03.2018 22:19:43

NAB hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 17:18:18
[…]
Wenn der Boot-Eintrag wirklich automatisch erstellt wird, woher weiß das UEFI dann, dass er "Linux" heißt? (Könnte natürlich ein Feature von Secure-Boot sein, das ich nicht kenne). Und wenn der Boot-Eintrag automatisch erstellt wird, warum wird er nicht erstellt, wenn Debian bootet? (Ich gehe davon aus, dass die Endless HDD dabei weiterhin am USB-Port hing)

hikaru, wie bootest du überhaupt das Endless OS, wenn F2 nicht geht?
Ich bin im Gegenteil davon ausgegangen, dass zumindest beim Booten von Debian die externe HDD nicht angeschlossen war...

Wie der Eintrag automatisch erstellt wird, weiß ich auch nicht, aber das automatische Erstellen schließe ich schlicht aus dem Auftauchen und Verschwinden des Eintrags. (und ich kenne ähnliches auch von anderen uefi-Systemen, dass sie zumindest das ursprünglich vorinstallierte System erkennen und einen Booteintrag dafür anlegen. In dem Fall ist es vielleicht sogar relativ einfach, weil shim.efi ja signiert sein muss und im BIOS/UEFI beliebige Metainformationen zum zwangsweise hinterlegten zugehörigen öffentlichen Schlüssel vorhanden sein könnten?)


Mir scheint es langsam so wäre die Behauptung aus dem Thread im Ubuntuforum, den ich in der ersten Antwort verlinkt habe, dass Secure Boot aktiviert sein muss richtig sein könnte (da habe ich zwar nur als Lösung für das Hängenbleiben bei der grub-Installation verstanden, aber es wäre kein Wunder, wenn das auch das F2-Problem lösen würde).
Allerdings selbst wenn es stimmt, weiß ich nicht wie man unter Debian mit dieser Information umgeht. Sich den kompletten grub samt secure boot shim von endless OS (oder auch Ubuntu?) ausborgen, klingt mir nicht sehr verlockend und eigentlich weiß ich auch gar nicht wie sich die Kombination von signiertem Bootloader und unsigniertem Kernel überhaupt verhält (sonst wäre ja vielleicht auch eine refind-Installation auf der SSD ein möglicher Workaround).

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von NAB » 21.03.2018 22:48:10

smutbert, kurzfristig ging ja alles, nämlich hier:
viewtopic.php?f=12&t=169061#p1168614
Das ist der Punkt, den ich momentan interessant finde. Über Alternativen kann man natürlich auch nachdenken ... da würd ich mir erst Refind angucken und dann Secure Boot (und die Pakete eher von Ubuntu klauen). Einen BIOS Boot von GPT könnte man auch noch testen.
hikaru hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 19:00:34
Endless:

Code: Alles auswählen

Boot0001* Linux	HD(1,800,1f000,7e4d7ae3-0837-41bb-8f04-4c61291b261e)File(\EFI\endless\shim.efi)RC
Diesen Eintrag finde ich immer noch interessant. Im Gegensatz zu smutbert habe ich Zweifel, dass der automatisch vom UEFI erzeugt wird. Ich würd mich ja freuen, wenn das UEFI mir beliebige Bootloader auf der ESP Partition automatisch zusammensucht, aber leider tun sie das bei mir nie. Und warum er sich ausgerechtnet den \endless\shim.efi rauspicken sollte, ist mir auch nicht klar. Mag natürlich sein, dass das ein besonderer Service von Secure Boot ist, das ist aber eigentlich ausgeschaltet.

hikaru, wie ist das jetzt eigentlich genau? Wenn du Endless OS bootest (mit der Debian SDD angeschlossen), dann ist dieser Eintrag da. Wenn du Debian bootest, ohne Endless HDD, dann ist dieser Eintrag nicht da. Und wenn du Debian bootest, mit angeschlossener Endless HDD, was passiert dann?
hikaru hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 19:00:34
Was ich nicht verstehe ist, dass doch genau das aber gestern den größten Teil des Abends funktioniert haben muss. Ich habe mich da noch nicht für die Inhalte von /boot/efi interessiert, aber die müssen doch auch von Debians grub-install gestammt haben und da ging sowohl UEFI als auch Booten.
Deinen Aufzeichnungen nach hat Xubuntu das UEFI kaputt gemacht (oder eventuell Endless). Fragt sich, was ein Live System am UEFI rumzufummeln hat, aber irgendwas muss es verändert haben.

Ich habe die dünne Theorie, dass es im UEFI eventuell unsichtbare Einträge gibt. Dass der Endless Eintrag zum Beispiel dauerhaft gespeichert ist, aber nur angezeigt wird, wenn die Endless HDD vorhanden ist. Ebenso könnte Xubuntu so einen Eintrag hinterlassen haben und dieser stört nun irgendwie, auch wenn man ihn nicht sehen kann. Ein Live System würde hier übrigens den removable media path /EFI/BOOT/BOOTX64.EFI benutzen - genau den, der jetzt plötzlich Ärger macht.

Was würde das bedeuten? Weiß nicht so genau. Es würde zumindest bedeuten, dass man doch (irgendwie) feste Einträge im UEFI speichern kann. Eventuell kann man sie dann auch wieder löschen. (Apropos, gibt es ein "Reset to defaults" im UEFI? Oder ein "Reset NVRAM"?). Eventuell kann man dann auch seinen eigenen konfliktfreien Eintrag hinzufügen, zum Beispiel /EFI/debian/grubx64.efi und dafür könnte man das störende /EFI/BOOT/BOOTX64.EFI löschen.
hikaru hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 19:00:34
Aber wer entwickelt einen Standard in dem sowas überhaupt möglich ist und traut sich dann auch noch, den zu veröffentlichen?
Deswegen heißt es Extensible Firmware Interface. Du darfst die Erweiterung einbauen, dass es mittendrin irreparabel abschmiert. Man sollte solche Extra-Featues nur groß auf die Verpackung schreiben.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von hikaru » 22.03.2018 00:35:54

smutbert hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 22:19:43
Mir scheint es langsam so wäre die Behauptung aus dem Thread im Ubuntuforum, den ich in der ersten Antwort verlinkt habe, dass Secure Boot aktiviert sein muss richtig sein könnte (da habe ich zwar nur als Lösung für das Hängenbleiben bei der grub-Installation verstanden, aber es wäre kein Wunder, wenn das auch das F2-Problem lösen würde).
Das habe ich vorhin mal probiert. Nachdem ich /boot/efi/EFI/BOOT/BOOTX64.EFI in Debian entfernt hatte, kam ich ja wieder in's UEFI. Da habe ich dann im UEFI /Boot/Secure Boot [Enabled|Disabled] aktiviert. Daraufhin kam ich sowohl mit als auch ohne BOOTX64.EFI in's UEFI, aber Debian bootete von der SSD in keinem Fall, sondern nur via rEFInd.
Nach dem Aktivieren von Secure Boot werden im UEFI folgende Optionen aktiv geschaltet:

Code: Alles auswählen

/Security/Secure Boot Mode/Erase all Secure Boot Settings: [Enter] -> [Yes|No]
/Security/Secure Boot Mode/Select an UEFI file as trusted for executing: [Enter] -> [Minimaler Dateibrowser der wohl alle gefundenen EFI-Partitionen nach *.efi-Dateien durchsucht]
/Security/Secure Boot Mode/Restore Secure Boot to Factory Default: [Enter] -> [Yes|No]
Über die zweite Option habe ich dann /EFI/debian/grubx64.efi aus dem Debian-EFI registriert. Nach einem Reboot zeigte sich wieder die Acer-Grub-Shell und teilte noch vor dem Prompt mit, dass das Laden dieses Eintrags nicht erlaubt sei. Ich habe dann das Gleiche mit dem Removable-Eintrag probiert, aber weil ich dafür unkreativerweise den selben Namen verwenden wollte wurde mir das verweigert.
Da ich weder über die erste noch die dritte Option aus dem Code-Block den Debianeintrag wieder deregistrieren konnte, wollte ich da nicht weiter rumspielen, denn ich habe dunkel in Erinnerung, das so ein UEFI-Eintragsspeicher recht schnell voll sein kann.
Eine Eintrag für Endless taucht hier nicht auf.
smutbert hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 22:19:43
Allerdings selbst wenn es stimmt, weiß ich nicht wie man unter Debian mit dieser Information umgeht. Sich den kompletten grub samt secure boot shim von endless OS (oder auch Ubuntu?) ausborgen, klingt mir nicht sehr verlockend und eigentlich weiß ich auch gar nicht wie sich die Kombination von signiertem Bootloader und unsigniertem Kernel überhaupt verhält (sonst wäre ja vielleicht auch eine refind-Installation auf der SSD ein möglicher Workaround).
Sowas Ähnliches habe ich möglicherweise zwischendurch probiert. Ich hatte mal sämtliche Inhalte der Endless-EFI-Partition auf die Debian-Partition kopiert. Das wurde als Bootoption erkannt, bootete aber nicht. Danach habe ich das BOOTX64.EFI von Debian wiederhergestellt, den Rest von Endless aber belassen. Auch das bootete nicht. An die genauen Fehlermeldungen erinnere ich mich nicht. Erst als ich wieder alle Endless-Inhalte gelöscht hatte, bootete Debian wieder.

Auch ohne Secure Boot scheint /EFI/debian/grubx64.efi übrigens wirkungslos zu sein. Es geht nur mit dem Removable-Eintrag. grub-install ohne --removable blieb übrigens hängen, sowohl mit als auch ohne geblacklistetem efivars/efivarfs. /EFI/debian/grubx64.efi wurde dabei allerdings noch abgelegt.

NAB hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 22:48:10
smutbert, kurzfristig ging ja alles, nämlich hier:
viewtopic.php?f=12&t=169061#p1168614
Das ist der Punkt, den ich momentan interessant finde.
Genau das ist es, was mich momentan umtreibt. Ich weiß, DASS UEFI-Zugang UND Debian-Boot irgendwie gehen muss, denn ich habe es gesehen.
An sich ist der aktuelle Zustand kein Beinbruch, denn eigentlich muss ich ja nicht in's UEFI , und falls doch mal, weiß ich wie ich da hinkomme (BOOTX64.EFI löschen) und hinterher einfach wieder ein bootfähiges Debian kriege (BOOTX64.EFI-Backup wieder zurückspielen). Mich macht nur diese dreckige Lösung wuschig.
NAB hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 22:48:10
Und wenn du Debian bootest, mit angeschlossener Endless HDD, was passiert dann?
Zunächst mal ist dann auch das UEFI zugänglich, wenn die Endless-HDD angeschlossen ist - warum auch immer. Danke für den Vorschlag!
efibootmgr sagt in dem Fall das:

Code: Alles auswählen

# efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0001,0000,2001,2002,2003
Boot0000* HDD: SanDisk SDSSDHP128G	PciRoot(0x0)/Pci(0x12,0x0)/Sata(0,0,0)/HD(1,GPT,f72ce1d4-210b-4267-9d64-34e991a61ef7,0x800,0xf3800)RC
Boot0001* Linux	HD(1,GPT,7e4d7ae3-0837-41bb-8f04-4c61291b261e,0x800,0x1f000)/File(\EFI\endless\shim.efi)RC
Boot2001* EFI USB Device	RC
Boot2002* EFI DVD/CDROM	RC
Boot2003* EFI Network	RC
NAB hat geschrieben: ↑ zum Beitrag ↑
21.03.2018 22:48:10
Ich habe die dünne Theorie, dass es im UEFI eventuell unsichtbare Einträge gibt. Dass der Endless Eintrag zum Beispiel dauerhaft gespeichert ist, aber nur angezeigt wird, wenn die Endless HDD vorhanden ist. Ebenso könnte Xubuntu so einen Eintrag hinterlassen haben und dieser stört nun irgendwie, auch wenn man ihn nicht sehen kann. Ein Live System würde hier übrigens den removable media path /EFI/BOOT/BOOTX64.EFI benutzen - genau den, der jetzt plötzlich Ärger macht.

Was würde das bedeuten? Weiß nicht so genau. Es würde zumindest bedeuten, dass man doch (irgendwie) feste Einträge im UEFI speichern kann. Eventuell kann man sie dann auch wieder löschen. (Apropos, gibt es ein "Reset to defaults" im UEFI?
Wie gesagt, die Optionen die im UEFI nach Löschen von Einträgen aussehen, haben offenbar keinen Effekt und das mit dem Hinzufügen war auch nicht wirklich zielführend.


Info am Rande:
Acer bietet als neueste UEFI-Version 1.03 zum Download an. Auf meinem System läuft die gleiche Version.

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von NAB » 22.03.2018 18:48:42

hikaru hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 00:35:54
Da habe ich dann im UEFI /Boot/Secure Boot [Enabled|Disabled] aktiviert. Daraufhin kam ich sowohl mit als auch ohne BOOTX64.EFI in's UEFI, aber Debian bootete von der SSD in keinem Fall, sondern nur via rEFInd.
Also Refind lässt dich mit Secure Boot booten? (wobei F2 funktioniert). Das ist ja interessant. Refind sollte man im Hinterkopf behalten, das gibt's auch als Debian Paket in den Repos. Ich habe nur keine Ahnung, wie man es installiert und konfiguriert.
hikaru hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 00:35:54
Über die zweite Option habe ich dann /EFI/debian/grubx64.efi aus dem Debian-EFI registriert.
Ist dieser Eintrag "persistent"? Also ist er immer noch da? (obwohl er nicht funktioniert, da nicht signiert)

Falls er noch da ist ... und du mit aktiviertem Secure Boot Endless OS bootest (das geht doch, oder?) - zeigt der efibootmgr diesen Eintrag an? Kannst du ihn mit efibootmgr löschen?
hikaru hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 00:35:54
Da ich weder über die erste noch die dritte Option aus dem Code-Block den Debianeintrag wieder deregistrieren konnte,
*hmpf* ... das wäre so die erste leicht nachvollziehbare Fehlfunktion, die man als Bug an Acer melden könnte ...
hikaru hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 00:35:54
Nach einem Reboot zeigte sich wieder die Acer-Grub-Shell und teilte noch vor dem Prompt mit, dass das Laden dieses Eintrags nicht erlaubt sei.
Ach ja ... ist dieser komische Grub nun wirklich von Acer? Als du die Efi-Partition gelöscht hattest und er somit gar nichts zum Booten gefunden hat, erschien dieser Grub da auch?
hikaru hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 00:35:54
Danach habe ich das BOOTX64.EFI von Debian wiederhergestellt, den Rest von Endless aber belassen. Auch das bootete nicht. An die genauen Fehlermeldungen erinnere ich mich nicht. Erst als ich wieder alle Endless-Inhalte gelöscht hatte, bootete Debian wieder.
Das wird ja immer kurioser. Das klingt, als ob er wirklich den Inhalt der Efi-Partition scannt (smutberts Theorie) und den Boot verweigert, wenn er etwas findet, was ihm nicht passt. Eventuell wäre es interessant, die Endless-Dateien (und Verzeichnisse) sukzessiv zu löschen, dann wüsste man, welche Datei ihn stört - und damit auch, auf welche Datei er achtet.
hikaru hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 00:35:54
grub-install ohne --removable blieb übrigens hängen, sowohl mit als auch ohne geblacklistetem efivars/efivarfs. /EFI/debian/grubx64.efi wurde dabei allerdings noch abgelegt.
Der grubx64.efi könnte unfertig sein. Ich hab grad mal auf zwei Systemen verglichen, bei beiden ist der grubx64.efi unterschiedlich groß. Das eine System fährt / auf Raid, das andere nicht (so als Erklärungsversuch). Ist dein grubx64.efi identisch zu deinem BOOT/BOOTX64.EFI?

Hängt grub-install auch mit "--no-nvram"?
hikaru hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 00:35:54
Zunächst mal ist dann auch das UEFI zugänglich, wenn die Endless-HDD angeschlossen ist - warum auch immer. Danke für den Vorschlag!
Es wird wirklich immer kurioser ...
hikaru hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 00:35:54

Code: Alles auswählen

Boot0001* Linux	HD(1,GPT,7e4d7ae3-0837-41bb-8f04-4c61291b261e,0x800,0x1f000)/File(\EFI\endless\shim.efi)RC
Aus meiner Sicht besteht immer noch die Frage, ob das UEFI diesen Pfad irgendwo fest gespeichert hat und nur einblendet, wenn er existiert, oder ob dieser Pfad jedes mal dynamisch neu erzeugt wird. Wenn er wirklich dynamisch neu erzeugt wird, dann frage ich mich, warum er ausgerechnet \endless\shim.efi nimmt und nicht BOOT\BOOTX64.EFI. Wenn er hingegen fest gespeichert ist, dann wäre auch die UUID (7e4d7ae3- ...) fest gespeichert. Das würde erklären, warum das UEFI zufrieden ist, wenn es \endless\shim.efi auf der richtigen UUID entdeckt und sich sperrt, wenn \endless\shim.efi auf der falschen UUID liegt.

Dabei fällt mir das Xubuntu wieder ein und die Frage, was es angerichtet haben könnte. Kannst du das mal anstöpseln, dann Debian booten und den efibootmgr befragen? Wenn du dabei einen Pfad entdeckst, der nicht der removable media path ist, dann versuche den mal mit dem efibootmgr zu löschen.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von hikaru » 22.03.2018 23:22:04

NAB hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 18:48:42
Also Refind lässt dich mit Secure Boot booten? (wobei F2 funktioniert).
Das habe ich gerade probiert:
rEFInd-Stick dran und versucht in's EFI zu kommen, um Secure Boot einzuschalten. Das klappte nicht.
Also rEFInd-Stick und Endless-HDD angestöpselt und ich komme in's UEFI. Dann habe ich Secureboot aktiviert und ohne Eingriff in den Bootprozess mit rEFInd-Stick aber ohne Endless-HDD gebootet und es kam der Debian-Grub hoch, nicht der von Acer und auch nicht rEFInd.
Langsam habe ich das Gefühl, dass die Secure-Boot-Option im UEFI zwar irgendwas hin- und herschaltet, das teilweise das Verhalten beim Boot beeinflusst, dass aber Secure Boot an sich nicht für den Unterschied verantwortlich ist.
NAB hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 18:48:42
hikaru hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 00:35:54
Über die zweite Option habe ich dann /EFI/debian/grubx64.efi aus dem Debian-EFI registriert.
Ist dieser Eintrag "persistent"? Also ist er immer noch da? (obwohl er nicht funktioniert, da nicht signiert)
Jetzt ist er weg. :?
Vielleicht brauchte es den Poweroff über Nacht oder so. Es kann sein, dass ich gestern Abend beim Testen nur Reboots gemacht habe.
NAB hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 18:48:42
Ach ja ... ist dieser komische Grub nun wirklich von Acer? Als du die Efi-Partition gelöscht hattest und er somit gar nichts zum Booten gefunden hat, erschien dieser Grub da auch?
Soweit ich das beurteilen kann, kommt diese Grub-Shell immer dann hoch, wenn sonst nichts zum Booten gefunden wird.
Und ja, ich glaube die ist wirklich von Acer. Erst kommt das Acer-Logo wie man es schon aus Legacy-Zeiten zum Verstecken des POST kennt, dann wird über das Acer-Logo die Grub-Shell eingeblendet. Das Acer-Logo ist hier also das Hintergrundbild von Grub. Und es lässt sich grafisch kein Übergang zwischen POST und Grub ausmachen.
NAB hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 18:48:42
Ist dein grubx64.efi identisch zu deinem BOOT/BOOTX64.EFI?
Ja. Die Dateigrößen stimmen überein. Ich habe einmal sogar die Datei zwischen BOOT/ und debian/ hin- und herkopiert.
NAB hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 18:48:42
Hängt grub-install auch mit "--no-nvram"?
Nein. Aber das ändert auch nichts am Bootverhalten.
NAB hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 18:48:42
Dabei fällt mir das Xubuntu wieder ein und die Frage, was es angerichtet haben könnte. Kannst du das mal anstöpseln, dann Debian booten und den efibootmgr befragen?

Code: Alles auswählen

BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,2001,2002,2003
Boot0000* HDD: SanDisk SDSSDHP128G      PciRoot(0x0)/Pci(0x12,0x0)/Sata(0,0,0)/HD(1,GPT,f72ce1d4-210b-4267-9d64-34e991a61ef7,0x800,0xf3800)RC
Boot2001* EFI USB Device        RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network   RC
Interessanterweise wird seit dem eben durchgeführten Secure-Boot-Experiment der Ubuntu-Stick nicht mehr als Bootoption erkannt, selbst wenn ich Secure Boot wieder ausschalte. :?

Das habe ich ganz zum Schluss gemacht:
NAB hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 18:48:42
Das klingt, als ob er wirklich den Inhalt der Efi-Partition scannt (smutberts Theorie) und den Boot verweigert, wenn er etwas findet, was ihm nicht passt. Eventuell wäre es interessant, die Endless-Dateien (und Verzeichnisse) sukzessiv zu löschen, dann wüsste man, welche Datei ihn stört - und damit auch, auf welche Datei er achtet.
Ich habe zuerst das gesamte EFI/endless-Verzeichnis auf die Debian-SSD kopiert und dann versucht ohne Endless-HDD zu booten. Dabei kam nach dem Acer-Logo ein schwarzer Bildschirm (Acer-Grub?) auf dem ständig und ohne Ende diese Zeile fast unleserlich flackerte:

Code: Alles auswählen

error: no such device: 4f68-bce3-e8cd-4db1-96e7fbcaf984b709
Das sieht aus wie eine UUID. Diese passt aber zu keiner Partition und zu keinem Dateisystem auf der Endless-HDD oder auf der Debian-SSD.*
Dann habe ich Endless von der HDD gebootet und auf der Debian-SSD das EFI/endless/bootx64.efi gegen EFI/debian/bootx64.efi ersetzt. Damit klappt sowohl der Debian-Boot als auch der UEFI-Zugriff beim Booten.
Als nächstes habe ich aus dem endless-Verzeichnis alle Dateien außer bootx64.efi gelöscht. Damit konnte ich booten, aber nicht in's UEFI.
Dann habe ich shim.efi wiederhergestellt und es ging wieder Beides. Die gleiche Konstellation in BOOT/ oder debian/ statt endless/ führte zwar zu funktionierendem UEFI, aber es war kein Booten mehr möglich.

Aktuell habe ich nur EFI/endless/grubx64.efi (von Debian) und EFI/endless/shim.efi (von Endless), kein BOOT/ oder debian/ und alles funktioniert soweit.
Ich vermute momentan, dass das UEFI die Datei EFI/endless/shim.efi an eben dieser Stelle haben möchte um zugreifbar zu sein, falls auch ein bootx64.efi auf der selben Partition gefunden wird. Das Booten läuft dann über bootx64.efi, dessen Position im EFI-Pfad eigentlich nebensächlich ist, wobei die Suche aber nach dem Finden von EFI/endless/shim.efi nicht neu initialisiert wird, weshalb letztendlich doch beide Dateien im endless-Verzeichnis stehen müssen.
So richtig traue ich dem Frieden aber noch nicht. Dafür ist mir das Verhalten noch viel zu undurchsichtig. Gibt es sowas wie einen Decompiler für *.efi-Dateien um mal zu schauen, was in dem shim.efi drin steht?


*) Edit: Diese Kennung nennt sich im UEFI-Kontext wohl "Protokoll":
https://jbeekman.nl/blog/2015/03/revers ... -firmware/

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von NAB » 23.03.2018 17:54:26

hikaru hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 23:22:04
rEFInd-Stick dran und versucht in's EFI zu kommen, um Secure Boot einzuschalten. Das klappte nicht.
Also rEFInd-Stick und Endless-HDD angestöpselt und ich komme in's UEFI. Dann habe ich Secureboot aktiviert und ohne Eingriff in den Bootprozess mit rEFInd-Stick aber ohne Endless-HDD gebootet und es kam der Debian-Grub hoch, nicht der von Acer und auch nicht rEFInd.
Hmm ... dann scheint "dein" Refind Secure Boot tauglich zu sein. Ich weiß nicht, wie es mit dem von Debian steht, aber eventuell kann man sich mit dem eine "nur Debian"-Lösung basteln.
hikaru hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 23:22:04
Langsam habe ich das Gefühl, dass die Secure-Boot-Option im UEFI zwar irgendwas hin- und herschaltet, das teilweise das Verhalten beim Boot beeinflusst, dass aber Secure Boot an sich nicht für den Unterschied verantwortlich ist.
Ich habe eher den Eindruck, dass Secure Boot nach dem Ausschalten nicht wirklich komplett ausgeschaltet ist. Er scheint weiterhin nach einem (signierten?) Secure-Boot-Bootloader zu suchen (ohne den geht F2 nicht). Es fragt sich weiterhin, ob das ein bestimmter im UEFI hinterlegter Bootloader ist, oder ob er sich selbstständig "irgendeinen" auf der Platte sucht.

Nach deinem folgenden Kommentar fragt sich aber auch, ob man das so sicher sagen kann, ohne jeweils einen Kaltstart ausgeführt zu haben. Eigentlich müsste man sämtliche Experimente mit einem "Power-Off" dazwischen wiederholen.

Bei Desktop-UEFIs beobachte ich übrigens oft folgendes Verhalten: Bei manchen (nicht allen) Änderungen am UEFI wird mir erst eine Liste aller von mir getätigten Änderungen angezeigt, dann führt das Gerät einen Reboot durch, und an der Stelle, an der der Bootloader gestartet werden sollte, folgt ein weiterer Reboot, der dann "normal" verläuft. Das sieht für mich so aus, als ob bei Änderungen am UEFI ein neuer Boot-Eintrag mit "Änderungsaufträgen" und einem "Reboot" am Ende erzeugt wird. Ich schließe daraus, dass Änderungen im UEFI eine sehr komplizierte Sache sind.
hikaru hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 23:22:04
Soweit ich das beurteilen kann, kommt diese Grub-Shell immer dann hoch, wenn sonst nichts zum Booten gefunden wird.
Und ja, ich glaube die ist wirklich von Acer.
Das ist aus zwei Gründen interessant:
1) Warum ist der da? Wofür mag der gut sein? Kann man den selber irgendwie nutzen? (Nein, ich habe keine Antworten)
2) Wie war das noch mit der GPL? Müsste Acer dann nicht den Quellcode dazu anbieten?
hikaru hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 23:22:04
NAB hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 18:48:42
Ist dein grubx64.efi identisch zu deinem BOOT/BOOTX64.EFI?
Ja. Die Dateigrößen stimmen überein. Ich habe einmal sogar die Datei zwischen BOOT/ und debian/ hin- und herkopiert.
NAB hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 18:48:42
Hängt grub-install auch mit "--no-nvram"?
Nein. Aber das ändert auch nichts am Bootverhalten.
Das meinte ich nicht.
Das ist aus zwei Gründen interessant:
1) Grub schreibt bei der Installation vor dem Aufhängen einen kompletten Bootloader, hängt sich also erst danach auf (du erinnerst dich, damit fing der Thread an). Das "danach" hat dann höchstwahrscheinlich mit dem Schreiben ins NVRAM zu tun.
2) Das Blacklisten der efivar-Module nach smutberts Anleitung führt entweder nicht zum gewünschten Ergebnis oder wurde von dir falsch durchgeführt oder "grub-install" lädt diese Module dann trotzdem "hintenrum".

Nebenbei fällt mir gerade noch ein, dass du auf Seite 1 von Kernel-Panics berichtet hast. Wenn man die (ohne "--no-nvram") reproduzieren kann, reicht's vielleicht für einen qualifizierten Kernel Bug.
hikaru hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 23:22:04
Interessanterweise wird seit dem eben durchgeführten Secure-Boot-Experiment der Ubuntu-Stick nicht mehr als Bootoption erkannt, selbst wenn ich Secure Boot wieder ausschalte. :?
Huch? Es wird wirklich immer kurioser. Eventuell hilft ein Power-Off dagegen?

Ob der Ubuntu-Stick sich selbst beschädigt hat, kannst du mangels weiterer UEFI-Maschine nicht testen, oder? Aber einen Blick auf die Efi-Partition und den removable media path müsstest du werfen können. Findest du dort die gleich erwähnte PARTUUID?
hikaru hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 23:22:04
Ich habe zuerst das gesamte EFI/endless-Verzeichnis auf die Debian-SSD kopiert und dann versucht ohne Endless-HDD zu booten. Dabei kam nach dem Acer-Logo ein schwarzer Bildschirm (Acer-Grub?) auf dem ständig und ohne Ende diese Zeile fast unleserlich flackerte:

Code: Alles auswählen

error: no such device: 4f68-bce3-e8cd-4db1-96e7fbcaf984b709
Das sieht aus wie eine UUID. Diese passt aber zu keiner Partition und zu keinem Dateisystem auf der Endless-HDD oder auf der Debian-SSD.*

*) Edit: Diese Kennung nennt sich im UEFI-Kontext wohl "Protokoll":
https://jbeekman.nl/blog/2015/03/revers ... -firmware/
Uff ... ich weiß jetzt wesentlich mehr über EFI Binaries als ich jemals wissen wollte. Aber ich denke, du bist auf dem Holzweg. Stimmt, EFI nutzt UUIDs als Funktionsreferenz. Aber auch in gewöhnlicher Weise um Partitionen zu identifizieren. Die Meldung oben sieht mir viel zu sehr nach einem gewöhnlichen Grub-Fehler aus, der seine Partition nicht finden kann.

Auf einem funktionierenden UEFI wirst du feststellen, dass die UUIDs in den Booteinträgen von "efibootmgr -v" identisch sind zu den PARTUUIDs, die blkid anzeigt. Die PARTUUIDs stehen in der GPT, sind also von der Partitionstabelle abhängig und nicht vom Dateisystem.

Ich bin mir ziemlich sicher, dass Grub hier eine PARTUUID sucht. Die PARTUUID lässt sich ändern:
https://bbs.archlinux.org/viewtopic.php?id=215541
man könnte ihm also geben, wonach er sucht. Interessanter wäre aber mMn, wo diese "4f68-bce3-e8cd-4db1-96e7fbcaf984b709" steht. Hardcodiert im Acer-Grub? Versteckt und änderbar im NVRAM? Oder in einem der Bootloader von Endless oder Debian (woher auch immer). Du könntest auf der Platte und im Acer-BIOS-Update danach suchen.
hikaru hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 23:22:04
Dann habe ich Endless von der HDD gebootet und auf der Debian-SSD das EFI/endless/bootx64.efi gegen EFI/debian/bootx64.efi ersetzt. Damit klappt sowohl der Debian-Boot als auch der UEFI-Zugriff beim Booten.
Als nächstes habe ich aus dem endless-Verzeichnis alle Dateien außer bootx64.efi gelöscht. Damit konnte ich booten, aber nicht in's UEFI.
Dann habe ich shim.efi wiederhergestellt und es ging wieder Beides. Die gleiche Konstellation in BOOT/ oder debian/ statt endless/ führte zwar zu funktionierendem UEFI, aber es war kein Booten mehr möglich.

Aktuell habe ich nur EFI/endless/grubx64.efi (von Debian) und EFI/endless/shim.efi (von Endless), kein BOOT/ oder debian/ und alles funktioniert soweit.
Hmm .. so als grobe Hypothese: Entweder
1) sucht das UEFI trotz ausgeschaltetem Secure Boot einen signierten Bootloader (smutberts Theorie), findet den unter /endless/shim.efi (sonst geht F2 nicht) und /endless/shim.efi will dann einen hardcodierten Pfad laden *a).
oder
2) der Pfad /endless/shim.efi ist irgendwo gespeichert (wo?!?) (meine Theorie), wird geladen wenn er gefunden wird und /endless/shim.efi will dann wieder einen hardcodierten Pfad laden *a).

*a) Welchen hardcodierten Pfad? Aus der Beschreibung von Shim (siehe unten) ergeben sich zwei Möglichkeiten.
a1) Shim sucht in <aktuelles Verzeichnis>/grubx64.efi (oder sucht generell eine Datei grubx64.efi in der Efi Partition, das halte ich für unwahrscheinlich).
a2) Acer benutzt einen manipulierten Shim, der nach /endless/grubx64.efi sucht.

Soweit ich das Chaos hier überblicke: wenn man shim.efi und Debians grubx64.efi in ein anderes Verzeichnis packt, dann funktioniert es nicht. Das schließt eine Kombination von 1) und a1) eigentlich aus. Den Rest kann man herausbekommen.
hikaru hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 23:22:04
Gibt es sowas wie einen Decompiler für *.efi-Dateien um mal zu schauen, was in dem shim.efi drin steht?
Die Frage ist, wie lange sowas dauert und was es bringt. Reverse Engineering ist ziemlich aufwändig, wie dein Artikel eindrucksvoll zeigt. Wenn du erst nach Buster fertig bist, kannst du genau so gut auch den bis dahin hoffentlich funktionierenden Secure Boot Support von Buster nutzen.

Der Punkt an Shim ist, dass es von Microsoft signiert und somit binär unveränderbar ist, und das meineswissens seit 2012:
http://www.codon.org.uk/~mjg59/shim-signed/
Das Readme führt dich hierhin:
https://mjg59.dreamwidth.org/20303.html
wenn man das wörtlich nimmt, dann muss Shim in /EFI/BOOT liegen ... das scheint zumindest hier nicht so ganz zu stimmen - zumindest nicht für den Fall "Secure Boot ausgeschaltet".

Du könntest dir erst mal irgendein anderes shim.efi besorgen und das mit deinem von Endless OS vergleichen. Wenn beide binär identisch sind, dann hat Acer hier zumindest nichts eigenes gebacken und du kannst den öffentlichen Quellcode von Shim sichten.

Und wenn es ein unmanipulierter Shim ist, dann müsste meiner Meinung nach Folgendes klappen:
shim.efi -> /EFI/BOOT/bootx64.efi
(den removable media path bootet dein UEFI ja anscheinend brav)
/debian/grubx64.efi -> /EFI/BOOT/grubx64.efi

Falls das klappt, hätten wir EFI/endless/shim.efi durch den anscheinend priorisierten removable media path umgangen, aber immer noch nicht geklärt, warum das UEFI den Pfad EFI/endless/shim.efi so gerne mag.

Falls es sich um einen manipulierten Shim handelt, würde ich erst mal bei Endless OS gucken, ob der von denen stammt (ich weiß über Endless OS so gut wie nichts). Die dürften den Quellcode vorrätig halten. Sonst wären wir wieder bei der Frage mit der GPL ...

"shim" gibt es übrigens auch als Debian Paket. Ich hab nur keine Ahnung, in welchem Zustand es sich befindet und wie man es konfiguriert. Aber nach meinem Verständnis kann sich da seit 2012 eigentlich nichts geändert haben und zu konfigurieren dürfte es da auch nichts geben.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von hikaru » 27.03.2018 10:54:19

NAB hat geschrieben: ↑ zum Beitrag ↑
23.03.2018 17:54:26
Ich habe eher den Eindruck, dass Secure Boot nach dem Ausschalten nicht wirklich komplett ausgeschaltet ist. Er scheint weiterhin nach einem (signierten?) Secure-Boot-Bootloader zu suchen (ohne den geht F2 nicht). Es fragt sich weiterhin, ob das ein bestimmter im UEFI hinterlegter Bootloader ist, oder ob er sich selbstständig "irgendeinen" auf der Platte sucht.
bootx64.efi aus Debianshim (oder auch aus dem Ubuntu-18.04-Paket) funktionioert ebenfalls, vorausgesetzt, man legt die Datei als EFI/endless/shim.efi ab.
Keine zwei der drei Dateien sind identisch.
NAB hat geschrieben: ↑ zum Beitrag ↑
23.03.2018 17:54:26
Und wenn es ein unmanipulierter Shim ist, dann müsste meiner Meinung nach Folgendes klappen:
shim.efi -> /EFI/BOOT/bootx64.efi
(den removable media path bootet dein UEFI ja anscheinend brav)
/debian/grubx64.efi -> /EFI/BOOT/grubx64.efi
Das führt zu bootendem Debian aber fehlendem UEFI-Zugriff, egal ob mit shim bzw. bootx64 von Endless, Debian oder Ubuntu.
NAB hat geschrieben: ↑ zum Beitrag ↑
23.03.2018 17:54:26
Falls es sich um einen manipulierten Shim handelt, würde ich erst mal bei Endless OS gucken, ob der von denen stammt (ich weiß über Endless OS so gut wie nichts). Die dürften den Quellcode vorrätig halten. Sonst wären wir wieder bei der Frage mit der GPL ...
shim steht unter BSDL (2-Clause). [1] Eine Verpflichtung zur Veröffentlichung von Quellcode besteht daher für Acer/Endless nicht.
Unabhängig davon gibt es unter [2] eine sources.list zu Endless, und in diesem Repo gibt es shim-Quellen [3], neben denen ein bootx64.efi liegt, das binär identisch mit meinem endless/shim.efi ist. Die Datei führt aber wie gesagt unter dem Namen bootx64.efi nicht zu einem erfolgreichen UEFI-Zugriff. Laut debian/rules aus dem Archiv wird bootx64.efi nach shim.efi kopiert.

In der sources.list auf meiner Endless-HDD steht übrigens ein anderer Server, der aber nicht (mehr?) online zu sein scheint. Laut dieser sources.list ist auf der HDD Endless 3.1 installiert.
NAB hat geschrieben: ↑ zum Beitrag ↑
23.03.2018 17:54:26
Nach deinem folgenden Kommentar fragt sich aber auch, ob man das so sicher sagen kann, ohne jeweils einen Kaltstart ausgeführt zu haben. Eigentlich müsste man sämtliche Experimente mit einem "Power-Off" dazwischen wiederholen.
Nachdem ich den Verdacht hatte, dass Reboots möglicherweise nicht ausreichen, habe ich alle weiteren Aktionen grundsätzlich mit Kaltstarts gemacht.
NAB hat geschrieben: ↑ zum Beitrag ↑
23.03.2018 17:54:26
Bei Desktop-UEFIs beobachte ich übrigens oft folgendes Verhalten: Bei manchen (nicht allen) Änderungen am UEFI wird mir erst eine Liste aller von mir getätigten Änderungen angezeigt, dann führt das Gerät einen Reboot durch, und an der Stelle, an der der Bootloader gestartet werden sollte, folgt ein weiterer Reboot, der dann "normal" verläuft. Das sieht für mich so aus, als ob bei Änderungen am UEFI ein neuer Boot-Eintrag mit "Änderungsaufträgen" und einem "Reboot" am Ende erzeugt wird. Ich schließe daraus, dass Änderungen im UEFI eine sehr komplizierte Sache sind.
Hier sieht es anders aus. Nachdem irgendwelche Schreibaktionen nach /boot/efi/EFI ducrhgeführt wurden, dauert der Shutdown (egal ob kalt oder warm) jeweils 1-3 Minuten länger als üblich. Ich vermute, dabei werden Änderungen geschrieben (die aber möglicherweise beim nächsten Boot noch irgendwie initialisiert werden müssen, was vieleicht nur beim Kaltstart geht).

Kombiniert man das mit der langen Shutdown-Prozedur eines fetten Live-Xubuntu von einem zugegeben nicht blitzschnellen USB-2.0-Stick, dann kann möglicherweise der Eindruck entstehen, das System habe sich beim Shutdown aufgehangen. Ich glaube genau das ist neulich passiert und ich war nicht geduldig genug. Nachdem ich die Systematik mit endless/shim.efi und endless/grubx64.efi herausgefunden habe funktioniert übrigens auch der Boot vom Xubuntu-Stick wieder. Warum es nun wieder geht, weiß ich allerdings nicht. Auf dem Xubuntu-Stick gibt es neben der iso9660-Partition zwar noch eine fat-Partition, ich finde darauf jedoch keine efi-Dateien.
NAB hat geschrieben: ↑ zum Beitrag ↑
23.03.2018 17:54:26
hikaru hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 23:22:04
Soweit ich das beurteilen kann, kommt diese Grub-Shell immer dann hoch, wenn sonst nichts zum Booten gefunden wird.
Und ja, ich glaube die ist wirklich von Acer.
Das ist aus zwei Gründen interessant:
1) Warum ist der da? Wofür mag der gut sein? Kann man den selber irgendwie nutzen? (Nein, ich habe keine Antworten)
2) Wie war das noch mit der GPL? Müsste Acer dann nicht den Quellcode dazu anbieten?
Im Endless-Repo gibt es auch Grub2-Quellen. [4] Ob die zu diesem "Acer-Grub" passen weiß ich nicht und ich sehe bisher auch keinen Weg, diesen Grub auszutauschen.
NAB hat geschrieben: ↑ zum Beitrag ↑
23.03.2018 17:54:26
2) Das Blacklisten der efivar-Module nach smutberts Anleitung führt entweder nicht zum gewünschten Ergebnis oder wurde von dir falsch durchgeführt oder "grub-install" lädt diese Module dann trotzdem "hintenrum".
Ich habe mich an smutberts Anleitung gehalten und die Module (efivars, efivarfs) werden dann laut lsmod auch nicht geladen, selbst nach einem grub-install ohne --no-nvram nicht.
NAB hat geschrieben: ↑ zum Beitrag ↑
23.03.2018 17:54:26
Nebenbei fällt mir gerade noch ein, dass du auf Seite 1 von Kernel-Panics berichtet hast. Wenn man die (ohne "--no-nvram") reproduzieren kann, reicht's vielleicht für einen qualifizierten Kernel Bug.
Diese Kernel-Panics hatte ich jetzt lang nicht mehr, egal ob mit oder ohne geladenem efivars/efivarfs und mit oder ohne --no-nvram.
NAB hat geschrieben: ↑ zum Beitrag ↑
23.03.2018 17:54:26
hikaru hat geschrieben: ↑ zum Beitrag ↑
22.03.2018 23:22:04
Ich habe zuerst das gesamte EFI/endless-Verzeichnis auf die Debian-SSD kopiert und dann versucht ohne Endless-HDD zu booten. Dabei kam nach dem Acer-Logo ein schwarzer Bildschirm (Acer-Grub?) auf dem ständig und ohne Ende diese Zeile fast unleserlich flackerte:

Code: Alles auswählen

error: no such device: 4f68-bce3-e8cd-4db1-96e7fbcaf984b709
Das sieht aus wie eine UUID. Diese passt aber zu keiner Partition und zu keinem Dateisystem auf der Endless-HDD oder auf der Debian-SSD.*

*) Edit: Diese Kennung nennt sich im UEFI-Kontext wohl "Protokoll":
https://jbeekman.nl/blog/2015/03/revers ... -firmware/
Uff ... ich weiß jetzt wesentlich mehr über EFI Binaries als ich jemals wissen wollte. Aber ich denke, du bist auf dem Holzweg. Stimmt, EFI nutzt UUIDs als Funktionsreferenz. Aber auch in gewöhnlicher Weise um Partitionen zu identifizieren. Die Meldung oben sieht mir viel zu sehr nach einem gewöhnlichen Grub-Fehler aus, der seine Partition nicht finden kann.
Ich fürchte, wir sind beide auf dem Holzweg.
Wenn man mal genau hinschaut, dann stellt man fest, dass GPT-PARTUUIDs und auch UEFI-Protokoll-UUIDs das Format 8-4-4-4-12 haben. Was da auf meinem Schirm erschien hat aber das Format 4-4-4-4-16.
NAB hat geschrieben: ↑ zum Beitrag ↑
23.03.2018 17:54:26
Auf einem funktionierenden UEFI wirst du feststellen, dass die UUIDs in den Booteinträgen von "efibootmgr -v" identisch sind zu den PARTUUIDs, die blkid anzeigt. Die PARTUUIDs stehen in der GPT, sind also von der Partitionstabelle abhängig und nicht vom Dateisystem.
Kann ich auf meinem System bestätigen. Aber die "UUID" aus dem Flackerschirm passt zu keiner PARTUUID auf irgendeinem der Datenträger die ich jemals zum Booten des Geräts verwendet habe, nicht auf der Endless-HDD, der Debian-SSD, dem Xubuntu-Stick oder dem rEFInd-Stick. Sie passt selbst dann nicht, wenn man die Bindestriche im Format ignoriert. Die Hex-Sequenz taucht nirgendwo sonst auf.
NAB hat geschrieben: ↑ zum Beitrag ↑
23.03.2018 17:54:26
Hmm .. so als grobe Hypothese: Entweder
1) sucht das UEFI trotz ausgeschaltetem Secure Boot einen signierten Bootloader (smutberts Theorie), findet den unter /endless/shim.efi (sonst geht F2 nicht) und /endless/shim.efi will dann einen hardcodierten Pfad laden *a).
oder
2) der Pfad /endless/shim.efi ist irgendwo gespeichert (wo?!?) (meine Theorie), wird geladen wenn er gefunden wird und /endless/shim.efi will dann wieder einen hardcodierten Pfad laden *a).

*a) Welchen hardcodierten Pfad? Aus der Beschreibung von Shim (siehe unten) ergeben sich zwei Möglichkeiten.
a1) Shim sucht in <aktuelles Verzeichnis>/grubx64.efi (oder sucht generell eine Datei grubx64.efi in der Efi Partition, das halte ich für unwahrscheinlich).
a2) Acer benutzt einen manipulierten Shim, der nach /endless/grubx64.efi sucht.

Soweit ich das Chaos hier überblicke: wenn man shim.efi und Debians grubx64.efi in ein anderes Verzeichnis packt, dann funktioniert es nicht. Das schließt eine Kombination von 1) und a1) eigentlich aus. Den Rest kann man herausbekommen.
In dem Archiv unter [3] gibt es abgesehen vom Changelog zwei Dateien in denen "endless" erwähnt wird:

Code: Alles auswählen

debian/source/include-binaries:debian/endless-ca.der
debian/shim-efi-image-signed.install:MokManager.efi  /boot/efi/EFI/endless/
debian/shim-efi-image-signed.install:shim.efi /boot/efi/EFI/endless/
debian/shim-efi-image-signed.install:BOOT.CSV /boot/efi/EFI/endless/
Die .install halte ich für unspektakulär:

Code: Alles auswählen

bootx64.efi /boot/efi/EFI/BOOT/
fallback.efi /boot/efi/EFI/BOOT/
MokManager.efi  /boot/efi/EFI/endless/
shim.efi /boot/efi/EFI/endless/
BOOT.CSV /boot/efi/EFI/endless/
Die include-binaries verwirrt mich (vollständiger Inhalt):

Code: Alles auswählen

debian/endless-ca.der
Die Datei gibt es in dem Archiv nicht, dafür eine debian/endless-ca.cer
Ist das ein Tippfehler? Und falls ja, hat der Auswirkungen?

Was ich noch nicht ganz verstanden habe ist die Rolle von MokManager.efi. Die Datei habe ich bisher ignoriert. Unter [5] steht ein bisschen was dazu, aber das ist mir zu unspezifisch.


[1] https://mjg59.dreamwidth.org/20303.html ... #cmt790095
[2] https://wiki.debian.org/Derivatives/Census/Endless
[3] http://sources.endlessm.com/debian/pool ... im-signed/
[4] http://sources.endlessm.com/debian/pool/core/g/grub2/
[5] https://www.golem.de/news/uefi-secure-b ... 96085.html

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von NAB » 27.03.2018 19:34:15

hikaru hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 10:54:19
Keine zwei der drei Dateien sind identisch.
hmm ... das lässt mich nun an meinem Verständnis von "signierter Bootloader" zweifeln ...
Andererseits hat auch niemand versprochen, dass jede Version von Shim signiert ist, dämmert mir gerade. Man könnte beliebige unsignierte Versionen erzeugen. Wozu man die dann braucht, wäre eine andere Frage.
hikaru hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 10:54:19
NAB hat geschrieben: ↑ zum Beitrag ↑
23.03.2018 17:54:26
Und wenn es ein unmanipulierter Shim ist, dann müsste meiner Meinung nach Folgendes klappen:
shim.efi -> /EFI/BOOT/bootx64.efi
(den removable media path bootet dein UEFI ja anscheinend brav)
/debian/grubx64.efi -> /EFI/BOOT/grubx64.efi
Das führt zu bootendem Debian aber fehlendem UEFI-Zugriff, egal ob mit shim bzw. bootx64 von Endless, Debian oder Ubuntu.
*mist* ... dein UEFI scheint wirklich in den Pfad /endless/shim.efi verliebt zu sein.

Aber ich befürchte, das funktioniert schon deswegen nicht, weil es einen signierten Shim braucht (der von Endless ist ja signiert). Ich ging bisher davon aus, dass Shim immer signiert ist, weil ich mir keinen anderen Nutzen vorstellen kann. Siehe weiter unten.
hikaru hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 10:54:19
Hier sieht es anders aus. Nachdem irgendwelche Schreibaktionen nach /boot/efi/EFI ducrhgeführt wurden, dauert der Shutdown (egal ob kalt oder warm) jeweils 1-3 Minuten länger als üblich.
Huch? Das meinte ich eigentlich gar nicht. Ich meinte Änderungen im UEFI selber, die ins NVRAM/CMOS/Wasauchimmer geschrieben werden, keine Änderungen in der EFI Partition. Warum das UEFI auf Änderungen in der Partition derartig lange herumkaut, und das auch noch beim Herunterfahren, ist mir ein Rätsel. Das kenne ich nicht.
hikaru hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 10:54:19
Ich vermute, dabei werden Änderungen geschrieben (die aber möglicherweise beim nächsten Boot noch irgendwie initialisiert werden müssen, was vieleicht nur beim Kaltstart geht).
"Eigentlich" nicht. Eigentlich sollte es dem UEFI egal sein, ob sich auf der Partition etwas ändert. Lediglich Änderungen am NVRAM müsste es irgendwie prüfen und integrieren. Wenn du deinen Bootloader löscht, dann würde es beim nächsten Booten den Eintrag im NVRAM nachschlagen, dann feststellen, dass die Datei nicht mehr existiert und meckern ... oder zum nächsten Booteintrag übergehen. Dein UEFI führt da ein merkwürdiges Eigenleben, das ich so nicht kenne.
hikaru hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 10:54:19
Kombiniert man das mit der langen Shutdown-Prozedur eines fetten Live-Xubuntu von einem zugegeben nicht blitzschnellen USB-2.0-Stick,
Das mag sein, erklärt aber nicht, was Xubuntu auf der EFI-Partition (oder im NVRAM) zu ändern hatte. Eigentlich sollte ein Live-System beides nicht anfassen.
hikaru hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 10:54:19
Auf dem Xubuntu-Stick gibt es neben der iso9660-Partition zwar noch eine fat-Partition, ich finde darauf jedoch keine efi-Dateien.
Huch? Da sollten aber welche sein:
http://www.syslinux.org/wiki/index.php?title=Isohybrid
Eigentlich ginge es auch ohne, aber dann müsste das UEFI (von USB) einen BIOS-Boot machen.
hikaru hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 10:54:19
Im Endless-Repo gibt es auch Grub2-Quellen. [4] Ob die zu diesem "Acer-Grub" passen weiß ich nicht und ich sehe bisher auch keinen Weg, diesen Grub auszutauschen.
Das meinte ich nicht. Deinen Berichten zufolge steckt der Grub in der Firmware, ließe sich also nur durch ein Firmware-Update austauschen. Und die müssen inzwischen signiert sein. Ich meinte, den vorhandenen Grub zum Booten zu benutzen, insbesondere mit der vermeintlichen UUID, aber da hast du mir gerade den Wind aus den Segeln genommen.
hikaru hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 10:54:19
Ich habe mich an smutberts Anleitung gehalten und die Module (efivars, efivarfs) werden dann laut lsmod auch nicht geladen, selbst nach einem grub-install ohne --no-nvram nicht.
Das bezweifele ich nicht, aber warum funktioniert grub-install (ohne --no-nvram) und efibootmgr bei dir? Wenn das Blacklisten von efivars den gewünschten Effekt hätte, dürfte beides nicht funktionieren. Hier steht etwas mehr darüber:
https://wiki.gentoo.org/wiki/Efibootmgr/de
hikaru hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 10:54:19
Ich fürchte, wir sind beide auf dem Holzweg.
Wenn man mal genau hinschaut, dann stellt man fest, dass GPT-PARTUUIDs und auch UEFI-Protokoll-UUIDs das Format 8-4-4-4-12 haben. Was da auf meinem Schirm erschien hat aber das Format 4-4-4-4-16.
Upps ...
Ich würd ja gerne widersprechen, aber ich finde keinen Hinweis, dass UUIDs irgendwo/wie anders notiert werden. Dieses "error: no such device:" sieht aber trotzdem sehr verlockend nach einem suchenden Grub aus. Trotzdem ... ich wüsste nicht, wie man eine derartig verunstaltete UUID in eine Partitionstabelle schreibt. Und wenn wirklich ein Grub dieses "Ding" anzeigt, dann müsste der Grub selber eigenwillig verändert worden sein, nur wozu?

Es bleibt mysteriös ...
hikaru hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 10:54:19
Die Datei gibt es in dem Archiv nicht, dafür eine debian/endless-ca.cer
Ist das ein Tippfehler? Und falls ja, hat der Auswirkungen?
Ich tippe mal darauf, dass es einen Fehler bei der Installation geben würde. Aber ... worauf willst du hinaus? Ich war bei der Frage, wie das UEFI funktioniert. Nun gräbst du Endless um, was wohl niemand hier installieren oder benutzen möchte.

Was sich mir hingegen gerade in die Netzhaut brennt ist das "shim-efi-image-signed". Der Shim aus Stretch scheint tatsächlich "unsigned" zu sein (wozu auch immer man sowas braucht). In Buster gibt es einen shim-signed:
https://packages.debian.org/de/buster/shim-signed
Du könntest dir da das "shimx64.efi.signed" rausklauen und versuchen, es statt des Endless-Shim zu benutzen.
hikaru hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 10:54:19
Was ich noch nicht ganz verstanden habe ist die Rolle von MokManager.efi. Die Datei habe ich bisher ignoriert.
Wozu Shim überhaupt ein MokManager.efi braucht, ist mir auch unklar. MOKs hingegen sind "Machine Owner Keys" und eigentlich eine ziemlich tolle Sache. Du kannst nämlich aus dem UEFI den Microsoft-Key rausschmeißen und deinen eigenen MOK hinterlegen und fortan nur noch selbstsignierte Binaries starten. Ich hab mich damals ziemlich gefreut, als ich das gelesen habe und dachte mir "tolle Sache" aber irgendwie wird es bis heute nicht so richtig genutzt. Inzwischen hätte ich aber eher Angst davor, in welche UEFI-Bugs ich dabei stolpern würde. Mehr zum Thema:
https://firmware.intel.com/blog/using-m ... suse-linux
Und in der praktischen Anwendung:
https://knowledge.windriver.com/en-us/0 ... 70/000/010
Daraus kann man sich zurechtraten, was der MokManager.efi vermutlich tut. Kurz gesagt: nichts, was du nutzt.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von hikaru » 27.03.2018 23:08:50

NAB hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 19:34:15
Aber ich befürchte, das funktioniert schon deswegen nicht, weil es einen signierten Shim braucht (der von Endless ist ja signiert).
In meinem letzten Beitag schrieb ich, dass es offenbar egal ist, welchen shim ich verwende (Endless, Stretch oder Ubuntu). Wichtig ist nur, dass das Teil in /endless liegt und auch wirklich shim.efi heißt (und nicht etwa boot64.efi).
So zumindest die Situation mit abgeschaltetem Secure Boot. Für einen weiteren Test mit Secure Boot bin ich gerade zu faul.
NAB hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 19:34:15
Huch? Das meinte ich eigentlich gar nicht.
[..]
Das meinte ich nicht.
Wir müssen an unserer Kommunikation arbeiten! ;)
NAB hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 19:34:15
Das mag sein, erklärt aber nicht, was Xubuntu auf der EFI-Partition (oder im NVRAM) zu ändern hatte. Eigentlich sollte ein Live-System beides nicht anfassen.
Es kann sein, das ich einen meiner EFI-Reparaturversuche (hin- und herschieben von *.efi-Dateien) von Xubuntu aus durchgeführt habe.
NAB hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 19:34:15
hikaru hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 10:54:19
Auf dem Xubuntu-Stick gibt es neben der iso9660-Partition zwar noch eine fat-Partition, ich finde darauf jedoch keine efi-Dateien.
Huch? Da sollten aber welche sein:
Oh, Tatsache:

Code: Alles auswählen

# md5sum /mnt/efi/boot/*
6e94c3d33194c89bd327bfaa5871e294  /mnt/efi/boot/bootx64.efi
7dc5588d483932c1215cc6ff785ceb36  /mnt/efi/boot/grubx64.efi
Keine Ahnung warum ich die nicht gesehen habe. (Ich bin mir 100%ig sicher, sie nicht gesehen zu haben. Aber vielleicht habe ich mich heute morgen vermountet.)
NAB hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 19:34:15
Das bezweifele ich nicht, aber warum funktioniert grub-install (ohne --no-nvram) und efibootmgr bei dir?
grub-install mit und ohne --removable funktioniert mit und ohne efivars/efivarfs. Ohne die Module geht's nur mit --no-nvram. Nach dem was ich bisher verstanden habe ist daran auch nichts seltsam.
NAB hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 19:34:15
Ich war bei der Frage, wie das UEFI funktioniert. Nun gräbst du Endless um, was wohl niemand hier installieren oder benutzen möchte.
Ich habe bisher keine Ahnung von UEFI. Da dachte ich, es wäre eine gute Idee nachzuschauen, wie das einzige mir bisher bekannte mit UEFI-Boot ausgelieferte System unter der Haube aussieht.
Außerdem suchte ich nach einer Möglichkeit, die Kiste mit Quellen aus dem Netz bootfähig zu machen, falls ich mir mal wieder irgendwas an der Bootsequenz zerschieße und mir in einem kosmischen Unglücksfall alle Backups gleichzeitig sterben.

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von smutbert » 27.03.2018 23:40:09

Habt ihr eigentlich noch einen Überblick - ich muss zugeben, dass obwohl ich mich bemühe, nicht ganz mitkomme?
Mir ist die Aussage in Erinnerung, dass das Aufrufen des BIOS/UEFI-Setup (<F2>) ohne »EFI/boot/bootx64.efi« funktioniert hat - ist das noch aktuell?

Weil dann wäre es meiner Meinung nach ganz interessant was passiert, wenn du von diesem endless OS aus unter dem ja alles (?) funktioniert mittels efibootmgr (oder eventuell auch chroot) einen Booteintrag für Debians grub anlegst »EFI/debian/grubx64.efi« anlegst und dafür »EFI/boot/bootx64.efi« (jeweils auf der internen SSD) löschst. Das sollte in etwa so gehen (bin mir jetzt nicht sicher, ob Debians EFI System Partition dafür gemountet sein muss oder nicht)

Code: Alles auswählen

# efibootmgr -c -d /dev/sda -p 1 -L "Debian" -l "\EFI\debian\grubx64.efi"
Bleibt dieser Befehl (auch) in endless OS hängen oder funktioniert dann das Booten von Debian und/oder <F2> wieder nicht?

Antworten