[gelöst] Nach update stretch, Grub weg, Dualboot

[marmai]

Hallo,
Ausgangslage: Ein Dualboot mit win 10 und bisher installiertem jessie tat 2 Jahre seinen Dienst. Nach update auf stretch lief gar nichts mehr, es erschien kein Grub mehr, sondern win10 startet direkt los. Mittels Rettungsdisk "reFInd" konnte ich "win10" oder "stretch" starten, aber stretch wollte absolut keinen xserver hoch fahren, so dass ich (nach Stunden) beschloss neu zu installieren. Aber beim Installationsprozess wurde ein Fehler von grub gemeldet, habe mir den dummerweise nicht aufnotiert, aber sinngemäß, dass grub nicht auf Platte sda7 (diese Platte soll stretch enthalten) installiert werden könne. Insgesamt sind drei Platten im Einsatz, 500GB-SSD = sda, (win10 , deb 9, Daten), sowie eine alte 256SSD =sdb (nur Daten) und eine 4TB = sdc (nur Daten).

Mittels "reFInd" kann ich jetzt "win10" oder "boot EFI/debian/grubx64.efi" auswählen und stretch lässt sich starten. Aber nach wie vor kommt Grub erst, wenn ich mit "reFIind" grub64.efi anwähle. Ohne die Rettungsdisk legt nach wie vor win10 los.

Die Plattenbelegung mittels "lsblk" sieht so aus:

Code: Alles auswählen

sda       8:0    0 465,8G  0 disk 
├─sda1    8:1    0   300M  0 part 
├─sda2    8:2    0   100M  0 part /boot/efi
├─sda3    8:3    0   128M  0 part 
├─sda4    8:4    0 312,4G  0 part 
├─sda5    8:5    0   450M  0 part 
├─sda7    8:7    0  41,1G  0 part /
├─sda8    8:8    0   2,1G  0 part [SWAP]
└─sda9    8:9    0 107,3G  0 part /home
 

parted -l liefert:

Code: Alles auswählen

 Model: ATA Samsung SSD 850 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size    File system     Name  Flags
 1      1049kB  316MB  315MB   ntfs            Basi
 2      316MB   420MB  105MB   fat32           EFI   boot, esp
 3      420MB   555MB  134MB                   Micr  msftres
 4      555MB   336GB  335GB   ntfs                  msftdata
 5      336GB   336GB  472MB   ntfs                  hidden, diag
 7      336GB   381GB  44,2GB  ext4                  msftdata
 8      381GB   383GB  2278MB  linux-swap(v1)
 9      383GB   498GB  115GB   ext4                  msftdata

"efibootmgr -v" liefert:

Code: Alles auswählen

 BootCurrent: 000A
Timeout: 2 seconds
BootOrder: 0001,000A,0002,0009,000B,0005,0006
Boot0001* Windows Boot Manager	HD(2,GPT,6fd6a3fc-87b4-409b-ba23-42af38aa2153,0x96800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...s................
Boot0002* Samsung SSD 850 EVO 500GB	BBS(HD,,0x0)AMBO
Boot0005* TSSTcorp CDDVDW SH-216BB	BBS(CDROM,,0x0)AMBO
Boot0006* IBA GE Slot 00C8 v1398	BBS(Network,,0x0)AMBO
Boot0009* WDC WD40EZRZ-00WN9B0	BBS(HD,,0x0)AMBO
Boot000A* UEFI: TSSTcorp CDDVDW SH-216BB	PciRoot(0x0)/Pci(0x1f,0x2)/Sata(5,65535,0)/CDROM(0,0x5d,0x3000)AMBO
Boot000B* Samsung SSD 840 PRO Series	BBS(HD,,0x0)AMBO
Boot000C* Samsung SSD 850 EVO 500GB	BBS(HD,,0x0)AMBO
Boot000D* Samsung SSD 840 PRO Series	BBS(HD,,0x0)AMBO

Irgendwie schein aus dem efi das bootfähige deb9 verschwunden zu sein, oder noch nie angelegt. Motherboad ist ein Fujitsu, Secureboot ist ausgeschaltet, Motherboard unterstützt uefi.
Habe mich durch die diversen Problemhilfen (Ubuntu, debianforum) durchgearbeitet, komme aber nicht weiter.

Kann jemand helfen?

Danke im Voraus.

[BenutzerGa4gooPh]

Mache erst mal nach Fremd-Start von Debian mit Rettungsdisk nur

Code: Alles auswählen

update-grub

Wenn System nicht selber startet

Code: Alles auswählen

grub-install
update-grub

Wenn immer noch nicht:

Code: Alles auswählen

apt-get --reinstall install grub-common grub-efi-amd64 os-prober
update-grub

Notfalls mal probieren:

Code: Alles auswählen

grub-install /dev/sda
update-grub

(Mein UEFI-Laptop will das komischerweise.)

Danach mit

Code: Alles auswählen

efibootmgr -o ... 

Reihenfolge neu festlegen.

Eventuelle Fehlerausgaben posten!

[marmai]

Also:
Schritt 1 Deiner Lösung führte zu:

Code: Alles auswählen

root@deb9:/home/mm# update-grub
GRUB-Konfigurationsdatei wird erstellt …
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Linux-Abbild gefunden: /boot/vmlinuz-4.9.0-3-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.9.0-3-amd64
Windows Boot Manager auf /dev/sda2@/EFI/Microsoft/Boot/bootmgfw.efi gefunden
Adding boot menu entry for EFI firmware configuration
erledigt

Denke, dass ist soweit in Ordnung.

Schritt 2:

Code: Alles auswählen

root@deb9:/home/mm# 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.

erzeugt eine Fehlermeldung, jetzt erinnere ich mich wieder, dass dies die gleiche Fehlermeldung ist, die ich bei der Installation von stretch erhielt.
Ich kann diese allerdings nicht interpretieren. Wieso kein Platz mehr auf der Platte, oder wo will Grub denn hininstallieren?
Partition /dev/sda2 /boot/efi hat insgesamt 100MB, unbenutzt sind ca.60MB laut gparted. Also Platz ist da doch genügend, oder?

Schritt 3:
(habe ich gerade aus einem Bugreport abgelesen):
https://bugs.debian.org/cgi-bin/bugrepo ... bug=845023

Code: Alles auswählen

root@deb9:/home/mm# grub-install -v
-----
-----
grub-install: Info: copying `/boot/grub/x86_64-efi/core.efi' -> `/boot/efi/EFI/debian/grubx64.efi'.
grub-install: Info: Registering with EFI: distributor = `debian', path = `\EFI\debian\grubx64.efi', ESP at hostdisk//dev/sda,gpt2.
grub-install: Info: executing efibootmgr --version </dev/null >/dev/null.
grub-install: Info: executing modprobe -q efivars.
grub-install: Info: executing efibootmgr -c -d /dev/sda -p 2 -w -L debian -l \EFI\debian\grubx64.efi.
Could not prepare Boot variable: No space left on device
grub-install: Fehler: efibootmgr failed to register the boot entry: Eingabe-/Ausgabefehler. 

liefert wohl, dass der Fehler beim Beschreiben des EFI auftritt? Aber der Lösungsversuch mit Firmwareupdate geht bei mir nicht, da über win10 und entsprechendem Tool
von Fujitsu schon lange keine Firmwareupdate nötig wurde (überprüfe ich regelmäßig). Außerdem habe eben ein BIOS-update mittels Fujitsu-Tool gemacht bringt keine Änderung.
Wie interpretierst Du den ganz unten im Bugreport stehenden Lösungsvorschlag? Einfach nur Ordner und Datel mit Großbuchstaben versehen? Habe ich auch gemacht, bringt nichts.

Ratlos!

[whisper]

Hast du im BIOS eine Schweibschutzoption für die Platte?
Oder mit hdparm früher mal selber eingeschaltet?

[owl102]

liefert wohl, dass der Fehler beim Beschreiben des EFI auftritt?

Ja. Genauer bei

Code: Alles auswählen

efibootmgr -c -d /dev/sda -p 2 -w -L debian -l '\EFI\debian\grubx64.efi'

Aber der Lösungsversuch mit Firmwareupdate geht bei mir nicht, da über win10 und entsprechendem Tool
von Fujitsu schon lange keine Firmwareupdate nötig wurde (überprüfe ich regelmäßig). Außerdem habe eben ein BIOS-update mittels Fujitsu-Tool gemacht bringt keine Änderung.

Dann wird man sich wohll an den Support von Fujitsu wenden müssen.

Die einzige Idee, die ich noch hätte: Bietet das Fujitsu-BIOS einen Menüpunkt, um selber EFI-Booteinträge anzulegen? (Dell zum Beispiel hat sowas.) Wenn ja, dann kannst du auch darüber den Boot-Eintrag anlegen.

Wie interpretierst Du den ganz unten im Bugreport stehenden Lösungsvorschlag? Einfach nur Ordner und Datel mit Großbuchstaben versehen?

Da der Bug im UEFI BIOS zu stecken scheint, ist es immer schwer zu sagen, wie und ob man den Bug umgehen kann. Ob beim Anwender die Großbuchstaben geholfen haben, oder aber der andere Pfad "/EFI/BOOT/BOOTX64.EFI" statt "/EFI/debian/grubx64.efi", oder die geänderte Länge des Pfades oder der geänderte Mondstand, oder ob die Subrauminterferenzen vorher zu stark waren, wer weiß das schon.

Tatsache ist leider, daß viele UEFI BIOS im Feld alles andere als ausgereift sind, und für einige Hersteller gilt wohl "Wir konnten 1x Windows 10 installieren" bereits als völlig ausreichende Qualitätskontrolle.

Ausprobieren kann man das auf jeden Fall trotzdem mal, d.h. auf der EFI-Partition "/EFI/debian/grubx64.efi" nach "/EFI/BOOT/BOOTX64.EFI" kopieren und anschließend (als root)"

Code: Alles auswählen

efibootmgr -c -d /dev/sda -p 2 -w -L debian -l '\EFI\BOOT\BOOTX64.EFI'

versuchen. Wenn es dabei keine Fehlermeldung gibt, ist das schon 'mal sehr gut. Anschließend kannst du mit

Code: Alles auswählen

efibootmgr

überprüfen, ob er die neue EFI-Bootvariable wirklich korrekt gefressen hat oder nicht.

Wenn du auf das "debian" keinen Wert legst, könnte man auch hier mal variieren, z.B. nach "LINUX". (Dies ist lediglich der Prosa-Name, den dein UEFI BIOS im Bootmenü anzeigt).

[BenutzerGa4gooPh]

Zuletzt Notlösung: Im BIOS CSM/Legacy einstellen und in diesem Modus installieren. Nicht schick. Dran denken: Max. 4 primäre Partitionen oder eben erweiterte. Und W10 müsste wohl neu installiert werden. Oder im BIOS geht beides einzustellen?

[owl102]

Und W10 müsste wohl neu installiert werden. Oder im BIOS geht beides einzustellen?

Windows 10 im EFI-Modus und Linux im CSM-Modus ist unhübsch. Alle UEFI-BIOS, die ich kenne, bevorzugen AFAIR immer UEFI-Boot, d.h. es würde immer Windows 10 als default gebootet werden. Und selbst wenn man es tatsächlich doch ändern könnte, müsste man trotzdem immer mit dem UEFI-Bootmenü arbeiten, denn aus dem Grub vom Linux heraus könnte man so nicht Windows 10 booten.

Wenn, dann also am besten beides im CSM/Legacy-Modus. Ich meine mich daran erinnern zu können, daß in der C'T mal eine Anleitung stand, wie man bei Windows 10 UEFI/GPT zu Windows 10 CSM/MBR umwandelt. Oder andersherum. Ich weiß es nicht mehr. Blöde ist auf jeden Fall, daß ohne technisch notwendigen Grund bei Windows UEFI nur mit GPT geht und CSM nur mit MBR-Partitionstabelle, d.h. neben Windows 10 selber muß auch die Partitionstabelle umgebaut werden.

[BenutzerGa4gooPh]

Alle UEFI-BIOS, die ich kenne, bevorzugen AFAIR immer UEFI-Boot, d.h. es würde immer Windows 10 als default gebootet werden.

Bei meinem Lenovo-Lappi kann ich "UEFI first" de- u. aktivieren.

Und selbst wenn man es tatsächlich doch ändern könnte, müsste man trotzdem immer mit dem UEFI-Bootmenü arbeiten, denn aus dem Grub vom Linux heraus könnte man so nicht Windows 10 booten.

Ist ja wirklich

unhübsch.

Wie W10 neu installieren und updaten. (Deshalb hatte ich auf den "Mix" vage hingewiesen.) Vielleicht enthalten aktuell heruntergeladene W10-ISOs auch schon viele Updates? Wäre nicht zuviel verlangt.

[marmai]

Jetzt knallen aber gleich die Sektkorken, ich bin erleichtert kann ich euch sagen......
Einen Dank an alle hier, die mitgeholfen haben.
Lösung gefunden:

Der Reihe nach.
In dem Post erbat ich einen Tipp:
viewtopic.php?f=12&t=165565
mikelm hat sich ein wenig Zeit gelassen, sonst hätte ich den Thread nicht aufgemacht. Er hat den richtigen Hinweis geliefert, deshalb poste ich hier, was er recherchiert hat, bei ihm geholfen hat und was ich auch gemacht habe.

So wie er schreibt, wird das Problem auf:
https://forums.gentoo.org/viewtopic-p-8011234.html
beschrieben und gelöst.

Ich habe also entsprechend dem Gentoo-Thread, welcher auf den archlinux-Artikel verweist:
https://wiki.archlinux.org/index.php/Un ... _Interface
folgendes beherzigt und durchgeführt:

Code: Alles auswählen

 If any userspace tool is unable to modify efi variables data, check for existence of /sys/firmware/efi/efivars/dump-* files. If they exist, delete them, reboot and retry again.

also alle dumpdateien gelöscht und neu gestartet, dann nochmals den

Code: Alles auswählen

grub-install

ausgeführt und siehe da, ohne Fehler. Maschine läuft nun wieder wie es sein soll und bringt beim Anwerfen Grub mit der Auswahl deb9 und win10.

[owl102]

welcher auf den archlinux-Artikel verweist:
https://wiki.archlinux.org/index.php/Un ... _Interface

Danke für den Link, habe die Seite heute früh durchgelesen und wieder was dazugelernt.

Code: Alles auswählen

 If any userspace tool is unable to modify efi variables data, check for existence of /sys/firmware/efi/efivars/dump-* files. If they exist, delete them, reboot and retry again.

Was leider nicht in dem Wiki steht: Wer legt wann diese dump-Dateien im NVRAM des UEFI BIOS an? Das UEFI BIOS selber? Wenn ja, wann und wieso?

Maschine läuft nun wieder wie es sein soll und bringt beim Anwerfen Grub mit der Auswahl deb9 und win10.

Schön!