System lässt sich nicht mehr booten - Eventuell Problem mit grub

[Cordess]

Hallo,

ich kann seit heute mein Debian 10 System nicht mehr booten, das grub bootloader Menü erscheint nicht . Gestern ging es noch.
Am System habe ich nichts verändert, zumindest nicht bewusst.
Das Debian 10 System befindet sich auf einer SSD mit ein paar mit LUKS verschlüsselten Partitionen, genaugenommen eine für /, /var und /home, lediglich die boot Partition ist unverschlüsselt.
Auf der anderen SSD, die als erstest gebootet wird, befindet sich der grub bootloader und ein Windows 10 System.


Ich schreibe das hier unter einem Kubuntu Live System welches sich auf meinem USB Stick befindet. Die SSDs auf dem das Debian 10 System drauf ist, sind von dort noch ansprechbar. Ein Hardwaredefekt kann also ausgeschlossen werden.

Die einzige Vermutung die ich habe, warum das heute nicht mehr gehen könnte, könnte die Installation von grub auf meinem USB Multiboot Stick liegen, den ich gerade verwende und auf dem auch mein Kubuntu Live System drauf ist.
Den USB Stick, auf dem sich mehrere Installations ISO Dateien für verschiedene Distris befinden, habe ich nämlich gestern für einen anderen Rechner verändern müssen. Auf diesem muss ich dann immer den grub bootloader updaten, eventuell ist da etwas schief gelaufen, obwohl das eigentlich nicht sein dürfte, denn ich habe das früher immer mit dem gleichen Befehl gemacht und da gab es nie Probleme, das war allerdings noch unter Kubuntu 16.04 LTS.
Das Debian 10 System ist recht neu installiert..

Als Befehl habe ich folgenden Befehl als root ausgeführt:

Code: Alles auswählen

grub-install --root-directory=/media/nutzername/multi_os/ /dev/sdd

Der USB Stick war zu diesem Zeitpunkt eingebunden.
/dev/sdd entspricht hierbei dem Devicenamen für den USB Stick.
Und /meda/nutzername/multi_os/ ist der gemountete USB-Stick.
In dessen root Verzeichnis befindet sich ein boot/grub/ Verzeichnis und eine entsprechende grub.cfg.

Der grub Bootloader für das eigentliche installierte System, also ohne USB Stick, müsste sich auf /dev/sda befinden.
Den habe ich aber gestern gar nicht verändert und das hätte heute noch alles problemlos funktionieren müssen,
aber vielleicht gibt's da einen Bug bei der grub2 Versioni von dem Debian 10 System, so dass obiger Befehl den Grub Bootloader auf der SSD zerschossen hat? Das wäre zumindest eine Vermutung und Erklärung, denn anders kann ich mir das nicht erklären.

Ansonsten kann ich noch sagen, dass ich für das Debian 10 System UEFI und eine gpt Partition verwende.
Für den USB Stick verwende ich eine legacy Partition.
Eventuell gab es hier Schwierigkeiten.


Jetzt möchte ich das System auf der SSD wieder booten können.
Die grub.cfg befindet sich in der boot Partition, die ich mounten kann.

Irgendwelche Vorschläge, wie ich das am elegantesten lösen kann?

[smutbert]

Sicher, dass du den geposteten Befehl so eingegeben hast – eine Option --root-directory von grub-install kenne ich nicht (und die manpage ebensowenig). Zum Installieren von grub für „fremde“ Systeme schreibe ich später noch etwas, wenn du willst, aber als erstes dürfte wohl der grub deines Debian 10 interessant sein.

Zuallererst muss ich an den Bug von grub-pc denken, der im Forum gerade erst vorgekommen ist (966575, viewtopic.php?f=12&t=178222). Siehst du eine Fehlermeldung: „error: symbol 'grub_calloc' not found.“?

Außerdem würde ich vermuten, dass du mit dem Befehl, zwar den Teil in /boot/grub deines Debian 10 upgedatet hast, aber wegen der Angabe von sdd als Ziel nicht den MBR der SSD. Je nach Änderungen in Grub kann so ein unvollständiges grub-Update das Booten komplett vereiteln. Eigentlich müsstest du dann mit dem Stick dein Debian 10 booten können oder zumindest zur oben erwähnten Fehlermeldung kommen.

[MSfree]

Zuallererst muss ich an den Bug von grub-pc denken, der im Forum gerade erst vorgekommen ist (966575, viewtopic.php?f=12&t=178222).

Du meinst diesen Thread:
viewtopic.php?f=12&t=178215

Dein Link zeigt darauf, wie man das grub-Update verhindert. Das hilft aber nur, wenn das Kind noch nicht in den Brunnen gefallen ist.

[Cordess]

Sicher, dass du den geposteten Befehl so eingegeben hast – eine Option --root-directory von grub-install kenne ich nicht (und die manpage ebensowenig).

Da bin ich mir ganz sicher, da ich mir damals für meinen Multi USB Stick, als ich den das erste mal vor > 6 Jahren erstellt habe, eine Textdatei auf diesem angelegt habe, in dem ich kurz beschrieben habe, wie ich bei neuen Distroversionen den USB Stick aktualisiere, damit ich da nicht jedesmal aufs neue mich einlesen muss.
Und da hat der Befehl früher unter Ubuntu 16.04 LTS und davor immer funktioniert.

Die Option ist auch notwendig, da ja ansonsten grub gar nicht wissen würde, welche Menüeinträge es für den USB Stick erstellen soll.
Es würde dann die grub.cfg aus der Systeminstallation auswählen und die würde ja nicht passen.
Gestern hat es allerdings die richtigen Menüeinträge erstellt, die Option scheint also noch irgendwie im grub Code enthalten und ausgewertet zu werden.

Falls es die Option nun nicht mehr offiziell geben sollte, dann könnte es sich um eine legacy bzw. obsolete gewordene Option handeln, die früher mal funktionierte und nun nicht richtig aus dem grub Code entfernt wurde und auch bei neuen grub Versionen nun nicht mehr unterstützt wird. Das würde auch das Problem erklären, das ich jetzt habe und warum die Option in der manpage fehlt.

Zum Installieren von grub für „fremde“ Systeme schreibe ich später noch etwas, wenn du willst, aber als erstes dürfte wohl der grub deines Debian 10 interessant sein.

Der schnellste Weg, der zum erhofften Ziel führt, würde mir genügen. Hauptsache ich kann mein System wieder booten.

Zuallererst muss ich an den Bug von grub-pc denken, der im Forum gerade erst vorgekommen ist (966575, viewtopic.php?f=12&t=178222). Siehst du eine Fehlermeldung: „error: symbol 'grub_calloc' not found.“?

Nein, eine Fehlermeldung erhalte ich gar nicht.
Ich sehe nach dem Booten nur einen schwarzen Bildschirm und den Cursor als Unterstrich kurz oben links aufblinken und dann erscheint er ca. 4 Zeilen weiter unten und ein paar Leerzeichen weiter vorne. Ein Text steht aber nicht dabei, ich kann auch in keine grub Konsole.

Außerdem würde ich vermuten, dass du mit dem Befehl, zwar den Teil in /boot/grub deines Debian 10 upgedatet hast, aber wegen der Angabe von sdd als Ziel nicht den MBR der SSD. Je nach Änderungen in Grub kann so ein unvollständiges grub-Update das Booten komplett vereiteln. Eigentlich müsstest du dann mit dem Stick dein Debian 10 booten können oder zumindest zur oben erwähnten Fehlermeldung kommen.

Das kann ich leider nicht, da ich für den Stick ja andere Grub Menüeinträge habe und die aus der /media/nutzername/multi_os/boot/grub/grub.cfg ausgewertet werden.
Beim USB Stick funktioniert auch alles wie gewünscht, nur der grub Bootloader meines Systems geht nicht mehr richtig.
Wenn die -root-directory= Option so ne Legacy Option ist, die nun nicht mehr richtig unterstützt wird, aber im Code noch irgendwie halber da ist und schlecht getestet ist, dann wäre es aber eine Erklärung, warum jetzt nichts mehr richtig funktioniert. Im Grunde hätte der grub bootloader auf meiner SSD ja nie überschrieben werden dürfen und ich habe gründlich darauf geachtet, dass ich als Devicename auch /dev/sdd und nicht meine Systemplatte angebe.
Ich habe sogar extra vorher noch einmal nachgeschaut, ob es auch der richtige Devicename ist. Den Fehler kann ich also auch ausschließen.


Was die grub.cfg auf der /boot Patition, also in /boot/grub/ anbelangt, so scheint diese noch unverändert zu sein.
Diese wurde das letzte mal am 1. August aktualisiert, als ein Kernelupdate kam. Aber das war vor 5 Tagen und Gestern konnte ich mein System ja noch booten.

Siehe auch dazu folgende Ausgabe, der eingebundenen boot Systempartition meines Debian 10 Systems.

Code: Alles auswählen

ls -l --full-time /media/kubuntu/boot/grub/grub.cfg 
-r--r--r-- 1 root root 8711 2020-08-01 21:09:44.000000000 +0000 /media/kubuntu/boot/grub/grub.cfg

Das einzige was mir noch einfällt ist, dass ich beim Ausführen des obigen grub-install Befehl Gestern
ein String der irgendwie x86????efi oder x86????gpt oder so ähnlich hieß, als Ausgabe bekam, das kam mir etwas komisch vor.
Mein USB Stick hat nämlich noch einen klassischen MBR und wurde auch für klassische Rechner mit legacy BIOS erstellt.
EFI hätte da also gar nicht in Erscheinung treten dürfen.
Der Befehl wurde am Ende dann aber mit einer positiven Meldung quittiert und das alles geklappt hat. Und auf dem anderen Rechner konnte ich den USB Stick dann auch wie erwartet mit den neuen Menüeinträgen und der neuen ISO Distri booten.

[schwedenmann]

Hallo

Ich weiß jetzt nciht ob man per recue vom grubmenü jetzt booten kannst, falls das jetzt überhaupt kommt.

Ansonsten hast du dann 2 Möglichkeiten dein System zu booten

1. chroot Methode und dann grub-install /dev/wo immer du ihn hinhabne willst.

2. per rescatux oder Supergrubcd dein / bzw. /boot booten ud dann auch wiederr grub-install /dev/wo immer du ih hin haben willst

mfg
schwedenmann

[Cordess]

Hallo

Ich weiß jetzt nciht ob man per recue vom grubmenü jetzt booten kannst, falls das jetzt überhaupt kommt.

Nein, geht nicht. Ich erhalte nach dem booten ja gar kein grubmenu, sondern nur nen schwarzen Bildschirm

Ansonsten hast du dann 2 Möglichkeiten dein System zu booten

1. chroot Methode und dann grub-install /dev/wo immer du ihn hinhabne willst.

Ja, die werde ich wohl machen müssen. Allerdings ist das ja ein verschlüsseltes LUKS system, gepaart mit LVM, also recht aufwendig zum einbinden und chrooten.

Schöner wäre es, wenn ich die grub.cfg Configdatei in der boot Partition mit dem Kubuntu Live System, das ich gerade verwende, nutzen könnte
um den grub bootloader wiederherzustellen.
In der boot Partition ist ja auch noch die initrd und der Kernel und die ist unverschlüsselt.

2. per rescatux oder Supergrubcd dein / bzw. /boot booten ud dann auch wiederr grub-install /dev/wo immer du ih hin haben willst

Das müßte ich mir mal ansehen. Das kenne ich noch nicht.

[smutbert]

Vom Stick kannst du aber booten?
Dann würde ich im grub des Stick einmal <c> drücken, um in grubs Kommandozeile/Shell zu kommen und von dort die grub.cfg der boot-Partition der SSD laden:

In der Kommandozeile erhältst du mit ls eine Liste der Platten/SSDs/... und Partitionen, deren Dateisystem samit Label und UUID du dann in weiterer Folge mit

Code: Alles auswählen

ls (hd1,gpt1)

anzeigen lassen kannst. Wenn du dort deine boot-Partition erkennst, solltest du mit einem Befehl wie

Code: Alles auswählen

configfile (hd1,gpt1)/grub/grub.cfg

die Konfigurationsdatei laden können. In der grub-Shell gibt es mit <Tab> auch eine automatische Vervollständigung, die das ganze erleichtert und du kannst dir auch die Dateien und Verzeichnisse auflisten lassen

Code: Alles auswählen

ls (hd1,gpt1)/

Das Tastaturlayout ist halt amerikanisch. "(" liegt auf der Taste ")" und ")" auf "=", der Schrägstrich auf dem Minuszeichen.

Eigentlich solltest du damit in das gewohnte grub-Menü deines Debian kommen, es booten können und von dort wie gewohnt grub neu installieren können

[Cordess]

Dann würde ich im grub des Stick einmal <c> drücken, um in grubs Kommandozeile/Shell zu kommen und von dort die grub.cfg der boot-Partition der SSD laden:

Das ist ein sehr guter Tipp. Das werde ich gleich mal ausprobieren.
Danke dafür.

[KP97]

Auf jedem Installationsmedium befindet sich im Rescue Modus auch der Menüpunkt zur Installation des Grub Bootloaders.
Das sollte sich aber doch schon herumgesprochen haben...ist ja erst so lange, wie es Grub gibt...

[Cordess]

Vom Stick kannst du aber booten?
Dann würde ich im grub des Stick einmal <c> drücken, um in grubs Kommandozeile/Shell zu kommen und von dort die grub.cfg der boot-Partition der SSD laden:

So, habe das jetzt ausprobiert.

Doch es gibt ein Problem.
Er kennt die Dateisysteme nicht und zeigt für (hd1) und (hd2), die beiden SSDs die in Frage kommen folgendes
an:

Code: Alles auswählen

ls (hd1)
hd1 No known filesystem detected
Sector size 512B
....usw.

Das gleiche gilt für hd2.

Die auf dem multi OS USB Stick installierte Grubversion ist zu wohl zu alt.
Die Version ist 2.02"beta2-36ubuntu3.23

Das Ansprechen einer gpt Partition ergibt folgendes

Code: Alles auswählen

ls (hd1,gpt1)
error no such partition

Für die damalige Installation von Debian 10 habe ich auf einem anderen USB Stick ein Debian Installationssystem installiert.
Also habe ich es jetzt mal damit versucht.
Doch da wird grub viel zu schnell ausgeführt, so dass ich nicht in die grub shell komme.

Also habe ich in dem Debian Menü den Rescue Mode ausprobiert um die grub installation damit zu retten.
Das entschlüsseln der LUKS Partition und das Einbinden von dieser funktioniert alles.
Aber wenn ich dann grub in /dev/sda installieren will, erhalte ich folgende Fehlermeldung:

Code: Alles auswählen

grub-reinstall Fehlercode 1

[Cordess]

Auf jedem Installationsmedium befindet sich im Rescue Modus auch der Menüpunkt zur Installation des Grub Bootloaders.
Das sollte sich aber doch schon herumgesprochen haben...ist ja erst so lange, wie es Grub gibt...

Und das funktioniert nicht wie gewünscht.
Möglicherweise wurde es nie richtig getestet.

Schade ist auch, dass es die anderen /var, /home Volgroups nicht einbindet, das muss ich in der Shell alles händisch machen.
/var braucht es wohl für grub, das ergab zumindest die Meldung von update-grub.
Also habe ich die manuell auch eingebunden, aber grub ließ sich trotzdem nicht installieren.

[Cordess]

Für die damalige Installation von Debian 10 habe ich auf einem anderen USB Stick ein Debian Installationssystem installiert.
Also habe ich es jetzt mal damit versucht.
Doch da wird grub viel zu schnell ausgeführt, so dass ich nicht in die grub shell komme.

Hier muss ich mich korrigieren.

Wenn ich mir die grub.cfg und die Menüeinträge der Debian 10 Installations CD so ansehe, dann scheint das, was da grafisch kommt, das grub menü zu sein.
Allerdings komme ich mit dem nicht mit Taste c in eine grub shell.

Gibt's irgendeine Möglichkeit in einem laufenden Grub menu von der grafischen Grub Oberfläche in die Text Oberfläche umzuschalten, so dass man wenigstens an die Grub Shell herankommt?

[Cordess]

Für die damalige Installation von Debian 10 habe ich auf einem anderen USB Stick ein Debian Installationssystem installiert.
Also habe ich es jetzt mal damit versucht.
Doch da wird grub viel zu schnell ausgeführt, so dass ich nicht in die grub shell komme.

Hier muss ich mich korrigieren.

Wenn ich mir die grub.cfg und die Menüeinträge der Debian 10 Installations CD so ansehe, dann scheint das, was da grafisch kommt, das grub menü zu sein.
Allerdings komme ich mit dem nicht mit Taste c in eine grub shell.

Gibt's irgendeine Möglichkeit in einem laufenden Grub menu von der grafischen Grub Oberfläche in die Text Oberfläche umzuschalten, so dass man wenigstens an die Grub Shell herankommt?

Ich nehm das wieder zurück.

Es sieht zwar aus wie ein Menü mit Menüeinträgen von grub, aber wenn es grub wäre, müsste ich mit der ESC Taste in die TUI von grub landen. So steht es jedenfalls im Internet.
Dort lande ich allerdings nicht. Stattdessen gibt's Texterklärungen für den Debian Installer die man von Taste F1 bis ca. F8 durchschalten kann.


Ich habe also nochmal den rescue Modus des Debian Installer probiert, um grub doch noch irgendwie zu installieren.
Alle notwendigen Partitionen, inkl. /var manuell eingebunden und dann erhalte ich folgendes bei AFAIK update-grub:

Code: Alles auswählen

grub-probe Fehler für /dev/sdd1 konnte kein Grub-Laufwerk gefunden werden. Überprüfen sie ihre Device.map
Win 7 auf /dev/sde1 gefunden
erledigt

Anmerkung: Win 7 ist auf dem multi OS Stick als Installationsmedium drauf.
Zu dem Zeitpunkt waren 5 Datenträger eingebunden.

Meine 2 SSDs, eine HD und die zwei USB Sticks. Der eine Stick mit meinem Multi OS Installationsmenü, der andere mit dem Debian 10 Installer.

Ein grub-install ergibt übrigens folgendes:

Code: Alles auswählen

grub-install 
/usr/lib/grub/x86_64-ef-signed/modinfo.sh existiert nicht
Bitte geben Sie --target oder --directory an

Wenn ich das mache und auf /usr/lib/grub/x86_64-ef-signed/ verweise ändert das aber auch nichts, da es die modinfo.sh in diesem Verzeichnis nicht gibt.

[smutbert]

Vom Stick kannst du aber booten?
Dann würde ich im grub des Stick einmal <c> drücken, um in grubs Kommandozeile/Shell zu kommen und von dort die grub.cfg der boot-Partition der SSD laden:

So, habe das jetzt ausprobiert.

Doch es gibt ein Problem.
Er kennt die Dateisysteme nicht und zeigt für (hd1) und (hd2), die beiden SSDs die in Frage kommen folgendes
an:
[...]

Ok, da dürfte das Modul für die Partitionierung per gpt fehlen. Das habe ich vergessen zu bedenken oder erwähnen. Vorher einfach ein

Code: Alles auswählen

insmod part_gpt

dann sollten die Partitionen und Dateisysteme erkannt werden. Sicherheitshalber kannst du auch noch den Dateisystemtreiber laden, für ext2/3/4 also etwa

Code: Alles auswählen

insmod ext2

Danach müsste ls zumindest die Partitionen erkennen und hoffentlich auch das Dateisystem

Code: Alles auswählen

ls (hd1,gpt1)

wobei du das ls (hd1,gpt1) natürlich anpassen musst – du musst deine boot-Partition nehmen. Anhand der Ausgabe (den Dateien) erkennst du dann auch gleich ob es wirklich /boot ist und kannst dann die grub.cfg laden, wie oben beschrieben.

[Cordess]

Ich habe es jetzt endlich über den Rescue Mode der Debian Installations CD hingekriegt.

Die Gründe, warum es Anfangs nicht funktioniert hat waren:

1. Ich hatte den USB Stick im UEFI/BIOS via legacy boot gebootet, anstatt über UEFI.
Das hat dann dazu geführt, dass beim Ausführen von grub-installl folgender Fehler auftrat.
Der wurde über den Menüpunkt nicht angezeigt und ist mir daher erst aufgefallen, nachdem ich in der Konsole das manuell probiert habe:

Code: Alles auswählen

grub-install --target x86_64_efi
grub-install Waring EFI variables are not supported on this system.
Installation beendet. Keine Fehler gefunden.

x86_64_efi war das einzige target, für das es auch eine modinfo.sh Datei gab. Deswegen habe ich die explizit angegeben.
Das EFI Gedöhns war wohl nicht verfügbar, weil der USB Stick via legacy gebootet wurde.

Also habe ich ihn den USB Stick über die UEFI Boot Auswahl gebootet, das löste dann dieses Problem mit dem Warning EFI variables are not supported on this system.


Ein weiteres Problem war folgendes.
2. Der Reparaturmodus fragt einem, in welche Partition man Grub installieren soll.
Im Prinzip sieht man folgende Textmeldung:
https://wiki.debianforum.de/Datei:GRUB_ ... on_EFI.png
https://wiki.debianforum.de/Grub_repari ... onierung_2

Der Fehler, es wird einem NICHT gesagt, dass man Nichts eingeben soll, wenn es ein EFI System ist.
Ich habe immer /dev/sda versucht und das hat nicht geklappt.
Hier müsste man die Anweisung mal überarbeiten, damit man darauf hingewiesen wird. Wer sich mit dem Schreiben von Bugreports auskennt, kann das gerne machen.

Dieses Kommentar hier schreibe ich jetzt wieder unter meinem Debian System.
Das Grub Menü konnte ich wiederherstellen.
Allerdings fehlte der chainloading Eintrag für Windows 10.
Den muss ich jetzt irgendwie wieder herstellen.
Momentan kann ich Windows 10 nur übers UEFI(BIOS) per Direktauswahl auswählen und booten, nicht aber über grub, wie ich es zuvor immer konnte.

[Cordess]

So, dass mit dem fehlenden Win 10 Menüeintrag konnte ich jetzt auch mit einem einfachen
update-grub
grub-install
beheben.

Damit geht jetzt wieder alles wie gewünscht.
Aber es ist schon irgendwie ärgerlich, da ich den ganzen Tag damit verschwendet habe.

Dafür, wie ich jetzt zukünftig meine grub Menüeinträge für meinen Multi-OS USB Stick akutallisieren kann,
wenn ich den Paramter --root-directory=/media/nutzername/multi_os/ nicht mehr verwenden kann, ohne meine Grubinstallation für mein System zu beschädigen, dafür werde ich auch noch nach einer Lösung suchen müssen.

Dabei wäre es auch sinnvoll, wenn ich auch noch eine Lösung finde, wie ich die auf dem USB Stick installierte grub Version update.
2.02~beta2-3 ist laut Debian Changelog jedenfalls aus dem Jahr 2014 und dem Monat Januar, also uralt.

Ok, da dürfte das Modul für die Partitionierung per gpt fehlen. Das habe ich vergessen zu bedenken oder erwähnen. Vorher einfach ein

Code: Alles auswählen

insmod part_gpt

dann sollten die Partitionen und Dateisysteme erkannt werden. Sicherheitshalber kannst du auch noch den Dateisystemtreiber laden, für ext2/3/4 also etwa

Code: Alles auswählen

insmod ext2

Danach müsste ls zumindest die Partitionen erkennen und hoffentlich auch das Dateisystem

Code: Alles auswählen

ls (hd1,gpt1)

wobei du das ls (hd1,gpt1) natürlich anpassen musst – du musst deine boot-Partition nehmen. Anhand der Ausgabe (den Dateien) erkennst du dann auch gleich ob es wirklich /boot ist und kannst dann die grub.cfg laden, wie oben beschrieben.

Danke, das werde ich dann beim nächsten mal so machen.


EDIT:
Ach ja, von mir noch ein Dankeschön an alle, die mir geholfen haben.

[smutbert]

[...]

Dafür, wie ich jetzt zukünftig meine grub Menüeinträge für meinen Multi-OS USB Stick akutallisieren kann,
wenn ich den Paramter --root-directory=/media/nutzername/multi_os/ nicht mehr verwenden kann, ohne meine Grubinstallation für mein System zu beschädigen, dafür werde ich auch noch nach einer Lösung suchen müssen.

[...]

Ok, also erst einmal bin ich überrascht, dass du behauptest in der Vergangenheit mit grub-install mit der Option --root-directory=... nicht nur grub auf dem USB-Stick installiert sondern gleichzeitig eine passende grub.cfg erstellt zu haben.
Eigentlich dachte ich (und glaube es noch immer), dass update-grub für das Erstellen der grub.cfg zuständig ist und die Menüeinträge immer für das aktuell laufende System oder gegebenenfalls, das System in das man ge-chrootet hat, erstellt und mit zusätzlichen Paketen nur zusätzlich weitere Menüeinträge zum Starten fremder Systeme (os-prober) oder zum Beispiel von grml-iso-Images (grml-rescueboot) erstellen kann.


Ich meine also es läuft darauf hinaus, dass man die grub.cfg selbst schreibt. Um den grub zuerst auf einem USB-Stick oder einem anderen Medium für ein anderes System bzw. Systeme zu installieren, muss man angeben wo die Dateien von grub landen sollen (die Module von grub, die grub.cfg u. s. w.).
Für grub-pc (für BIOS/Legacy/CSM-Modus) muss man zusätzlich angeben wohin der Bootcode von grub geschrieben werden soll (üblicherweise in den MBR eines Speichermediums).
Bei grub-efi muss man stattdessen angeben wo die EFI System Partition ist, auf der grub landen soll und eventuell weitere Optionen für das Anlegen der Booteinträge im nvram.


Für grub-pc sollte mit

Code: Alles auswählen

grub-install --boot-directory=/media/nutzername/multi_os/ /dev/sdz

der Bootcode beispielsweise im MBR von /dev/sdz landen und die zugehörigen Dateien von grub in »/media/nutzername/multi_os/grub«, wo man dann auch selbst die grub.cfg anlegen kann. (Das ist im allgemeinen auch nicht besonders schwierig und man muss es vor allem nur einmal machen.)
Mit demselben Befehl lässt sich grub dann in Folge auch leicht updaten.


Bei grub-efi könnte man die gewünschte EFI System Partition unter »/mnt/efi« mounten und dann mit

Code: Alles auswählen

grub-install --boot-directory=/mnt/efi/EFI --efi-directory=/mnt/efi --removable --no-nvram

grub so installieren, dass alle seine Dateien in »EFI/grub« auf der EFI System Partition landen, wo man auch wieder die die grub.cfg anlegen kann, wobei --removable dafür sorgt, dass die .efi-Datei, die dann vom UEFI geladen wird, in einem Pfad gespeichert wird in dem sie auch ohne eigenen Booteintrag sucht und -no-nvram sorgt dafür, dass kein Booteintrag erstellt wird (anders hätte es auf einem Wechselmedium auch keinen Sinn, weil die Booteinträge ja im nichtflüchtigen Speicher des Computers erstellt werden).

[Cordess]

[...]

Dafür, wie ich jetzt zukünftig meine grub Menüeinträge für meinen Multi-OS USB Stick akutallisieren kann,
wenn ich den Paramter --root-directory=/media/nutzername/multi_os/ nicht mehr verwenden kann, ohne meine Grubinstallation für mein System zu beschädigen, dafür werde ich auch noch nach einer Lösung suchen müssen.

[...]

Ok, also erst einmal bin ich überrascht, dass du behauptest in der Vergangenheit mit grub-install mit der Option --root-directory=... nicht nur grub auf dem USB-Stick installiert sondern gleichzeitig eine passende grub.cfg erstellt zu haben.

Da liegt ein Missverständnis vor. So etwas habe ich nicht behauptet.

Meine grub.cfg für den USB Stick editiere ich per Hand.
Und mit grub--install --root-directory=/...usw /dev/sd? wurde es dann bisher installiert.

Ich meine also es läuft darauf hinaus, dass man die grub.cfg selbst schreibt. Um den grub zuerst auf einem USB-Stick oder einem anderen Medium für ein anderes System bzw. Systeme zu installieren, muss man angeben wo die Dateien von grub landen sollen (die Module von grub, die grub.cfg u. s. w.).
Für grub-pc (für BIOS/Legacy/CSM-Modus) muss man zusätzlich angeben wohin der Bootcode von grub geschrieben werden soll (üblicherweise in den MBR eines Speichermediums).
Bei grub-efi muss man stattdessen angeben wo die EFI System Partition ist, auf der grub landen soll und eventuell weitere Optionen für das Anlegen der Booteinträge im nvram.

Einfacher wäre es, wenn man grub-install sagen könnte wo die grub.cfg liegt bzw. welche es nehmen soll.
Dann noch den devicenamen mitangeben und das root Verzeichnis übergeben, damit die Pfadangaben in der übergebenen grub.cfg stimmen und schon könnte das alles ausreichen.

Leider ist es irgendwie komplett verdreht, so dass man sogar chrooten muss.

Für grub-pc sollte mit

Code: Alles auswählen

grub-install --boot-directory=/media/nutzername/multi_os/ /dev/sdz

der Bootcode beispielsweise im MBR von /dev/sdz landen und die zugehörigen Dateien von grub in »/media/nutzername/multi_os/grub«, wo man dann auch selbst die grub.cfg anlegen kann. (Das ist im allgemeinen auch nicht besonders schwierig und man muss es vor allem nur einmal machen.)
Mit demselben Befehl lässt sich grub dann in Folge auch leicht updaten.

--boot-directory werde ich mal ausprobieren.

Bei grub-efi könnte man die gewünschte EFI System Partition unter »/mnt/efi« mounten und dann mit

Code: Alles auswählen

grub-install --boot-directory=/mnt/efi/EFI --efi-directory=/mnt/efi --removable --no-nvram

grub so installieren, dass alle seine Dateien in »EFI/grub« auf der EFI System Partition landen, wo man auch wieder die die grub.cfg anlegen kann, wobei --removable dafür sorgt, dass die .efi-Datei, die dann vom UEFI geladen wird, in einem Pfad gespeichert wird in dem sie auch ohne eigenen Booteintrag sucht und -no-nvram sorgt dafür, dass kein Booteintrag erstellt wird (anders hätte es auf einem Wechselmedium auch keinen Sinn, weil die Booteinträge ja im nichtflüchtigen Speicher des Computers erstellt werden).

Danke, werde ich mir morgen mal angucken.