[erledigt] UEFI-Installation: "grub-install dummy" hängt
Re: UEFI-Installation: "grub-install dummy" hängt
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 ...
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
"No computer system can be absolutely secure." Intel Document Number: 336983-001
Re: UEFI-Installation: "grub-install dummy" hängt
Ja, sollte auch so klingen - als vage Vermutung.NAB hat geschrieben:20.03.2018 21:55:34So 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?
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.
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.NAB hat geschrieben:20.03.2018 21:55:34Der 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/*
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.
Windows kommt mir nicht mehr in's Haus.NAB hat geschrieben:20.03.2018 21:55:34Hast du das BIOS-Update noch im Hinterkopf? Win10 als Testversion gäbe es gratis ...
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.
Re: UEFI-Installation: "grub-install dummy" hängt
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).
(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.)
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).
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.hikaru hat geschrieben:20.03.2018 22:20:05Kann 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.
(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.)
Re: UEFI-Installation: "grub-install dummy" hängt
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.smutbert hat geschrieben:20.03.2018 22:38:27Eine 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.
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
Re: UEFI-Installation: "grub-install dummy" hängt
Gparted nennt das "Flag" (Partition -> Manage Flags). In diesem Fall das Boot-Flag (auch wenn es bei GPT kein Flag mehr ist).hikaru hat geschrieben:20.03.2018 23:26:47Die Partition hatte ich in gparted angelegt und mit fat32 formatiert. Der Partitionstyp ließ sich dort nicht festlegen.
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
"No computer system can be absolutely secure." Intel Document Number: 336983-001
Re: UEFI-Installation: "grub-install dummy" hängt
Das ist auf der Debian-EFI-Partition:
Und das auf der von Endless:
efibootmgr von Debian aus:
und von Endless:
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
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
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
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
Re: UEFI-Installation: "grub-install dummy" hängt
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.
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
"No computer system can be absolutely secure." Intel Document Number: 336983-001
Re: UEFI-Installation: "grub-install dummy" hängt
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.
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.
Re: UEFI-Installation: "grub-install dummy" hängt
smutbert, worauf willst du hinaus? Wenn ich das richtig verstanden habe, gibt es kein Boot-Problem mehr. Debian bootet über den removable media path.smutbert hat geschrieben:21.03.2018 16:16:20Zur möglichen Problemlösung habe ich nichts gefunden und leider auch keine Idee. Unter Ubuntu gab es offensichtlich dasselbe Problem [1]
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
"No computer system can be absolutely secure." Intel Document Number: 336983-001
Re: UEFI-Installation: "grub-install dummy" hängt
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)
(wenn ich mir das was ich schreibe noch einmal durchlese glaube ich es selbst auch nicht mehr, aber irgendetwas muss es sein)
Re: UEFI-Installation: "grub-install dummy" hängt
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:21.03.2018 16:06:18Interessant ist, dass Endless OS irgendwie einen zusätzlichen Boot-Eintrag ins NVRAM zaubert:
Boot0001* Linux
Probiere ich nachher beides, und auch das:NAB hat geschrieben:21.03.2018 16:06:18Mit 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.
smutbert hat geschrieben:21.03.2018 16:16:20Das 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?).
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.NAB hat geschrieben:21.03.2018 16:29:22P.S.: hikaru, ein simples "Akku raus" wäre natürlich mal einen Versuch wert.
30 Sekunden Powerknopf drücken habe ich schon diverse Male probiert.
[1] https://nl.hardware.info/reviews/7490/4 ... e-techniek
Re: UEFI-Installation: "grub-install dummy" hängt
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.)hikaru hat geschrieben: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.[…]
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.
Re: UEFI-Installation: "grub-install dummy" hängt
Oder an deren Größe, Offset oder irgendeiner anderen Kuriosität ...smutbert hat geschrieben:21.03.2018 16:42:57Ja, aber das F2-Problem muss doch an irgendeinem der Unterschiede am Inhalt der ESP liegen
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).smutbert hat geschrieben:21.03.2018 16:42:57als 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)
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.
Tut's aber manchmal, bis hin zum Totalschaden, grad wieder passiert:hikaru hat geschrieben:21.03.2018 16:57:44Ich bin ja eigentlich der Meinung, dass selbst der schlimmstmöglichst verhunzte Bootloader nicht das BIOS/UEFI beeinträchtigen darf,
https://itsfoss.com/ubuntu-17-10-bios-bug/
P.S.:
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)smutbert hat geschrieben:21.03.2018 17:09:02Im 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.
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
"No computer system can be absolutely secure." Intel Document Number: 336983-001
Re: UEFI-Installation: "grub-install dummy" hängt
Sieht wohl so aus:smutbert hat geschrieben:21.03.2018 17:09:02"efibootmgr -v" sollte also zeigen, dass Boot0000 auf EFI/BOOT/BOOTX64.efi auf der internen SSD verweist.)
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
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
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.
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:21.03.2018 17:18:18Tut's aber manchmal, bis hin zum Totalschaden, grad wieder passiert:hikaru hat geschrieben:21.03.2018 16:57:44Ich bin ja eigentlich der Meinung, dass selbst der schlimmstmöglichst verhunzte Bootloader nicht das BIOS/UEFI beeinträchtigen darf,
https://itsfoss.com/ubuntu-17-10-bios-bug/
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.NAB hat geschrieben:21.03.2018 17:18:18hikaru, wie bootest du überhaupt das Endless OS, wenn F2 nicht geht?
Re: UEFI-Installation: "grub-install dummy" hängt
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.hikaru hat geschrieben:21.03.2018 19:00:34Aber wer entwickelt einen Standard in dem sowas überhaupt möglich ist und traut sich dann auch noch, den zu veröffentlichen?
Re: UEFI-Installation: "grub-install dummy" hängt
Ich bin im Gegenteil davon ausgegangen, dass zumindest beim Booten von Debian die externe HDD nicht angeschlossen war...NAB hat geschrieben: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?
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).
Re: UEFI-Installation: "grub-install dummy" hängt
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, 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?
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.
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.
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 hat geschrieben:21.03.2018 19:00:34Endless:Code: Alles auswählen
Boot0001* Linux HD(1,800,1f000,7e4d7ae3-0837-41bb-8f04-4c61291b261e)File(\EFI\endless\shim.efi)RC
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?
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.hikaru hat geschrieben:21.03.2018 19:00:34Was 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.
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.
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.hikaru hat geschrieben:21.03.2018 19:00:34Aber wer entwickelt einen Standard in dem sowas überhaupt möglich ist und traut sich dann auch noch, den zu veröffentlichen?
Never change a broken system. It could be worse afterwards.
"No computer system can be absolutely secure." Intel Document Number: 336983-001
"No computer system can be absolutely secure." Intel Document Number: 336983-001
Re: UEFI-Installation: "grub-install dummy" hängt
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.smutbert hat geschrieben:21.03.2018 22:19:43Mir 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).
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]
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.
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.smutbert hat geschrieben:21.03.2018 22:19:43Allerdings 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).
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.
Genau das ist es, was mich momentan umtreibt. Ich weiß, DASS UEFI-Zugang UND Debian-Boot irgendwie gehen muss, denn ich habe es gesehen.NAB hat geschrieben:21.03.2018 22:48:10smutbert, kurzfristig ging ja alles, nämlich hier:
viewtopic.php?f=12&t=169061#p1168614
Das ist der Punkt, den ich momentan interessant finde.
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.
Zunächst mal ist dann auch das UEFI zugänglich, wenn die Endless-HDD angeschlossen ist - warum auch immer. Danke für den Vorschlag!NAB hat geschrieben:21.03.2018 22:48:10Und wenn du Debian bootest, mit angeschlossener Endless HDD, was passiert dann?
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
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.NAB hat geschrieben:21.03.2018 22:48:10Ich 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?
Info am Rande:
Acer bietet als neueste UEFI-Version 1.03 zum Download an. Auf meinem System läuft die gleiche Version.
Re: UEFI-Installation: "grub-install dummy" hängt
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:22.03.2018 00:35:54Da 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.
Ist dieser Eintrag "persistent"? Also ist er immer noch da? (obwohl er nicht funktioniert, da nicht signiert)hikaru hat geschrieben:22.03.2018 00:35:54Über die zweite Option habe ich dann /EFI/debian/grubx64.efi aus dem Debian-EFI registriert.
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?
*hmpf* ... das wäre so die erste leicht nachvollziehbare Fehlfunktion, die man als Bug an Acer melden könnte ...hikaru hat geschrieben:22.03.2018 00:35:54Da ich weder über die erste noch die dritte Option aus dem Code-Block den Debianeintrag wieder deregistrieren konnte,
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:22.03.2018 00:35:54Nach einem Reboot zeigte sich wieder die Acer-Grub-Shell und teilte noch vor dem Prompt mit, dass das Laden dieses Eintrags nicht erlaubt sei.
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:22.03.2018 00:35:54Danach 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.
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?hikaru hat geschrieben:22.03.2018 00:35:54grub-install ohne --removable blieb übrigens hängen, sowohl mit als auch ohne geblacklistetem efivars/efivarfs. /EFI/debian/grubx64.efi wurde dabei allerdings noch abgelegt.
Hängt grub-install auch mit "--no-nvram"?
Es wird wirklich immer kurioser ...hikaru hat geschrieben:22.03.2018 00:35:54Zunächst mal ist dann auch das UEFI zugänglich, wenn die Endless-HDD angeschlossen ist - warum auch immer. Danke für den Vorschlag!
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.hikaru hat geschrieben:22.03.2018 00:35:54Code: Alles auswählen
Boot0001* Linux HD(1,GPT,7e4d7ae3-0837-41bb-8f04-4c61291b261e,0x800,0x1f000)/File(\EFI\endless\shim.efi)RC
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
"No computer system can be absolutely secure." Intel Document Number: 336983-001
Re: UEFI-Installation: "grub-install dummy" hängt
Das habe ich gerade probiert:NAB hat geschrieben:22.03.2018 18:48:42Also Refind lässt dich mit Secure Boot booten? (wobei F2 funktioniert).
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.
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.
Soweit ich das beurteilen kann, kommt diese Grub-Shell immer dann hoch, wenn sonst nichts zum Booten gefunden wird.NAB hat geschrieben:22.03.2018 18:48:42Ach 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?
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.
Ja. Die Dateigrößen stimmen überein. Ich habe einmal sogar die Datei zwischen BOOT/ und debian/ hin- und herkopiert.
Nein. Aber das ändert auch nichts am Bootverhalten.
NAB hat geschrieben:22.03.2018 18:48:42Dabei 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
Das habe ich ganz zum Schluss gemacht:
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:NAB hat geschrieben:22.03.2018 18:48:42Das 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.
Code: Alles auswählen
error: no such device: 4f68-bce3-e8cd-4db1-96e7fbcaf984b709
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/
Re: UEFI-Installation: "grub-install dummy" hängt
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:22.03.2018 23:22:04rEFInd-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.
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.hikaru hat geschrieben:22.03.2018 23:22:04Langsam 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.
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.
Das ist aus zwei Gründen interessant:hikaru hat geschrieben:22.03.2018 23:22:04Soweit 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.
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?
Das meinte ich nicht.hikaru hat geschrieben:22.03.2018 23:22:04Ja. Die Dateigrößen stimmen überein. Ich habe einmal sogar die Datei zwischen BOOT/ und debian/ hin- und herkopiert.
Nein. Aber das ändert auch nichts am Bootverhalten.
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.
Huch? Es wird wirklich immer kurioser. Eventuell hilft ein Power-Off dagegen?hikaru hat geschrieben:22.03.2018 23:22:04Interessanterweise wird seit dem eben durchgeführten Secure-Boot-Experiment der Ubuntu-Stick nicht mehr als Bootoption erkannt, selbst wenn ich Secure Boot wieder ausschalte.
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?
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.hikaru hat geschrieben:22.03.2018 23:22:04Ich 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: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.*Code: Alles auswählen
error: no such device: 4f68-bce3-e8cd-4db1-96e7fbcaf984b709
*) Edit: Diese Kennung nennt sich im UEFI-Kontext wohl "Protokoll":
https://jbeekman.nl/blog/2015/03/revers ... -firmware/
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.
Hmm .. so als grobe Hypothese: Entwederhikaru hat geschrieben:22.03.2018 23:22:04Dann 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.
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.
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.hikaru hat geschrieben:22.03.2018 23:22:04Gibt es sowas wie einen Decompiler für *.efi-Dateien um mal zu schauen, was in dem shim.efi drin steht?
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
"No computer system can be absolutely secure." Intel Document Number: 336983-001
Re: UEFI-Installation: "grub-install dummy" hängt
bootx64.efi aus shim (oder auch aus dem Ubuntu-18.04-Paket) funktionioert ebenfalls, vorausgesetzt, man legt die Datei als EFI/endless/shim.efi ab.NAB hat geschrieben:23.03.2018 17:54:26Ich 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.
Keine zwei der drei Dateien sind identisch.
Das führt zu bootendem Debian aber fehlendem UEFI-Zugriff, egal ob mit shim bzw. bootx64 von Endless, Debian oder Ubuntu.NAB hat geschrieben:23.03.2018 17:54:26Und 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
shim steht unter BSDL (2-Clause). [1] Eine Verpflichtung zur Veröffentlichung von Quellcode besteht daher für Acer/Endless nicht.NAB hat geschrieben:23.03.2018 17:54:26Falls 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 ...
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.
Nachdem ich den Verdacht hatte, dass Reboots möglicherweise nicht ausreichen, habe ich alle weiteren Aktionen grundsätzlich mit Kaltstarts gemacht.NAB hat geschrieben:23.03.2018 17:54:26Nach 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.
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).NAB hat geschrieben:23.03.2018 17:54:26Bei 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.
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.
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:23.03.2018 17:54:26Das ist aus zwei Gründen interessant:hikaru hat geschrieben:22.03.2018 23:22:04Soweit 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.
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?
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:23.03.2018 17:54:262) 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".
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:23.03.2018 17:54:26Nebenbei 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.
Ich fürchte, wir sind beide auf dem Holzweg.NAB hat geschrieben:23.03.2018 17:54:26Uff ... 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.hikaru hat geschrieben:22.03.2018 23:22:04Ich 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: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.*Code: Alles auswählen
error: no such device: 4f68-bce3-e8cd-4db1-96e7fbcaf984b709
*) Edit: Diese Kennung nennt sich im UEFI-Kontext wohl "Protokoll":
https://jbeekman.nl/blog/2015/03/revers ... -firmware/
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.
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:23.03.2018 17:54:26Auf 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.
In dem Archiv unter [3] gibt es abgesehen vom Changelog zwei Dateien in denen "endless" erwähnt wird:NAB hat geschrieben:23.03.2018 17:54:26Hmm .. 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.
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/
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/
Code: Alles auswählen
debian/endless-ca.der
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
Re: UEFI-Installation: "grub-install dummy" hängt
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.
*mist* ... dein UEFI scheint wirklich in den Pfad /endless/shim.efi verliebt zu sein.hikaru hat geschrieben:27.03.2018 10:54:19Das führt zu bootendem Debian aber fehlendem UEFI-Zugriff, egal ob mit shim bzw. bootx64 von Endless, Debian oder Ubuntu.NAB hat geschrieben:23.03.2018 17:54:26Und 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
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.
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:27.03.2018 10:54:19Hier 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.
"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:27.03.2018 10:54:19Ich 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).
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:27.03.2018 10:54:19Kombiniert man das mit der langen Shutdown-Prozedur eines fetten Live-Xubuntu von einem zugegeben nicht blitzschnellen USB-2.0-Stick,
Huch? Da sollten aber welche sein:hikaru hat geschrieben:27.03.2018 10:54:19Auf dem Xubuntu-Stick gibt es neben der iso9660-Partition zwar noch eine fat-Partition, ich finde darauf jedoch keine efi-Dateien.
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.
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:27.03.2018 10:54:19Im 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 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:hikaru hat geschrieben:27.03.2018 10:54:19Ich 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.
https://wiki.gentoo.org/wiki/Efibootmgr/de
Upps ...hikaru hat geschrieben:27.03.2018 10:54:19Ich 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.
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 ...
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.hikaru hat geschrieben:27.03.2018 10:54:19Die 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 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.
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:hikaru hat geschrieben:27.03.2018 10:54:19Was ich noch nicht ganz verstanden habe ist die Rolle von MokManager.efi. Die Datei habe ich bisher ignoriert.
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
"No computer system can be absolutely secure." Intel Document Number: 336983-001
Re: UEFI-Installation: "grub-install dummy" hängt
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).NAB hat geschrieben:27.03.2018 19:34:15Aber ich befürchte, das funktioniert schon deswegen nicht, weil es einen signierten Shim braucht (der von Endless ist ja signiert).
So zumindest die Situation mit abgeschaltetem Secure Boot. Für einen weiteren Test mit Secure Boot bin ich gerade zu faul.
Wir müssen an unserer Kommunikation arbeiten!NAB hat geschrieben:27.03.2018 19:34:15Huch? Das meinte ich eigentlich gar nicht.
[..]
Das meinte ich nicht.
Es kann sein, das ich einen meiner EFI-Reparaturversuche (hin- und herschieben von *.efi-Dateien) von Xubuntu aus durchgeführt habe.NAB hat geschrieben:27.03.2018 19:34:15Das 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.
Oh, Tatsache:
Code: Alles auswählen
# md5sum /mnt/efi/boot/*
6e94c3d33194c89bd327bfaa5871e294 /mnt/efi/boot/bootx64.efi
7dc5588d483932c1215cc6ff785ceb36 /mnt/efi/boot/grubx64.efi
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:27.03.2018 19:34:15Das bezweifele ich nicht, aber warum funktioniert grub-install (ohne --no-nvram) und efibootmgr bei dir?
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.NAB hat geschrieben:27.03.2018 19:34:15Ich war bei der Frage, wie das UEFI funktioniert. Nun gräbst du Endless um, was wohl niemand hier installieren oder benutzen möchte.
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.
Re: UEFI-Installation: "grub-install dummy" hängt
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)
Bleibt dieser Befehl (auch) in endless OS hängen oder funktioniert dann das Booten von Debian und/oder <F2> wieder nicht?
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"