[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: 5502
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
Beiträge: 9705
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
Beiträge: 6271
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
Beiträge: 9705
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: 5502
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
Beiträge: 9705
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: 5502
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
Beiträge: 6271
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: 5502
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
Beiträge: 6271
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
Beiträge: 9705
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
Beiträge: 6271
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: 5502
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
Beiträge: 9705
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
Beiträge: 2305
Registriert: 16.10.2010 13:05:57
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Timbuktu

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:
Fedora 28 Workstation -- openSUSE Leap 42 / Gnome -- Debian 9 (Qnap TS-109/119) -- OmniOS (HP N54L)

Antworten