mini-installer scheitert an GRUB-Installation

[kreuzschnabel]

Tach, ich wollte gerade auf einem Notebook ein Debian Stable mit dem Minimalinstaller unter https://d-i.debian.org/daily-images/amd ... t/mini.iso vom USB-Stick installieren. Die mini.iso habe ich um 11:38 Uhr heute aktuell heruntergeladen.

Die SSD wurde mit GPT angelegt und händisch partitioniert, mit einer 100 MB großen EFI-System-Partition am Anfang. Beim Partitionieren ist mir aufgefallen, dass der USB-Stick als /dev/sda und die SSD (das Installationsziel) als /dev/sdb eingebunden wurde.

Lief auch tadellos durch bis zur GRUB-Installation am Schluss, die wurde beendet mit der Fehlermeldung, der Befehl grub install dummy sei fehlgeschlagen. Und ich so: Hä, wieso Dummy, wohin versuchst du denn den GRUB zu packen?

Kann es sda vs. sdb zusammenhängen? Hat er also versucht, den GRUB für die Installation auf den Stick zu schreiben? Der hat natürlich auch seine eigene ESP, ist ja bootfähig.

Ein anschließender Versuch mit der netinst.iso lief tadellos durch. Und jetzt war die SSD auch /dev/sda.

--ks

[michaa7]

Das Problem hast du ja wohl durch den netinst.iso workaround umgangen. Der Hinweis an andere ist durch dein Posting auch erledigt.

Fehlt eigentlich nur noch der Bugreport gegen den mini-installer.

[kreuzschnabel]

Ich neige dazu, den Fehler immer zuerst bei mir selbst zu suchen

--ks

[hikaru]

Ich habe mir den Mini-Installer lange nicht mehr angeschaut, aber das ist doch im Wesentlichen ein abgespeckter Netinstaller, oder?
Der Netinstaller wiederum ist im Wesentlichen ein Wrapper um debootstrap. Ich würde also vermuten, dass sich beide im Prinzip gleich verhalten.

Sowas wie eine Verwechselung von sda und sdb sollte also wenn, dann in beiden auftreten können. Allerdings ist der Umstand, dass man sich auf die Reihenfolge dieser Bezeichner nicht verlassen kann, so ein alter Hut, dass der Installer prinzipiell nicht damit arbeiten sollte.
Ein Bugreport gegen den Mini-Installer ist vermutlich trotzdem gerechtfertigt, allerdings würde ich vorher weitere Tests empfehlen, ob das Problem tatsächlich dort liegt, wo vermutet.

[kreuzschnabel]

Allerdings ist der Umstand, dass man sich auf die Reihenfolge dieser Bezeichner nicht verlassen kann, so ein alter Hut, dass der Installer prinzipiell nicht damit arbeiten sollte.

Natürlich. Das muss auch nicht der Grund gewesen sein, es ist mir halt dabei aufgefallen.

Ich stelle mir das Idealverhalten eher so vor, dass der Installer sich merkt, auf welchem Laufwerk die Rootpartition liegt, für GRUB die ESP von ebendiesem Laufwerk als Default nimmt und nur dann nachfragt, wenn er dort keine findet.

--ks

[thunder11]

Grad mal getestet (in VM)
Mit / ohne EFI ---> beides funktioniert
Einmal ist der Installer hängen geblieben. Zweiter Versuch hat dann funktioniert (Experten-Modus für EFI)

[uname]

So eine ähnliche Verwechslung ist mir vor Jahren damals noch ohne UEFI, SecureBoot und den ganzen anderen Schrott auch schon mal (fast) passiert.

Vielleicht hätte ich eine alternative Lösung. Vielleicht hat ja jemand Lust es auszuprobieren:

Man nimmt die GRML-Live (gerne grml-small siehe Download), "brennt" sie auf einen USB-Stick und bootet sie TORAM (kann man irgendwo beim Booten auswählen). Dann entfernt man den Stick und führt grml-debootstrap aus. Alternativ kann man jedes Debian-basiertes Live-System nehmen welches TORAM gebootet werden kann, bootet es TORAM und installiert grml-debootstrap. Eine Partition, die nicht existiert, kann man dann auch nicht überschreiben. Der Stick ist sicher vom PC getrennt.

Ein GRML-Live sollte man immer rumliegen haben. Somit ist es eigentlich gar kein zusätzlicher Aufwand.

[kreuzschnabel]

Ich hab auch schon oft von der mini-iso installiert, immer problemlos, immer im Expert-Modus (da kann man die Geschmacksrichtung wählen). So was ist mir zum ersten Mal passiert.

Da ich die mini.iso immer frisch runterlade (kann sonst Versionskonflikte mit den runterzuladenden Ressourcen geben, das wird dann aber ziemlich am Anfang schon gemeldet), kann es sein, dass die in den letzten 2 Tagen einen Bug bekommen hat.

Wovon hängt denn die Reihenfolge der Gerätedateien ab? Purer Zufall oder gibt es da Vorgaben wie „eingebaute Geräte zuerst“? Oder liegt’s an der Hardware?

Ich hatte den Installer mehrfach gestartet, immer war die interne SSD /dev/sdb.

--ks

[ralli]

Ich arbeite stets mit dem net-installer. Damit bekomme ich bisher auch problemlos eine Minimalinstallation hin, wenn gewünscht. Probleme tauchten bisher niemals auf.

Gruß ralli

[hikaru]

Wovon hängt denn die Reihenfolge der Gerätedateien ab?

Das hängt davon ab, welches Gerät sich zuerst beim Kernel meldet - eine klassische Race-Condition also, und daher ohne genaue Kenntnis der konkreten Hardware unvorhersagbar.

[ralli]

Wovon hängt denn die Reihenfolge der Gerätedateien ab?

Das hängt davon ab, welches Gerät sich zuerst beim Kernel meldet - eine klassische Race-Condition also, und daher ohne genaue Kenntnis der konkreten Hardware unvorhersagbar.

Das ist ja wirklich sehr intelligent. Dann ist der Installer ja verbesserungswürdig. Das Problem ist doch sicherlich bekannt, oder?

Ich meine mich zu Erinnern, das früher bei dem normalen Installer am Ende vor dem grub-install sozusagen die Device aufgelistet wurden, so das ich selbst auswählen konnte, wohin der Bootloader installiert wurde. Aber den habe ich schon lange nicht mehr benutzt.

Gruß ralli

[tobo]

Das ist ja wirklich sehr intelligent. Dann ist der Installer ja verbesserungswürdig. Das Problem ist doch sicherlich bekannt, oder?

Na klar, ist ja eine Kernel-Sache und damit unabhängig zum Installer. Wenn du mehrere Platten hast, dann mal - jeweils nach einem Boot - mittels `lsblk' schauen, ob die Partitionen zum Gerät passen.

[kreuzschnabel]

Das ist ja wirklich sehr intelligent. Dann ist der Installer ja verbesserungswürdig. Das Problem ist doch sicherlich bekannt, oder?

WENN das der Fehler ist. Ich habe unabhängig voneinander beobachtet, dass 1. die interne SSD als /dev/sdb im System war und 2. am Schluss ein "grub install dummy" scheiterte. Ob diese zwei Punkte kausal verbunden sind, weiß ich nicht. Wie das "dummy" da reinkommt, weiß ich auch nicht, sollte es nicht eher "grub install /dev/sdXy" oder so lauten?

Ich meine mich zu Erinnern, das früher bei dem normalen Installer am Ende vor dem grub-install sozusagen die Device aufgelistet wurden, so das ich selbst auswählen konnte, wohin der Bootloader installiert wurde. Aber den habe ich schon lange nicht mehr benutzt.

Bei MBR-Installationen ist das auch heute noch so. Bei EFI-Installationen wird nicht gefragt, weil klar ist, dass der Bootloader in die ESP kommt.

--ks

[rhHeini]

grub install dummy ist efi-Sprech, da wird eigentlich der Eintrag in der gemounteten ESP geschrieben. Wenn das schief geht ....

grub install /dev/sdXy gehört zum Legacy-Mode.

[kreuzschnabel]

grub install dummy ist efi-Sprech, da wird eigentlich der Eintrag in der gemounteten ESP geschrieben. Wenn das schief geht ....

Das erhärtet den Verdacht, dass er versucht hat, in die ESP des Sticks zu schreiben. Die hat nur 3,7 MB, da wird’s ernsthaft knapp

--ks

[michaa7]

Aber wenn Grub nur in das Installationsmedium schreiben kann und nicht in das Zielmedium, dann ist das ja wohl kein Feature, sondern ein Unfall mit Ansage, oder?

[kreuzschnabel]

Aber wenn Grub nur in das Installationsmedium schreiben kann und nicht in das Zielmedium, dann ist das ja wohl kein Feature, sondern ein Unfall mit Ansage, oder?

Ob das eine Frage von „kann“ ist, ist offen. Er hätte in meinem Fall ohne Weiteres ins Zielmedium schreiben können (jedenfalls von mir aus). Das System vorher hat er ja auch da hin geschrieben. Er hat sich dann offenbar nur die falsche ESP rausgesucht, nämlich die erste auffindbare und nicht diejenige auf dem Zielmedium.

Das alles nur gemutmaßt.

Für Gewissheit müsste man mal im Code nachgucken, was der Grub-Installer macht, wenn das Zielmedium nicht das alphabetisch erste Medium mit einer ESP ist. Wenn ihn das tatsächlich irritiert, dann müsste entweder dafür gesorgt werden, dass das Zielmedium das erste in der Liste ist (wird schwierig, siehe oben), oder es müsste dafür gesorgt werden, dass der Installer das richtige Medium auch woanders findet (wie von mir vorgeschlagen erstmal auf dem Medium nachgucken, auf dem die Rootpartition liegt, denn dort wird in 99,5 % aller Fälle auch gebootet).

Andererseits: Ich habe im Expert-Modus installiert, in dem jeder Furz vom Installer nachgefragt wird. Da könnte er ruhig auch fragen, in welche ESP er den Bootloader packen soll, wenn er mehr als eine findet.

--ks

[thunder11]

Also ich habe jetzt nochmal versucht, das Szenario in einer VM nachzuvollziehen.

Einziger "Makel": der USB-Stick ist nicht Efi-Verseucht, sondern ein "normales Boot-Medium

Ich vermute mal dass schon bei der Platten-Auswahl "geschlafen wurde"


An sich sollte man schon dort erkennen, was man zu wählen hat.
das weitere ergibt sich dann automatisch:

Die Installation ist dann weiterhin Fehlerfrei durchgelaufen.
Allerdings wird bei EFI nicht mehr nachgefragt, wohin Grub soll.

Edit
Hier noch die Massenspeicher der VM vor Installation

[kreuzschnabel]

Also ich habe jetzt nochmal versucht, das Szenario in einer VM nachzuvollziehen.

Einziger "Makel": der USB-Stick ist nicht Efi-Verseucht, sondern ein "normales Boot-Medium

Das ist kein Makel, sondern ein komplett anderes Szenario, denn – ich nehme an – genau dies (die ESP auf dem Stick) war die Ursache des Problems.

Ich vermute mal dass schon bei der Platten-Auswahl "geschlafen wurde"

Vorwurf an mich? Also bitte. Ich habe mit absoluter Sicherheit die eingebaute SSD mit 256 GB partitioniert, nicht den Stick mit 32 GB (während er lief), das wäre mir doch wirklich aufgefallen Geht das überhaupt, das Installationsmedium während der laufenden Installation zu partitionieren, ohne dass der Vorgang abbricht?

An sich sollte man schon dort erkennen, was man zu wählen hat.
das weitere ergibt sich dann automatisch:

Och bitte verkauf mich doch nicht für doof. Natürlich erkennt man das, und natürlich habe ich da den richtigen Eintrag gewählt und partitioniert.

Bei mir sieht das jetzt so aus, wenn ich auf derselben Hardware nochmal einen Trockenlauf starte (Englisch, ich hab den Anfang mit der Sprachauswahl übersprungen):



Das untere Laufwerk habe ich partitioniert und auf / und /home gemountet. Dorthin ist Debian auch installiert worden. Die ESP auf der SSD (also /dev/sdb1) habe ich mit „verwenden als → EFI-System-Partition“ angelegt, die wird dann automatisch auf /boot/efi gemountet. War jedenfalls bis jetzt immer so, und dann gibt es auch gar keine Auswahl eines Mountpunktes im Dialog. Beim zweiten Mal hab ich für die ESP des Sticks sogar ausdrücklich „nicht verwenden“ angewählt. Selber Fehler.

Allerdings wird bei EFI nicht mehr nachgefragt, wohin Grub soll.

Eben. Und das hat – Vermutung – dazu geführt, dass der Installer versucht hat, Grub in die ESP des Sticks zu packen, statt – wie das übrige System – auf die SSD.

--ks

[cosinus]

Ich neige dazu, den Fehler immer zuerst bei mir selbst zu suchen

Bist du da nicht etwas zu hart zu dir selbst?

[thunder11]

Also jetzt habe ich es nochmal gemacht mit folgenden USB Stick:
Hergestellt mit Rufus unter Windows VM:

Code: Alles auswählen

~# fdisk -l /dev/sdd
Disk /dev/sdd: 3,73 GiB, 4004511744 bytes, 7821312 sectors
Disk model: Cruzer Blade    
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: dos
Disk identifier: 0x7658a897

Device     Boot  Start    End Sectors  Size Id Type
/dev/sdd1  *         0 112639  112640   55M  0 Empty
/dev/sdd2          264   7491    7228  3,5M ef EFI (FAT-12/16/32)
/dev/sdd3       112640 124927   12288    6M  1 FAT12
root@XFCE:~# 

Das hat ebenso funktioniert. Wo ist der Haken /bzw. Unterschied ??

[KP97]

Und das hat – Vermutung – dazu geführt, dass der Installer versucht hat, Grub in die ESP des Sticks zu packen, statt – wie das übrige System – auf die SSD.

Doch @kreuzschnabel, Du vermutest richtig. Dann kann der Installer von Debian das noch immer nicht richtig, ganz im Gegensatz zu OpenSuse.

Ich habe ein Debian 12 auf einem USB-Stick, den ich als Rettungssystem auf FremdPC's und als Backupstick mit Partclone für meine eigenen Systeme nutze.
Das System hat mittlerweile schon zwei Updates erhalten, ist also schon etwas älter.
Erstellt habe ich den Stick mit einem Netinstall.iso, damals noch Buster, allerdings auch auf einem USB-Stick.
Ich installiere immer im Expertenmodus, die Partitionierung mache ich manuell. Die Installation verlief damals absolut reibungslos,
und auch der Stick funktionierte tadellos - auf meinem System.
Dass auf dem Stick gar keine EFI geschrieben wurde, weil ja die EFI der HDD gefunden wurde, ist mir erst aufgefallen, als ich den Stick in einem anderen PC verwenden wollte.
Klar, auf meinem Rechner war ja die EFI vorhanden, aber nicht auf dem fremden PC.
Ich habe dann hin und her getestet, nochmal neu installiert usw. kein Erfolg. Ich war es dann leid und habe die Iso auf eine CD gebrannt. Danach war es möglich, auch auf dem Stick eine EFI einzurichten, die bis heute problemlos funktioniert.
Tja, das muß heute nicht mehr passieren, ist ja schon ein paar Jährchen her, aber anscheinend zickt der Installer immer noch herum.
Später habe ich testweise auch mehrmals ein Suse Tumbleweed auf einen Stick installiert, überhaupt kein Problem mit der EFI, alles funktionierte auf Anhieb.
Was jetzt nicht heißen soll, daß alle Tumbleweed installieren sollen ;-) ... ich wollte es nur mal erwähnt haben...

@thunder
Ich weiß nicht, ob sich das in einer VBox 1:1 vergleichen läßt, da sind ja doch einige eigenen Abläufe von Virtualbox mit im Spiel. Ich nutze keine Virtualbox, kann mich also auch täuschen.
Ich verwende qemu, da wird in einer VM die Hardware des Hosts verwendet, während VBox da ja was emuliert.

[michaa7]

Also jetzt habe ich es nochmal gemacht mit folgenden USB Stick:
Hergestellt mit Rufus unter Windows VM:

Code: Alles auswählen

~# fdisk -l /dev/sdd
Disk /dev/sdd: 3,73 GiB, 4004511744 bytes, 7821312 sectors

...
Das hat ebenso funktioniert. Wo ist der Haken /bzw. Unterschied ??

Der Stick ist nicht sda

[ralli]

Da hier schon andere Installer angesprochen wurden, Anaconda (Fedora, Alma Linux, Rocky Linux) macht auch alles richtig. Jeder bilde sich seine eigene Meinung.

Gruß ralli

[thunder11]

Der Stick ist nicht sda

Doch war er. Das fdisk ist danach vom Host.

vielleicht hier der Fehler ?