Plötzlich: Booten von SATA-SSD nicht mehr möglich [gelöst]

[mitscherdinger]

Als Workaround würde ich von Debian aus die grub-Datei dorthin kopieren, wo sie das UEFI auch ohne eigens erstellten Booteintrag finden sollte

Code: Alles auswählen

# cp /boot/efi/EFI/debian/grubx64.efi /boot/efi/EFI/boot/bootx64.efi

/boot/efi/EFI/boot gibt's gar nicht, /boot/efi/EFI/debian schon. Ich erstelle einfach mal das fehlende Verzeichnis und kopier bootx64.efi da rein…
Dann mal schaun, was passiert...

[mitscherdinger]

Mein Biostar-UEFI gibt mir die Möglichkeit, komplett auf "Legacy" umzustellen. Das war bisher wohl auch der Stand, denn sobald ich angebe, dass nur noch UEFI-Einträge gebootet werden sollen, geht gar nichts mehr: Weder Ubuntu, noch Debian werden angezeigt. Auch nicht nach dem Kopieren von bootx64.efi in /boot/efi/EFI/boot/. Ich kann noch nicht einmal einzelne Festplatten auswählen, von denen gebootet werden sollen.

So, und hier ist der Unterschied zwischen der Ubuntu-Partition und der root-Partition von Debian, wenn ich mittels fdisk die Parameter auslese: /dev/sdb hat den * in der Boot-Spalte, bei /dev/sda taucht die gar nicht erst auf UND fdisk listet noch nicht einmal die Möglichkeit, die Boot-Flag zu setzen… Das liegt wohl an unterschiedlichen Partitions-Tabellen...

Die Frage ist nur: Wie konnte mein Mainboard bisher Debian ohne Boot-Flag booten? Und wie bekomme ich diesen Zustand wieder her?

[NAB]

Deine ESP-Partition hat ein Boot-Flag. Es lautet "EF00".

Du hast eine GPT-Partitionstabelle mit einer EFI ESP Partition. Für einen BIOS-Boot bräuchtest du eine bios_grub-Partition. Dein System mounted diese ESP-Partition unter /boot/efi, was für einen BIOS-Boot völlig sinnlos wäre.

Entweder hat jemand dein System heimlich gründlich umgebaut, während du nicht hingeguckt hast, oder es macht schon immer einen UEFI-Boot.

Dass Ubuntu einen BIOS-Boot macht, ist eine völlig andere Geschichte. Und es ist logisch, dass Ubuntu nicht mehr gefunden wird, wenn du BIOS-Boot (legacy) ausschaltest.

[mitscherdinger]

Okay… Dann probiere ich nochmal Deinen Vorschlag mit dem grub-install…

[smutbert]

[...] noch Debian werden angezeigt. Auch nicht nach dem Kopieren von bootx64.efi in /boot/efi/EFI/boot/.[...]

Du hast auch keinen Tippfehler beim Kopieren gemacht?

Der Vollständigkeit halber würde ich noch NABs Tipp versuchen mit einer kleinen Änderung, also vom laufenden Debian aus

Code: Alles auswählen

# grub-install --force-extra-removable

ausführen.

Dass Secure Boot deaktiviert ist, hast du überprüft?

Die Alternative wäre, wie Jana es zu Beginn vorgeschlagen hat, Debian mit Hilfe der Super Grub Disk im EFI Modus zu booten und dann erstens endlich von "efibootmgr -v" eine brauchbare Ausgabe zu erhalten und zweitens nötigenfalls den grub noch einmal richtig neu zu installieren.


und weil es zumindest theoretisch möglich wäre:
Einen Hardwarefehler hast du ausgeschlossen?
(ich habe bei einem defekten SATA-Kabel oder -Stecker/-buchse erlebt, dass die SSD bevor ein Betriebssystem gestartet wurde nicht funktioniert hat. Erst beim Start des Betriebssystems hat der SATA-Treibers wegen der Fehler in einen langsameren Übertragungsmodus geschaltet und von da an ist es fehlerfrei gelaufen.
Wird die SSD im BIOS richtig erkannt?)

[NAB]

Okay… Dann probiere ich nochmal Deinen Vorschlag mit dem grub-install…

Der sollte das selbe machen wie smutberts Ansatz, nämlich den Bootloader nach /boot/efi/EFI/boot/bootx64.efi schreiben. Das ist der standardisierte "Removable Media Path", den Medien wie Live-DVDs benutzen sollen, die ja keinen ins NVRAM eingetragenen Bootloader haben (können).

Wenn dein UEFI selbst den ignoriert, ist es wirklich etwas dämlich. Die Frage ist, wie ist es so dämlich geworden?

Neben smutberts Hinweisen würde ich mal einen gründlichen Kaltstart machen. Also Stromstecker raus, Ein-Schalter kurz drücken (um die Kondensatoren zu entladen), langsam bis 100 zählen, Stromstecker wieder rein und gucken, ob das UEFI die Festplatte wieder zur Kenntnis nimmt.

Die andere Frage ist, warum dein System die Efivars nicht zugänglich macht. lsmod sollte eigentlich drei Einträge zeigen:

Code: Alles auswählen

# lsmod | grep efi
efi_pstore             16384  0
efivars                20480  1 efi_pstore
efivarfs               16384  1

Wenn es das nicht tut, könntest du es mit:
modprobe efivars
modprobe efivarfs
versuchen. Und dann mal das Ende von "dmesg" auf Fehlermeldungen prüfen.
Wenn du keine siehst, sollte efibootmgr -v eigentlich funktionieren.

[smutbert]

[…]
Die andere Frage ist, warum dein System die Efivars nicht zugänglich macht.[…]

Das ist der Fall, weil der TE sein Debian mit Hilfe des grub des auf der externen Festplatte im BIOS-Modus installierten Ubuntu gebootet hat und die efivariablen nur zugänglich sind, wenn auch im efi-Modus gebootet wurde.

[mitscherdinger]

Du hast auch keinen Tippfehler beim Kopieren gemacht?

Code: Alles auswählen

# ls -l /boot/efi/EFI/debian/grubx64.efi 
-rwx------ 1 root root 154112 Mär 30 16:56 /boot/efi/EFI/debian/grubx64.efi
# ls -l /boot/efi/EFI/boot/grubx64.efi 
-rwx------ 1 root root 154112 Mär 30 18:44 /boot/efi/EFI/boot/grubx64.efi

Schaut net so aus…

Dass Secure Boot deaktiviert ist, hast du überprüft?

Ja. Das habe ich extra nochmal im UEFI gecheckt.

Einen Hardwarefehler hast du ausgeschlossen? […] Wird die SSD im BIOS richtig erkannt?

Ist beim Bootscreen sichtbar, ist im UEFI als Boot-Device auswählbar UND bei der Boot-Device-Schnellauswahl mit [F9] aufgelistet. Sollte tun.

lsmod sollte eigentlich drei Einträge zeigen:

Code: Alles auswählen

# lsmod | grep efi
efi_pstore             16384  0
efivars                20480  1 efi_pstore
efivarfs               16384  1

Da ist bei mir kein Kernelmodul vorhanden. Und modprobe sagt, warum:

Code: Alles auswählen

# modprobe efivars
modprobe: ERROR: could not insert 'efivars': No such device
# modprobe efivarfs
modprobe: ERROR: could not insert 'efivarfs': No such device

Ich nehme mir mal Morgen Eure weiteren Ratschläge zur Brust. Jetzt ist erstmal Feierabend. Danke bis hierher!

[NAB]

Das ist der Fall, weil der TE sein Debian mit Hilfe des grub des auf der externen Festplatte im BIOS-Modus installierten Ubuntu gebootet hat und die efivariablen nur zugänglich sind, wenn auch im efi-Modus gebootet wurde.

*stirnpatsch* ... natürlich ... du hast Recht!

mitscherdinger, du musst den Rechner irgendwie im UEFI-Modus booten, damit die Efivars vorhanden sind. Die Supergrub2Disk wäre da die einfachste Möglichkeit, die mir einfällt. Die ist winzig und passt auf den kleinsten USB-Stick,den du hast (per dd auf /dev/sdX schreiben). Dann schaltest du am Besten "legacy" aus, so dass er nur "UEFI" bootet. Und dann versuchst du, mit der SuperGrub2Disk dein Debian zu starten.

Mir kommt gerade der leise Verdacht, dass das UEFI vielleicht generell in einen BIOS-Modus schaltet, sobald es BIOS-Geräte entdeckt (also die Ubuntu-Platte). Wenn du die Ubuntu-Platte abziehst, kannst du dann Debian starten (per F9)?

[rendegast]

# ls -l /boot/efi/EFI/boot/grubx64.efi
-rwx------ 1 root root 154112 Mär 30 18:44 /boot/efi/EFI/boot/grubx64.efi

Dort soll die Datei nach obiger Anleitung "bootx64.efi" heißen.

[mitscherdinger]

Zack! Und schon lässt sich die Debian-Partition wieder booten!
Danke! Und sorry, war spät gestern!

Die efi-kernel-module sind geladen!

Code: Alles auswählen

# efibootmgr -v
BootCurrent: 0003
Timeout: 2 seconds
BootOrder: 0003,0001,0002
Boot0001* CD/DVD Drive 	BBS(CDROM,,0x0)..GO..NO........m.H.L.-.D.T.-.S.T.D.V.D.-.R.O.M. .D.H.1.0.N....................A.........................>..Gd-.;.A..MQ..L. . . . . . . . . . . . . . . . . . . . ........BO
Boot0002* Hard Drive 	BBS(HD,,0x0)..GO..NO........m.T.O.S.H.I.B.A. .Q.3.0.0......................A.........................>..Gd-.;.A..MQ..L.6.5.B.K.5.5.W.H.1.K.U.P. . . . . . . . ........BO..NO........[.G.e.n.e.r.i.c. .6.0.0.0....................A..........................Gd-.;.A..MQ..L.G.e.n.e.r.i.c. .6.0.0.0........BO..NO........u.A.s.m.e.d.i.a. .1.0.5.3.-.3.G. .E.x.t... .H.D.D.0....................A.......................H..Gd-.;.A..MQ..L.A.s.m.e.d.i.a. .1.0.5.3.-.3.G. .E.x.t... .H.D.D.0........BO
Boot0003* UEFI OS	HD(1,GPT,77768245-4cf4-425d-a376-a32ae5fd5ccb,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)..BO

ABER:

Code: Alles auswählen

# grub-install 
x86_64-efi wird für Ihre Plattform installiert.
Could not prepare Boot variable: No space left on device
grub-install: Fehler: efibootmgr failed to register the boot entry: Eingabe-/Ausgabefehler.

Ich glaube, wir sind zum Kern des Problems vorgedrungen… Was ist jetzt zu tun?

[debianoli]

ABER:

Code: Alles auswählen

# grub-install 
x86_64-efi wird für Ihre Plattform installiert.
Could not prepare Boot variable: No space left on device
grub-install: Fehler: efibootmgr failed to register the boot entry: Eingabe-/Ausgabefehler.

Ich glaube, wir sind zum Kern des Problems vorgedrungen… Was ist jetzt zu tun?

Steht eigentlich in der Meldung: Die Partition für den efi-Booteintrag ist voll. Wie sieht denn die Partitionierung der SSD aus? Bzw was steht denn alles in der efi-Boot-Partition und wie groß ist die? Evtl. musst du da nur einen alten Eintrag löschen und schon geht es wieder. Oder Die partition vergrößern.

[mitscherdinger]

Steht eigentlich in der Meldung

Schon klar! Allerdings:

Code: Alles auswählen

# df -h
Dateisystem                      Größe Benutzt Verf. Verw% Eingehängt auf
udev                              3,4G       0  3,4G    0% /dev
tmpfs                             690M     18M  672M    3% /run
/dev/sda2                         440G    431G  7,7G   99% /
tmpfs                             3,4G       0  3,4G    0% /dev/shm
tmpfs                             5,0M    4,0K  5,0M    1% /run/lock
tmpfs                             3,4G       0  3,4G    0% /sys/fs/cgroup
/dev/sda2                         440G    431G  7,7G   99% /home
/dev/sda1                         511M    320K  511M    1% /boot/efi
192.168.0.6:/home/jarosch/medien  2,8T    1,2T  1,6T   43% /mnt/medien
tmpfs                             690M     28K  690M    1% /run/user/1000
/dev/sdb1                         146G     61G   79G   44% /media/kodi/0823f341-91bf-4403-828d-99caf1c7b4041

Also, wenn's dabei um /dev/sda1 gehen sollte, dann ist die eigentlich noch gar nicht voll (im Gegensatz zu meiner Root-, bzw. Home-Partition (BTRFS)).
Was anderes gibt's gar nicht auf /dev/sda - bis auf 8 GB swap...
Grub wird meines Wissens aber eh in den MBR geschrieben, oder bin ich da jetzt in 'ner ganz falschen Kategorie gelandet?

Da ist aber was noch komisch, wenn ich mir mal so durchlese, was ich bisher gemacht habe…

Code: Alles auswählen

# gdisk -l /dev/sda 
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 937703088 sectors, 447.1 GiB
Model: TOSHIBA Q300.   
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 1268AB4C-918F-4E47-9305-2A5A27DD8839
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 2048, last usable sector is 937703054
Partitions will be aligned on 2048-sector boundaries
Total free space is 0 sectors (0 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  
   2         1050624       922703871   439.5 GiB   8300  
   3       922703872       937703054   7.2 GiB     8200  

Total free space is 0 sectors (0bytes)? Da könnte das Problem liegen. Aber: Warum meint df, dass da noch Platz ist? Oder meinen die beiden was Unterschiedliches?

[debianoli]

Grub wird meines Wissens aber eh in den MBR geschrieben, oder bin ich da jetzt in 'ner ganz falschen Kategorie gelandet?

Ja. Völlig falsch. Wir reden hier von efi und nicht von bios. Efi nutzt eine eigene /boot-Partition und die muss FAT32 sein. Der MBR interessiert efi nicht wirklich.

[BenutzerGa4gooPh]

Code: Alles auswählen

# df -h
Dateisystem                      Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda2                         440G    431G  7,7G   99% /home

läuft voll!

Grub wird mit UEFI nicht mit

Code: Alles auswählen

grub-install /dev/sdX

installiert! Siehe 1. Beitrag von mir.
Debian mit Supergrub2 und UEFI-Eintrag für Debian starten @smutbert wies darauf bereits hin. Supergrub2 sollte man wohl auch besser per UEFI starten.

[habakug]

Hallo,

vor allem das

Code: Alles auswählen

# df -h
Dateisystem                      Größe Benutzt Verf. Verw% Eingehängt auf
[...]
/dev/sda2                         440G    431G  7,7G   99% /
[...]
/dev/sda2                         440G    431G  7,7G   99% /home
8...9

ist ein gewagtes Konstrukt.

Gruss, habakug

[NAB]

Ursache der Fehlermeldung ist doch wohl das hier:

Code: Alles auswählen

efibootmgr failed to register the boot entry: Eingabe-/Ausgabefehler.

Und efibootmgr schreibt nicht auf die Platte sondern ins NVRAM.

Anders ausgedrückt: Das UEFI ist der Meinung, das NVRAM ist voll ... oder gibt eine Fehlermeldung zurück, die Linux so interpretiert.

Was sagt denn nun

Code: Alles auswählen

efibootmgr -v

[mitscherdinger]

[…]ist ein gewagtes Konstrukt.

btrfs macht's möglich! Is doch kein Problem… Nur n bisschen voll. Muss halt mal wieder was löschen.

Was sagt denn nun

Code: Alles auswählen

efibootmgr -v

Na, dasselbe wie vor 3 1/2 Stunden…

Code: Alles auswählen

# efibootmgr -v
BootCurrent: 0003
Timeout: 2 seconds
BootOrder: 0003,0001,0002
Boot0001* CD/DVD Drive 	BBS(CDROM,,0x0)..GO..NO........m.H.L.-.D.T.-.S.T.D.V.D.-.R.O.M. .D.H.1.0.N....................A.........................>..Gd-.;.A..MQ..L. . . . . . . . . . . . . . . . . . . . ........BO
Boot0002* Hard Drive 	BBS(HD,,0x0)..GO..NO........m.T.O.S.H.I.B.A. .Q.3.0.0......................A.........................>..Gd-.;.A..MQ..L.6.5.B.K.5.5.W.H.1.K.U.P. . . . . . . . ........BO..NO........[.G.e.n.e.r.i.c. .6.0.0.0....................A..........................Gd-.;.A..MQ..L.G.e.n.e.r.i.c. .6.0.0.0........BO..NO........u.A.s.m.e.d.i.a. .1.0.5.3.-.3.G. .E.x.t... .H.D.D.0....................A.......................H..Gd-.;.A..MQ..L.A.s.m.e.d.i.a. .1.0.5.3.-.3.G. .E.x.t... .H.D.D.0........BO
Boot0003* UEFI OS	HD(1,GPT,77768245-4cf4-425d-a376-a32ae5fd5ccb,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)..BO

Der 2. Eintrag sieht etwas vollgeschissen aus… Ist das das Problem?

[NAB]

Sorry, ich hab noch über deinen doppel-mount und habakugs Einwand gegrübelt, da habe ich es übersehen.

Der 2. Eintrag sieht etwas vollgeschissen aus… Ist das das Problem?

Schwer zu sagen, aber selbst wenn - du könntet es nicht ändern. Das sind alles automatisch erzeugte Einträge ... das UEFI klappert deine angeschlossenen Geräte ab und sucht nach bootbaren Partitionen und erzeugt daraus selbstständig diese Einträge. "Toshiba" ist vermutlich deine Ubuntu-Platte.

Auffällig ist bisher:
1) Es gibt keinen Eintrag "debian" (der müsste auf efi/debian/grubx64.efi verweisen). Hat der jemals existiert? Wenn ja, wer hat den gelöscht? Wenn nein, müsste der Rechner schon immer über efi/boot/bootx64.efi gebootet haben - wer hat dann diese Datei gelöscht?
2) Wieso mag efibootmgr nicht (mehr?) ins NVRAM schreiben? Ging das jemals?

Meine grobe Theorie wäre: es gab eine Änderung an der Handhabung der Efi-Variablen im Kernel, mit der dein Mainboard nicht klarkommt. Beim Versuch, ins NVRAM zu schreiben, wird der vorhandene Eintrag gelöscht und kein neuer erzeugt. Wie gesagt - nur eine Theorie.

[habakug]

Hallo,

Der 2. Eintrag sieht etwas vollgeschissen aus… Ist das das Problem?

Der 2. Eintrag ist eine Toshiba Q300 Festplatte die in einem Asmedia USB-Dock steckt [1].

Gruss, habakug

[1] https://www.amazon.com/ASMedia-Support- ... B00CBE17JG

[mitscherdinger]

Nein, die Toshiba Q300 ist die SSD, auf der Debian läuft. Asmedia ist - richtig erkannt - der USB3-SATA-Adapter. Da dran hängt aber 'ne alte Fujitsu (mit Ubuntu) - die wird nie erwähnt, die hängt ja hinter dem Asmedia.

[mitscherdinger]

Auffällig ist bisher:
1) Es gibt keinen Eintrag "debian" (der müsste auf efi/debian/grubx64.efi verweisen). Hat der jemals existiert? Wenn ja, wer hat den gelöscht? Wenn nein, müsste der Rechner schon immer über efi/boot/bootx64.efi gebootet haben - wer hat dann diese Datei gelöscht?

Also, so einen Eintrag, wie "UEFI-OS" sehe ich zum ersten mal… An einen Eintrag namens "Debian" kann ich mich aber erinnern. Das war, glaube ich, als ich Debian auf dem Board installiert habe. Kann mich aber auch täuschen... Ich habe soweit es irgendwie ging, immer auf EFI oder UEFI verzichtet… Und auf Secure-Boot erst recht - das hätte mit ebian mangels signiertem Kernel sowieso nicht hingehauen…

Meine grobe Theorie wäre: es gab eine Änderung an der Handhabung der Efi-Variablen im Kernel, mit der dein Mainboard nicht klarkommt. Beim Versuch, ins NVRAM zu schreiben, wird der vorhandene Eintrag gelöscht und kein neuer erzeugt. Wie gesagt - nur eine Theorie.

Sprich: Alten Kernel installieren und schaun, ob's dann wieder funktioniert. Und wenn ja: Bugreport auf kernel.org…

[habakug]

Hallo,

du könntest mit einem

Code: Alles auswählen

# ls -lisa /dev/disk/by-uuid/

schlauer werden.

Gruss, habakug

[mitscherdinger]

Code: Alles auswählen

# ls -lisa /dev/disk/by-uuid/
insgesamt 0
10448 0 drwxr-xr-x 2 root root 120 Mär 31 12:23 .
10421 0 drwxr-xr-x 6 root root 120 Mär 31 12:23 ..
10466 0 lrwxrwxrwx 1 root root  10 Mär 31 14:27 063937ba-ed74-42cb-9dc4-3136348af6ea -> ../../sda3
11414 0 lrwxrwxrwx 1 root root  10 Mär 31 12:23 0823f341-91bf-4403-828d-99caf1c7b404 -> ../../sdb1
10483 0 lrwxrwxrwx 1 root root  10 Mär 31 14:27 30B9-4DD2 -> ../../sda1
10449 0 lrwxrwxrwx 1 root root  10 Mär 31 14:27 7b7891fc-c706-41b5-9db7-65e7c223ed0d -> ../../sda2

Der Erkenntnisgewinn hält sich in Grenzen.

[NAB]

Nein, die Toshiba Q300 ist die SSD, auf der Debian läuft. Asmedia ist - richtig erkannt - der USB3-SATA-Adapter. Da dran hängt aber 'ne alte Fujitsu (mit Ubuntu) - die wird nie erwähnt, die hängt ja hinter dem Asmedia.

Dass in Eintrag 0002 was von "Toshiba" und "ASMEDIA" steht, siehste ja selber. Erklären kann das nur dein Mainboard.

Ich werde aus der Beschreibung des ASMedia1053 nicht so recht schlau. Der scheint neben USB3 auch Sata-Anschlüsse bereitzustellen. Und dein Board hält die Toshiba für "extern".

Hängt die Toshiba vielleicht an einem internen ASMedia Sata-Anschluss? Hast du sie kürzlich dahin umgestöpselt?

(habakug, Linux verwendet die "UUID", UEFI hingegen die "PARTUUID")