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

[hikaru]

Hallo,

ich bin gerade beim zweiten Versuch meiner ersten Installation auf einem System ohne Legacy-Boot, bin also gezwungen, UEFI zu nutzen.

Vor mir steht ein Notebook aus der Acer-Spin-B1-Reihe. [1] Da soll idealerweise Stretch mit Backports rauf, Buster nur falls es gar nicht anders geht. Secure Boot im UEFI ist ausgeschaltet.
Installationsziel ist eine SSD (aus meinem Fundus) die im Rahmen der Installation völlig plattgemacht wurde und nun auf GPT eine 512MB-EFI-Partition als /dev/sda1 sowie eine 10GB-Systempartition als /dev/sda2 enthält. Eine Minimalinstallation über den Netinstaller verläuft erfolgreich bis zur Installation von Grub.

Beim Schritt "Installieren des GRUB-Bootloaders" hängt dieser Schritt bei 50%, darunter steht: "Ausführen von »grub-install dummy« . . ." Das ist unabhängig davon, ob ich vorher die Abfrage zum Erzwingen der Installation von GRUB in den "Wechseldatenträgerpfad" bestätige (was fehlschlägt - woraufhin ich letztendlich den gesamten Installationprozess wiederholte) oder ablehne.
In der Konsole (F4) steht dazu (abgetippt):

Code: Alles auswählen

grub-installer: info: Installing grub on 'dummy'
grub-installer: info: grub-install does not support --no-floppy
grub-installer: info: Running chroot on /target grub-install --force "dummy"
grub-installer: Installing for x86_64-efi platform.

In diesem Zustand steht die Konsole nun etwa eine halbe Stunde. Suchen im Netz blieben erfolglos, denn mit den Stichworten "debian grub install dummy" komme ich immer zu Lösungsvorschlägen für eine Fehlermeldung wie in [2]. Aber bis zu dieser Fehlermeldung komme ich ja gar nicht.

Nach dem ersten fehlgeschlagenen Versuch mit dem selben Ergebnis habe ich den Rechner einfach hart rebootet wonach ich ein nacktes Grub-Prompt bekam mit dem ich nicht viel anfangen konnte. Über [3] bin ich zum "rEFInd Boot Manager"-Live-System [4] gekommen, mit dem ich zwar das installierte Debian booten kann, da die Installation aber noch nicht abgeschlossen ist und daher noch keine Nutzer eingerichtet sind, kann ich mich nicht einloggen.

Vom hängenden Installer aus kann ich in das Zielsystem chrooten. Rufe ich von dort aus grub-install /dev/sda auf, dann bleibt auch das hängen. (Keine Ahnung ob der Ansatz bei UEFI überhaupt sinnvoll ist.)

Im Wesentlichen schaue ich gerade wie das sprichwörtliche Schwein in's Uhrwerk. Kann mir jemand weiterhelfen?


[1] https://www.notebookcheck.com/Test-Acer ... 936.0.html
[2] viewtopic.php?t=164827
[3] https://wiki.debian.org/GrubEFIReinstall
[4] http://www.rodsbooks.com/refind/getting.html

[smutbert]

Ein Gerät als Installationsziel anzugeben (wie in "grub-install /dev/sda") hat afaik keinen Sinn – grub wird ja sowieso nach »/boot/efi/...« installiert, vorausgesetzt dort ist auch eine FAT-formatierte Partition gemountet, auf die der Booteintrag verweisen kann, der dann im nvram angelegt wird.

Hier hätte ich auch als erstes das Problem vermutet und versucht grub zu installieren ohne einen Booteintrag anzulegen.
Also mit "Wechseldatenträgerpfad", aber zusätzlich ohne Änderung im nvram, keine Ahnung wie man das aus dem Installer heraus bewerkstelligen könnte, bei der manuellen Installation wären es zB die Optionen

Code: Alles auswählen

# grub-install --force-extra-removable --no-nvram

(eventuell wahlweise --removable statt --force-extra-removable)
Das könntest du zumindest bei einer Experteninstallation, bei der du den Bootloader zuerst überspringst und dann selbst installierst oder bei einer Installation mit debootstrap ausnutzen.

Der Vorschlag beruht aber darauf, dass die Ursache des Problems ist, dass das Schreiben ins nvram so scheitert, dass zumindest dieser Prozess oder eines oder mehrere der beteiligten Kernelmodule (efivars, efivarfs, efi_pstore) ganz widerlich hängenbleiben (das kenne ich von einigen zickigen uefi-Systemen oder auch von 64Bit-Systemen mit 32Bit-uefi).

Es kann aber auch etwas anderes sein. Hier ist die Rede von ein paar "Acer-Besonderheiten" [1], inklusive einem Lösungsvorschlag [2], der das Aktivieren (!) von "Secure Boot" beinhaltet (da müsste man unter Debian wohl etwas kreativ sein).

Was ich noch nicht ganz verstehe: Die Einrichtung der Benutzer erfolgt doch vor der Bootloaderinstallation, die doch normalerweise ziemlich zum Schluss kommt, oder?
(aber wenn das so ist, wäre refind doch zumindest ein funktinierender Workaround)

Edit:
Hast du eine Idee, was mit dem "dummy" auf sich hat? Ich glaube das sehe ich zum ersten Mal.

[1] https://forum.ubuntuusers.de/topic/efi- ... aegt-fehl/
[2] https://wiki.ubuntuusers.de/EFI_Problem ... er-Rechner

[NAB]

sda1 hat das ESP/Bootable Flag? (gparted)

Kannst du irgendwo beobachten, ob sda1 nach /boot/efi gemounted wird?

Kennst du den hier?
https://ubuntuforums.org/showthread.php?t=2330915
Sieht nach vielen betroffenen Braswells aus. Aber deiner ist Apollo Lake, oder?

die Abfrage zum Erzwingen der Installation von GRUB in den "Wechseldatenträgerpfad" bestätige (was fehlschlägt

Lässt sich dazu irgendwo eine Fehlermeldung ausgraben?

P.S.: Hier:
https://askubuntu.com/questions/946886/ ... 18-rn-p7xq
hat jemand das Problem speziell auf einem Acer Spin B1 auseinandergenommen, leider auch ohne "freundliche" Lösung.
Mir fällt in seinem BootLog auf paste2.org auf, dass da anscheinend ein zusätzlicher BIOS-Grub im MBR sitzt, ohne Erläuterung, wo der herkommen mag. Er sagt ausdrücklich, er hätte kein weiteres Gerät mit M.2-Slot. Eventuell beherrscht der Rechner doch einen BIOS-Boot?

[hikaru]

Ich habe jetzt einen dritten Versuch (alle mit Experteninstaller) gemacht und dabei die Grub-Installation übersprungen. Das System kann ich dann über rEFInd booten.

Code: Alles auswählen

# grub-install --force-extra-removable --no-nvram

(eventuell wahlweise --removable statt --force-extra-removable)

Dazu müsste ich erstmal Grub installieren. grub2-common allein stellt aber grub-install nicht bereit. grub-efi-amd64 ist anscheinend das Paket das auch den Installer lahmgelegt hat, denn aus dem gebooteten System wird die Konfiguration nicht fertig. Keine Fehlermeldug, keine CPU-Last, einfach gar nichts. apt bleibt einfach stehen. Teilweise produziert die Installation sogar eine Kernel-Panic.
Im Call Trace steht dann das (abgetippt):

Code: Alles auswählen

? follow_managed+0x275/0x310
? kmem_cache_alloc+0x11a/0x5a0
? dput+0x2f/0x1f0
? efi_call+0x58/0x90
? virt_efi_query_variable_info.part.4+0x59/0x100
? efi_query_variable_store+0xac/01b0
? __kmalloc_track_caller+0x182/0x5d0
? efivar_entry_set_get_size+0xb4/0x1c0
? efivar_entry_set_get_size+0xb4/0x1c0
? efivarfs_file_write+0xb0/0x160 [efivars]
? vfs_write+0xb0/0x190
? SyS_write+0x52/0xc0
? SyS_ioctl+0x74/0x80
? system_call_fast_compare_end+0xc/0x6f
Code:  Bad RIP value.
RIP: 0x230 RSP: ffffae3640a53b68

Das passiert mit und ohne intel-microcode, mit Kernel 4.9 und 4.14 (bpo).

Es kann aber auch etwas anderes sein. Hier ist die Rede von ein paar "Acer-Besonderheiten" [1], inklusive einem Lösungsvorschlag [2], der das Aktivieren (!) von "Secure Boot" beinhaltet (da müsste man unter Debian wohl etwas kreativ sein).

Im Moment komme ich nicht mal mehr in's UEFI. Das Drücken von F2 beim Booten produziert gerade nur einen Unterstrich in der linken oberen Bildschirmecke (F12-Bootmenü und booten via rEFInd funktioniert aber).

Was ich noch nicht ganz verstehe: Die Einrichtung der Benutzer erfolgt doch vor der Bootloaderinstallation, die doch normalerweise ziemlich zum Schluss kommt, oder?

Die Benutzerdaten werden recht früh abgefragt, aber die eigentliche Einrichtung passiert erst kurz vor Ende der Installation (ginge vor der Installation des Grundsysstems eh nicht).

Edit:
Hast du eine Idee, was mit dem "dummy" auf sich hat? Ich glaube das sehe ich zum ersten Mal.

Nein.

sda1 hat das ESP/Bootable Flag? (gparted)

Wie prüfe/setze ich das ohne GUI (habe ich noch nicht installiert)? Früher ging das mit cfdisk. Da sehe ich auf dem Gerät aber nichts zu Bootflags.

Kannst du irgendwo beobachten, ob sda1 nach /boot/efi gemounted wird?

Ja, laut Ausgabe von mount ist das rw gemountet.

Kennst du den hier?
https://ubuntuforums.org/showthread.php?t=2330915

Ich glaube. das ist was anderes. Die Meldungen sehen anders aus und bei mir ist auch nicht der ganze Rechner fest, sondern nur die betroffene Konsole (teils komme ich sogar mit Ctrl+c wieder frei).

die Abfrage zum Erzwingen der Installation von GRUB in den "Wechseldatenträgerpfad" bestätige (was fehlschlägt

Lässt sich dazu irgendwo eine Fehlermeldung ausgraben?

Ich wüsste nicht wie (außer neuinstallieren und abschreiben). Das war einer von diesen Installer-Redscreens. Aber ich denke über das Stadium bin ich mit dem prinzipiell bootfähigen System eh hinaus.

[smutbert]

Oh, vergessen zu erwähnen

[…]grub-efi-amd64 ist anscheinend das Paket das auch den Installer lahmgelegt hat, denn aus dem gebooteten System wird die Konfiguration nicht fertig. Keine Fehlermeldug, keine CPU-Last, einfach gar nichts. apt bleibt einfach stehen. Teilweise produziert die Installation sogar eine Kernel-Panic.[…]

deshalb habe ich das Modul efivars (vielleicht auch zusätzlich efivarfs) auf problematischen uefi-Systemen vor der grub-Installation nachhaltig geblacklisted, auf diese Art:
viewtopic.php?f=25&t=168490&start=15#p1163271

(alternativ genügt es vielleicht auch das Ändern der Variablen im nvram zu deaktivieren - zumindest wenn die debconf-Priorität auf low ist wird nachgefragt)

(abgesehen von der Manipulation vom nvram sollte die grub-Installation ja wirklich harmlos und keinesfalls hängenbleiben)

[NAB]

Wie prüfe/setze ich das ohne GUI (habe ich noch nicht installiert)? Früher ging das mit cfdisk. Da sehe ich auf dem Gerät aber nichts zu Bootflags.

parted -l

cfdisk nennt es:

Code: Alles auswählen

Partition type: EFI System (C12A7328-F81F-11D2-BA4B-00A0C93EC93B)

Ich wüsste nicht wie (außer neuinstallieren und abschreiben). Das war einer von diesen Installer-Redscreens. Aber ich denke über das Stadium bin ich mit dem prinzipiell bootfähigen System eh hinaus.

Das wäre aber prinzipiell interessant - zumindest wenn du über F4 etwas mehr sehen kannst als einen Redscreen. Das sieht in der Tat so aus - wie von smutbert vermutet - als ob er sich beim Schreiben der EFI-Variablen weghängt. Wenn er den "Wechseldatenträgerpfad" benutzt, macht er das nicht, produziert aber einen weiteren Fehler. Ich vermute daher, dass es zwei verschiedene Fehler gibt.

Andererseits müsste --removable den gleichen Effekt erzielen ... falls du das irgendwie zum Laufen kriegst.

Hast du mal geguckt, was efibootmgr dazu sagt?

Hast du meine Ergänzung oben noch gelesen? Da ist von "Endless OS" die Rede ... eventuell kann man sich von dem was abgucken. Ich vermute, da gibt's irgendeinen BIOS-Boot-Trick.

Hier:
https://www.amazon.de/Acer-TravelMate-T ... B06XW7GG6L
"Benutzung des Geräts mit Ubuntu 17.10 (Gnome3)
Von tommex am 27. November 2017"
ist er ebenfalls der Meinung, ein BIOS-Boot funktioniert (und löst alle Probleme). Und gegen dein F2-Problem soll das Löschen aller Partitionen helfen (vermutlich reicht es, die ESP-Partition zu löschen).

[hikaru]

deshalb habe ich das Modul efivars (vielleicht auch zusätzlich efivarfs) auf problematischen uefi-Systemen vor der grub-Installation nachhaltig geblacklisted, auf diese Art:
viewtopic.php?f=25&t=168490&start=15#p1163271

Danke für den Hinweis! Ich muss zugeben, das ich dir hier momentan nur blind folge. Wirklich verstehen was da passiert tue ich noch nicht.
Ich habe jetzt mal beides geblacklistet und nun läuft zumindest die Installation von grub-efi-amd64 ohne Fehler durch. Booten kann ich deshalb leider noch nicht, auch nicht nach:

Code: Alles auswählen

grub-install --removable --no-nvram

Aber ich kann in der Grub-Shell von Debian nach dem Muster aus [1] von Hand booten, und das halbwegs komfortabel. Vorher hatte ich wohl eine Grub-Shell direkt von Acer und die konnte weder "bash-Completion)noch konnte sie tatsächlich Kernel laden.
Nun brauche ich wohl nur noch eine funktionierende Grub-Konfiguration. In's UEFI (F2) komme ich nach wie vor nicht mehr.


@Nab:
Deinen Hinweisen gehe ich morgen nach. Die ausgebaute (und fast jungfräuliche) Endless-HDD habe ich noch hier rumzuliegen. Mein Hauptproblem ist wohl momentan, das ich noch viel zu wenig von UEFI-Boot verstehe um überhaupt zu wissen, worauf ich achten muss.


[1] https://www.linux.com/learn/how-rescue- ... ub-2-Linux

[NAB]

hikaru, du müsstest jetzt zwei Bootloader haben. Einmal:
/boot/efi/EFI/BOOT/BOOTX64.EFI
(das ist der removable media path)
(Groß/Klein-Schreibung ist auf FAT im Zweifelsfall egal)

und:
/boot/efi/EFI/debian/grubx64.efi
(das ist der kaputte)

Deine Theorie hat übrigens einen Haken: Wenn die Endless-HDD daneben liegt, wie kommt dann ein Acer Grub auf deine SSD? (Nein, ich habe auch keine Erklärung. Ich hab mich auch schon gefragt, wo der vorhandene Grub herkommt. Wenn der wirklich von Acer kommt, dann müsste er ins UEFI eingebaut sein, also auch ohne SSD starten. Sowas habe ich noch nie gehört. Andererseits - wenn er von Debian stammt, dann dürfte er gar nicht starten, ohne ins NVRAM eingetragen zu sein)

Ich würde jetzt versuchen, den zweiten Bootloader da raus zu schieben und hoffen, dass er dann vom ersten reibungslos bootet. Aber da ich aus eben erwähnten Gründen selber verwirrt bin, was dein UEFI da treibt, mag ich dir dazu nicht raten.

Deinen Hinweisen gehe ich morgen nach. Die ausgebaute (und fast jungfräuliche) Endless-HDD habe ich noch hier rumzuliegen.

Interessant wäre:
MBR oder GPT?
EFI ESP Partition vorhanden?
Ja -> Wo liegt der Bootloader?
bios_grub Partition vorhanden?

Mein Hauptproblem ist wohl momentan, das ich noch viel zu wenig von UEFI-Boot verstehe um überhaupt zu wissen, worauf ich achten muss.

Dein Hauptproblem ist, dass du dir für dein erstes UEFI-Erlebnis ein schrottes UEFI ausgesucht hast. Sonst wärst du längst fertig und diesen Thread gäb's gar nicht.

Worauf ich hinaus will ist, dass du eben keinen UEFI-Boot machst sondern einen BIOS-Boot. Den Hinweisen nach scheint das zu gehen.

Wenn du abenteurlustig bist, kannst du es so versuchen: ESP-Partition löschen oder verkleinern, bios_grub/ef02 Partition anlegen, 1MB groß, gemäß:
https://wiki.ubuntuusers.de/GRUB_2/Grundlagen/
und dann grub-efi entfernen und grub-pc installieren. grub-install /dev/sda

[owl102]

Gibt es ein BIOS/UEFI Update von Acer?

[hikaru]

Heute morgen fiel mir beim Aufwachen beim Gedanken an die leere Debian-Grub-Shell ein, dass ich ja noch gar keine Grub-Konfiguration (update-grub) erstellt habe. Das habe ich beim Frühstück nachgeholt und Grub nochmal nach smutberts Beispiel installiert und seitdem habe ich beim Boot von der SSD ein ganz gewöhnliches Grub-Menü das auch sauber Debian bootet.
Ich komme nun übrigens auch wieder über F2 in's UEFI/BIOS. Insofern ist das Thema eigentlich gelöst, wenn ich mich mit dem Würgaround des Blacklistens von efivars abfinde.

hikaru, du müsstest jetzt zwei Bootloader haben. Einmal:
/boot/efi/EFI/BOOT/BOOTX64.EFI
(das ist der removable media path)
(Groß/Klein-Schreibung ist auf FAT im Zweifelsfall egal)

und:
/boot/efi/EFI/debian/grubx64.efi
(das ist der kaputte)

Einen davon habe ich definitiv gestern schon gesehen, ich erinnere mich aber nicht mehr welchen.

Deine Theorie hat übrigens einen Haken: Wenn die Endless-HDD daneben liegt, wie kommt dann ein Acer Grub auf deine SSD? (Nein, ich habe auch keine Erklärung. Ich hab mich auch schon gefragt, wo der vorhandene Grub herkommt. Wenn der wirklich von Acer kommt, dann müsste er ins UEFI eingebaut sein, also auch ohne SSD starten. Sowas habe ich noch nie gehört.

Nun, im Gegensatz zum Debian-Grub wird der Acer-Grub über das Acer-Boot-Logo eingeblendet. Es gibt nicht mal ein Bildschirmflackern oder etwas Ähnliches, das es erlauben würde, zwischen POST und Bootloaderstart zu unterscheiden. Es ist einfach irgendwann ein Grub-Prompt da.
Angesichts der weitgehend fehlenden Kommandos vermute ich, dass da ein "halbes Grub" im UEFI steckt, das zwar grundsätzlich eine Grub-Shell starten kann, die meisten Kommandos kommen dann aber wohl doch von der HDD/SSD.

Deinen Hinweisen gehe ich morgen nach. Die ausgebaute (und fast jungfräuliche) Endless-HDD habe ich noch hier rumzuliegen.

Interessant wäre:
MBR oder GPT?

GPT.

EFI ESP Partition vorhanden?
Ja -> Wo liegt der Bootloader?
bios_grub Partition vorhanden?

Muss ich prüfen.
(Das Endless ist im Kern übrigens ein Wheezy/Sid mit Kernel 4.8 und Gnome.)

Worauf ich hinaus will ist, dass du eben keinen UEFI-Boot machst sondern einen BIOS-Boot. Den Hinweisen nach scheint das zu gehen.

Laut dem was ich im UEFI/BIOS sehe und einiger Hinweise im Netz geht da kein Legacy-Boot.

Wenn du abenteurlustig bist, kannst du es so versuchen: ESP-Partition löschen oder verkleinern, bios_grub/ef02 Partition anlegen, 1MB groß, gemäß:
https://wiki.ubuntuusers.de/GRUB_2/Grundlagen/
und dann grub-efi entfernen und grub-pc installieren. grub-install /dev/sda

Nach dem Erfolg von heute morgen wollte ich das System jetzt eigentlich nicht mehr zerwürgen (inzwischen habe ich auch einen Desktop installiert).
Aber vielleicht habe ich noch eine ungenutzte HDD für weitere Tests rumzuliegen. Die Endles-HDD lässt sich zumindest ohne Weiteres auch über USB booten, so dass Tests mit externem Installationsziel kein großer Aufwand sein sollten.

Gibt es ein BIOS/UEFI Update von Acer?

Offenbar nur als Win10-Exe. [1] Was da im Detail drin steckt müsste ich mal prüfen.

[1] https://www.acer.com/ac/en/US/content/s ... t/7238?b=1

[smutbert]

Mir geht es da wie NAB, ich habe keine Ahnung was das Acer-UEFI (oder andere verkorkste UEFIs) da machen. Ich habe nur die Erfahrung gemacht, dass die Probleme so gut wie immer von den Bootvariablen im nvram kommen, die vom UEFI nicht gespeichert, wieder gelöscht,... werden oder sogar ganz allgemein davon, dass Schreibzugriffe auf das nvram nicht funktionieren und möglicherweise hängenbleiben oder gleich den Linuxkernel crashen.

Bei einigermaßen vernünftigen uefi-Implementationen kann man im Grunde jedes .efi-Executable booten, das in einem vom uefi lesbaren Dateisystem liegt, es muss nur der passende Booteintrag im nvram angelegt werden. Damit die Variablen im nvram verändert werden können ist das Kernelmodul efivars/efivarfs notwendig, das die Variablen im sysfs abbildet als wären es normale Dateien (/sys/firmware/efi/efivars).

Wenn die Kernelmodule nicht geladen sind, kann im nvram auch nichts verändert werden und es gibt keine Probleme, dafür muss man eben dafür sorgen, dass das uefi den Bootloader auch ohne Booteintrag findet und dafür sorgt der "removable media path". (Tatsächlich läuft es afaik so ab, dass das uefi beim Start alle für das uefi lesbaren Dateisysteme aller angeschlossenen Datenträger nach EFI/BOOT/BOOTX64.EFI absucht und für die gefundenen einen Booteintrag im nvram anlegt.)
Es genügt glaube ich sogar direkt vor dem Ausführen von grub-install das Kernelmodul efivars zu entladen, denn efibootmgr, das Programm, das die Manipulation der Booteinträge im nvram übernimmt, lädt das Kernelmodul glaube ich nicht automatisch und beendet sich dann unverrichteter Dinge wieder.

Nun, im Gegensatz zum Debian-Grub wird der Acer-Grub über das Acer-Boot-Logo eingeblendet. Es gibt nicht mal ein Bildschirmflackern oder etwas Ähnliches, das es erlauben würde, zwischen POST und Bootloaderstart zu unterscheiden. Es ist einfach irgendwann ein Grub-Prompt da.
Angesichts der weitgehend fehlenden Kommandos vermute ich, dass da ein "halbes Grub" im UEFI steckt, das zwar grundsätzlich eine Grub-Shell starten kann, die meisten Kommandos kommen dann aber wohl doch von der HDD/SSD.

Wenn du das ergründen willst, könntest du in diesem Acer-Grub vielleicht einmal den Befehl "set" ausführen. Das sollte (denke ich) zumindest verraten woher dieser grub seine Module und Konfigurationsdatei laden wollte (prefix, root).

[NAB]

Also ich würd's so lassen wie es jetzt ist - es geht ja alles.

Die Endles-HDD lässt sich zumindest ohne Weiteres auch über USB booten, so dass Tests mit externem Installationsziel kein großer Aufwand sein sollten.

Damit ist eine meiner Theorien hinfällig. Die ging so:
1) Das UEFI kann durchaus einen Legacy Boot, unterbindet den aber an den USB-Ports.
2) Endless OS führt einen Legacy Boot durch.
Ich vermute nun, Endless OS bootet einfach über den removable media path, genau wie Debian jetzt auch.

Laut dem was ich im UEFI/BIOS sehe und einiger Hinweise im Netz geht da kein Legacy-Boot.

Der Herr aus den Amazon-Bewertungen ist überzeugt, dass es geht ... nur nicht von USB aus.

[hikaru]

Wenn du das ergründen willst, könntest du in diesem Acer-Grub vielleicht einmal den Befehl "set" ausführen. Das sollte (denke ich) zumindest verraten woher dieser grub seine Module und Konfigurationsdatei laden wollte (prefix, root).

Ich weiß leider nicht, wie ich da ran komme. Seitdem die Debian-Grub-Konsole funktioniert, sehe ich den Acer-Grub nicht mehr.

Laut dem was ich im UEFI/BIOS sehe und einiger Hinweise im Netz geht da kein Legacy-Boot.

Der Herr aus den Amazon-Bewertungen ist überzeugt, dass es geht ... nur nicht von USB aus.

Bevor ich die SSD zur Installation plattgemacht hatte befand sich darauf eine Legacy-Stretch-Installation mit MBR. Die hat das UEFI des Acer nicht mal als Bootoption angeboten, weder vor noch nach der Deaktivierung von Secure Boot.
Vielleicht lag es nur am MBR (statt GPT), aber ich nahm das als Zeichen dafür, dass hier nur UEFI-Boot geht.

[NAB]

Bevor ich die SSD zur Installation plattgemacht hatte befand sich darauf eine Legacy-Stretch-Installation mit MBR. Die hat das UEFI des Acer nicht mal als Bootoption angeboten, weder vor noch nach der Deaktivierung von Secure Boot.
Vielleicht lag es nur am MBR (statt GPT), aber ich nahm das als Zeichen dafür, dass hier nur UEFI-Boot geht.

Guter Hinweis! Beim Legacy Boot sollte es keinen Unterschied zwischen MBR und GPT geben. GPT enthält ja auch einen "protective MBR", in dem der Bootloader dann steckt.

Damit ist die Idee mit dem Legacy Boot wohl hinfällig.

[hikaru]

Irgendwas ist hier faul. Als letztes noch vebleibendes Problem wollte ich die Lautstärkeregelung angehen, denn die Tastenkombinationen (Fn+Pfeil hoch/runter) taten nichts.
Installiert ist Xfce mit Pulseaudio. Im Netz fand ich Hinweise, xfce4-pulseaudio-plugin in's Panel zu holen und dort den Haken für die Tastatursteuerung zu setzen. Das tat ich, die Regler in pavucontrol und im OSD gingen auch lustig rauf und runter, aber die Laustärke änderte sich nicht (Stummschalten über Fn+F8 hingegen schon).
Den einsamen Master-Regler im Alsamixer zu verändern brachte auch nichts.

Als Lösung fand ich einen Tipp, options snd-hda-intel model=auto nach /etc/modprobe.d/alsa-base.conf zu schreiben und zu rebooten. [1] Gesagt getan und siehe da, Lautstärkeregelung geht.
Allerdings ging jetzt das Touchpad nicht mehr, der Touchscreen hingegen schon. Beides zusammen wird in lsusb als ein Gerät erkannt (40201). Das Problem hatte ich gestern schon während der Grub-Orgie. Darum wollte ich mich aber später kümmern. Als dann die Debian-Grub-Konsole lief, trat spontane Selbstheilung beim Touchpad ein und ich hatte die Sache eigentlich schon ad acta gelegt.

Als zeitlich passende Ursachen für die Selbstheilung stehen auf meiner Liste:
1. versehentliches Suspend2RAM
2. zwischenzeitliches Booten von "Endless"
3. zwischenzeitliches Booten des Xubuntu-18.04-Beta1-Live-Systems
4. grub-install von Debian aus mit geblacklistetem efivars+efivarfs

Nichts davon brachte mir jetzt das Touchpad zurück. Xubuntu hing sich beim Runterfahren auf, so dass ich die Kiste hart auschalten musste. Seitdem komme ich auch nicht mehr in's UEFI (Unterstrich nach Drücken auf F2). Debians Grub funktioniert aber nach wie vor tadellos.


[1] https://askubuntu.com/questions/978789/ ... ot-working

[NAB]

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 ...

[hikaru]

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.

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.

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.

[smutbert]

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).

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.)

[hikaru]

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]

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 ...

[hikaru]

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]

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.

[smutbert]

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]

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.

[smutbert]

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)