[gelöst] Ein /boot-Verzeichnis für mehrere Distributionen?

[Mounty]

Moin!

Ich habe eine NVMe-SSD (auf Adapter, PCIe), von der mein Rechner nicht booten kann (zu alt die Dose:-) Habe jetzt Testing mit einer /boot-Partition auf einer bootbare SSD installiert.

Kann ich diese /boot-Partition auch für weiter Distributionen verwenden?
Oder benötigt jede weiter Installation eine eigene /boot-Partition?

Fragt, mit Dank und Gruß
Mounty

[schwedenmann]

Hallo

Kann ich diese /boot-Partition auch für weiter Distributionen verwenden?

afaik nein, auch wenn es sich um dielben distrizwige handelns sollte

Oder benötigt jede weiter Installation eine eigene /boot-Partition?

Sollte für die weiteren OS auf der nvme nicht nötig sein, da du quasi per chainlaoding von der bootbaren /boot den bootloader der weiteren OS aufrufst.

ich würde einfach mal eine Distri als 2. OS auf die nvme installieren un den bootloder entweder gar nicht, oder in die Rootpartition installieren.
dann das 1.Linux wieder booten und updatwe-grub ausführen, dann sollte eigentlich das 2.Linux im grubmenü auftauchen und sich booten lassen.

mfg
schwedenmann

[Tintom]

Kann ich diese /boot-Partition auch für weiter Distributionen verwenden?

afaik nein, auch wenn es sich um dielben distrizwige handelns sollte

Kann man das so pauschal sagen? Ich habe jetzt keinen Gegenbeweis, aber warum sollte das nicht gehen?

[TuxPeter]

[...} aber warum sollte das nicht gehen?

Weil sie unterschiedlich sind! (vielleicht nur geringfügig, aber das reicht höchstwahrscheinlich für einen crash)
Wären sie es nicht, wären sie vermutlich die selbe Distri ...

[Livingston]

Es spricht nix dagegen, mehrere Distris auf verschiedenen root-Partitionen einzurichten und ein einzelnes boot-Verzeichnis zu verwenden. Man sollte aber nur über eine Distri den Bootmanager verwalten, ggf. grub manuell einrichten. Die verschiedenen Kernel findet grub ja selbst, holperig wird's nur beim Auffinden der jeweiligen root-Verzeichnisse.
Ein guter Kandidat für manuelle grub-Einträge ist /etc/grub.d/40_custom

[Mounty]

@schwedenmann
Die NVMe-SSD auf dem Adapter in einem PCIe-Slot, kennt das System erst nach booten des Kernels. Ob es eine Möglichkeit gibt, das Grub die NVMe mit "Hausmittel" erkennt, weiss ich nicht.

Es geht um das jeweilige oldstable (wird eigendlich nie mehr benötigt:-), stable und testing. Wenn jetzt nur Stable den Bootloder installiert, liegen dann nicht nur die verschieden Kernel der jeweiligen Distribution in /boot? Von Stable ist dann zusätzlich der Grub-Ordner vorhanden.

Die Suchmaschienen schmeisst immer Multiboot raus und ich finde keinen Ansatz so etwas aus Ihnen heraus zu holen.

Kann man eigentlich nachträglich das /boot-Verzeichniss in/auf eine andere Partition verschieben? Dann könnte ich mein jetziges Stabel auch auf die NVMe kopieren.

Gruß
Mounty

Edit: @Livingston hat sich überschnitten - bin nicht so schnell mit dem Schreiben...

[Livingston]

Das sind zwei unterschiedliche Themen.
1. Das Erkennen der NVMe-SSD als boot-Device liegt beim BIOS/UEFI. Da müsstest Du klar machen, wo gebootet wird. Generell ist es aber egal, wo grub liegt. Wenn Du von woanders aus startest, ist das ja durchaus auch (erstmal) ok.
2. Für verschiedene Distris/Versionen ist es wichtig, dass nur eine die Kontrolle über die grub-Installation hat. D.h. Du solltest grub von testing und unstable deinstallieren. Immer wenn Du in testing /unstable einen neuen Kernel installierst/updates, muss hinterher in stable ein update-grub manuell durchgeführt werden. Damit werden zunächst einmal alle Kernel gefunden. Problematisch ist nur, dass grub nicht wissen kann, welche(r) kernel sich auf welche Distri beziehen. Defaultmäßig werden folglich alle angebotenen Kernel als Auswahl für stable angeboten.
Für die anderen Varainaten musst Du also selbst einen Eintrag in /etc/grub.d/40_custom vornehmen.

[Livingston]

Beispiel mit zwei Installationen.
1. stable hat root auf /dev/sda3. Hier ist auch das Paket grub installiert.
2. testing mit root auf /dev/sdb5, wobei hier kein grub installiert ist.
Beide teilen sich /dev/sda1 und binden es als /boot ein.

Immer wenn Du auf stable den Kernel updatest, wird auch automatisch update-grub aufgerufen. Dabei wird nach Kernels in /boot gesucht und die Datei /boot/grub/grub.cfg neu gebaut. Grundlage dafür sind die Dateien /etc/default/grub und die Dateien unter /etc/grub.d/.

Von stable aus aufgerufen findet update-grub dann die Kernel 4.19.x aus der stable-Installation und 5.8.x aus testing. Es entstehen dann zwei Einträge für stable, um dieses entweder mit dem 4er- oder mit dem 5er-Kernel zu starten, aber erst mal keiner für testing.
Den baust Du selber, indem Du /etc/grub.d/40_custom selbst aufmöppelst. Wenn Du da mal in die Datei reinschaust siehst Du am Anfang, dass sie nichts anderes macht, als sich unter Auslassung der ersten 3 Zeilen selbst auszugeben.
Dieser Output wird von update-grub wortwörtlich in die neu zu erstellende Datei /boot/grub/grub.cfg übernommen.

Du kannst also aus /boot/grub/grub.cfg bestehende Einträge der stable-Installation als Vorlage herauskopieren und an das Dateiende von 40_custom packen. Dann noch so abändern, dass das richtige root-Verzeichnis und der korrekte Kernel für testing herausgepickt werden.

Zugegeben, so eine grub.cfg sieht ziemlich wild aus, aber das, worum es geht ist gar nicht so bösartig. Such einfach nach dem Schlüsselwort menuentry, kopiere den ganzen Block nach 40_custom und ändere noch die Angaben am Ende von

Code: Alles auswählen

        echo    'Linux 4.19.xxx wird geladen …'
        linux   /vmlinuz-4.19.xxx root=/dev/sda3 ro  
        echo    'Initiale Ramdisk wird geladen …'
        initrd  /initrd.img-4.19.xxx

nach

Code: Alles auswählen

        echo    'TESTING: Linux 5.8.xxx wird geladen …'
        linux   /vmlinuz-5.8.xxx root=/dev/sdb5 ro  
        echo    'Initiale Ramdisk wird geladen …'
        initrd  /initrd.img-5.8.xxx

Am Schluss noch mal ein update-grub und fertig.

[rhHeini]

Eines gemeinsames /boot macht man doch nur wenn man keinen Festplattenplatz verfügbar hat. Bei einigermassen aktueller HW und nicht zu knappen Platz sollten 1G oder 2G für ein separates /boot spendierbar sein. Es macht Sinn da eher etwas grosszügig zu sein.

Meine neuesten Rechner sind mit EFI installiert, >= GPT Partitionierung, es läuft Arch, Stable und Testing, alle verschlüsselt. Stable und Testing kriegen ihr eigenes 2G /boot, und ich hab immer noch Platz auf der nvme fürs System. Jedes System ist für sich über die efi-Einträge bootbar. Die 3 sehen sich ansonsten nicht, und ich hab auch keinen Ärger mit Neben- und Rückwirkungen aus dem einen ions andere System.

Rolf

[Mounty]

Moin!

Ich habe jetzt erst mal meine kleine SSD frei gemacht. Habe jetzt Stable einfach auf die große SSD geklont. Win10 auf die frei gemachte SSD geklont (habe jetzt ein bisschen mehr Platz für mein Spiel:-) und kleinste der SSDs befindet sich jetzt in der NAS (Cache). Rechner innen reinigen war auch angesagt...

@Livingston
Danke für deine Bemühung mich zu unterstützen. @rhHeini hat schon recht, jedem System sein eigenes /boot-Verzeichnis. Haupsächlich, weil ich mich kenne und irgendwann vergesse das Formatieren des /boot-Verzeichnis bei einer Neuinstallation auszuschalten.

Danke euch Allen und Gruß
Mounty