[gelöst] Multiboot Grub - Jedes Linux installiert seine eigene Grub-Konfiguration

[Bluesky787]

Hallo liebe Community,

ich habe kürzlich mithilfe dieser Anleitung http://forums.debian.net/viewtopic.php? ... 4&start=15 ein zweites Linux (Kali) installiert, sodass ich jetzt Windows, Debian und Kali Linux auf zwei Festplatten verteilt installiert habe.
Mein Problem ist nun, dass Kali nun zwar einen funktionierenden Bootloader installiert hat (ich habe ein bisschen basteln müssen, damit auch Debian wieder startet, weil ich bei der Installation die Boot-Partition neu formatiert habe), Debian diesen aber immer wieder mit einem nicht funktionierenden Grub überschreibt, sobald ein Paket-Upgrade durchgeführt wird.
In der Grub-Konfiguration von Debian soll bspw. in der Debian-Startkonfiguration die linux-image-Datei 5.10 von Kali gebootet werden, obwohl Debian bei mir unter dem Kernel 5.7 läuft (war notwendig, weil die WLAN-Treiber mind. 5.0 erfordern). Kali wird zwar erkannt, soll aber von LVM--vg-Debian geladen werden.

Sobald ein Upgrade gemacht wurde, bleibt mir nichts anderes übrig, als über Timeshift die alte Boot-Partition wiederherzustellen, den ursprünglichen Kali-Eintrag in den Erweiterten Bot-Einträgen von Kali zu starten und im gebooteten Kali Grub neuzuinstallieren.

Wie kann ich Debian davon überzeugen, entweder
a) Grub nicht mehr zu überschreiben (nach jedem Update im Zweifel Kali den Grub aktualisieren zu lassen), oder
b) die auf /dev/sda1 installierte Grub-Konfiguration zu respektieren?

Ich habe unter Kali das Tool Grub-Customizer genutzt, der mittels OS-Prober die OS-Installationen erkennt und entsprechende Starteinträge erstellt. OS-Prober unter Debian erstellt hingegen nur diese merkwürdigen Fehlkonfigurationen.

Über Hilfe freue ich mich riesig, vielen Dank schon einmal!

Viele Grüße
Bluesky787

---
Ausdruck von lsblk (Anmerkungen mit --):

Code: Alles auswählen

sda                      8:0    0   1,8T  0 disk  
├─sda1                   8:1    0   500M  0 part  /boot
├─sda2                   8:2    0 242,8G  0 part  -- leer
├─sda4                   8:4    0     1K  0 part  
├─sda5                   8:5    0   150G  0 part  -- Datenpartition
├─sda6                   8:6    0   1,1T  0 part   -- Datenpartition
└─sda7                   8:7    0   326G  0 part  
  └─sda7_crypt         254:0    0   326G  0 crypt 
    ├─LVM--vg-Debian 254:1    0 186,3G  0 lvm   /
    └─LVM--vg-Kali   254:2    0 139,7G  0 lvm   
nvme0n1                259:0    0 465,8G  0 disk  
├─nvme0n1p1            259:1    0   529M  0 part  
├─nvme0n1p2            259:2    0    99M  0 part  /boot/efi
├─nvme0n1p3            259:3    0    16M  0 part  
└─nvme0n1p4            259:4    0 465,1G  0 part  -- Windows

-- Ausdruck von ls -vaulth der Boot-Partition:
drwx------  2 root root 4,0K Feb  7 16:00 lost+found
drwxr-xr-x  6 root root 4,0K Feb  7 16:00 grub
drwx------  5 root root 4,0K Feb  7 16:00 efi
-rw-r--r--  3 root root 6,5M Feb  5 20:08 vmlinuz-5.10.0-kali3-amd64
-rw-r--r--  3 root root 231K Feb  5 20:08 config-5.10.0-kali3-amd64
-rw-r--r--  3 root root  66M Feb  5 20:08 initrd.img-5.10.0-kali3-amd64
-rw-r--r--  3 root root   83 Feb  5 20:08 System.map-5.10.0-kali3-amd64
-rw-r--r--  7 root root 6,5M Feb  3 08:00 vmlinuz-5.10.0-kali2-amd64
-rw-r--r--  7 root root 231K Feb  3 08:00 config-5.10.0-kali2-amd64
-rw-r--r--  7 root root  66M Feb  3 08:00 initrd.img-5.10.0-kali2-amd64
-rw-r--r--  7 root root   83 Feb  3 08:00 System.map-5.10.0-kali2-amd64
-rw-r--r--  9 root root 5,4M Jan 24 01:51 vmlinuz-5.7.0-0.bpo.2-amd64
-rw-r--r--  9 root root  57M Jan 24 01:51 initrd.img-5.7.0-0.bpo.2-amd64
-rw-r--r--  9 root root 225K Jan 24 01:51 config-5.7.0-0.bpo.2-amd64
-rw-r--r--  9 root root 4,1M Jan 24 01:51 System.map-5.7.0-0.bpo.2-amd64

-- Ausdruck der (funktionierenden) grub.cfg unter Kali:
pastebin/?mode=view&s=41265

-- Ausdruck der (nicht funktionierenden) grub.cfg unter Debian:
pastebin/?mode=view&s=41266

[smutbert]

Bei grub-pc kannst du mit

Code: Alles auswählen

# dpkg-reconfigure -p low grub-pc

die Geräte auswählen auf denen grub installiert (und aktualisiert wird). Wählst du hier kein Gerät aus, wird grub auch nicht mehr jedes Mal von neuem installiert.

Wenn du im uefi-Modus bootest, also grub-efi-amd64 verwendest, genügt es stattdessen einfach die EFI System Partition nicht zu mounten, damit grub nicht mehr aktualisiert/installiert werden kann, indem du beispielsweise den Eintrag für /boot/efi entfernst oder auskommentierst.


Ich weiß nicht wie die der Bootmenüeintrag für debian unter Kali automatische erzeugt wird, aber wenn du unter kalis grub selbst einen Booteintrag für Debian anlegst, dann könntest du unter Debian auch einfach alle grub-Pakete deinstallieren und wärst das Problem auch los.

[Emess]

Bei grub-pc kannst du mit

Code: Alles auswählen

# dpkg-reconfigure -p low grub-pc

die Geräte auswählen auf denen grub installiert (und aktualisiert wird). Wählst du hier kein Gerät aus, wird grub auch nicht mehr jedes Mal von neuem installiert.

Da hätte ich mal ne Frage zu.
Bei mir z.Z. Multiboot
1. Windows
2. Stable
3. Testing

Grub liegt jetzt auf Testing, weil es zuletzt installiert wurde.
Wenn es also jetzt auf Stable ein Kernelupdate gibt muss ich Testing starten um ein update-grub machen kann.
Bringt mir grub-pc einen vorteil?

[smutbert]

Bringt grub-pc einen Vorteil gegenüber was?
Wenn du auf efi vs bios, bzw. grub-efi-* vs grub-pc hinauswillst, dann nicht und eine grub-Version wirst du ja schon haben. Ich glaube ich weiß aber was du damit meinst:

Wenn es also jetzt auf Stable ein Kernelupdate gibt muss ich Testing starten um ein update-grub machen kann.

und es gibt mehrere Möglichkeiten das zu umgehen.
Verfügen deine Debians über eine eigene /boot-Partition (das würde die Sache minimal verkomplizieren)?

[Emess]

Verfügen deine Debians über eine eigene /boot-Partition (das würde die Sache minimal verkomplizieren)?

Gebootet wird im MBR vond Sda

[smutbert]

Das ist nicht ganz die Antwort, die ich erwartet habe
Ich meinte ob zB dein stable komplett auf einer Partition installiert ist oder ob / und /boot auf getrennten Partitionen liegen?

[willy4711]

Ich meinte ob zB dein stable komplett auf einer Partition installiert ist oder ob / und /boot auf getrennten Partitionen liegen?

Zumindest /boot scheint alles zu enthalten : Debian und Kali ---> Sehr seltsame Konfiguration

-- Ausdruck von ls -vaulth der Boot-Partition:

Code: Alles auswählen

ls -vaulth
drwx------ 2 root root 4,0K Feb 7 16:00 lost+found
drwxr-xr-x 6 root root 4,0K Feb 7 16:00 grub
drwx------ 5 root root 4,0K Feb 7 16:00 efi
-rw-r--r-- 3 root root 6,5M Feb 5 20:08 vmlinuz-5.10.0-kali3-amd64
-rw-r--r-- 3 root root 231K Feb 5 20:08 config-5.10.0-kali3-amd64
-rw-r--r-- 3 root root 66M Feb 5 20:08 initrd.img-5.10.0-kali3-amd64
-rw-r--r-- 3 root root 83 Feb 5 20:08 System.map-5.10.0-kali3-amd64
-rw-r--r-- 7 root root 6,5M Feb 3 08:00 vmlinuz-5.10.0-kali2-amd64
-rw-r--r-- 7 root root 231K Feb 3 08:00 config-5.10.0-kali2-amd64
-rw-r--r-- 7 root root 66M Feb 3 08:00 initrd.img-5.10.0-kali2-amd64
-rw-r--r-- 7 root root 83 Feb 3 08:00 System.map-5.10.0-kali2-amd64
-rw-r--r-- 9 root root 5,4M Jan 24 01:51 vmlinuz-5.7.0-0.bpo.2-amd64
-rw-r--r-- 9 root root 57M Jan 24 01:51 initrd.img-5.7.0-0.bpo.2-amd64
-rw-r--r-- 9 root root 225K Jan 24 01:51 config-5.7.0-0.bpo.2-amd64
-rw-r--r-- 9 root root 4,1M Jan 24 01:51 System.map-5.7.0-0.bpo.2-amd64

[TRex]

@willy: du bist nun dem Hijacking von Emess zum Opfer gefallen und hast dadurch zwei Systeme/Threads vermischt.

Da hätte ich mal ne Frage zu.

@Emess: bitte lass das in Zukunft. Ich werde die Threads nun nicht mehr trennen (können). Mach für deine Probleme eigene Threads auf, wenn du mehr als nur zuschauen willst, ob es auch dein Problem löst.
Infolgedessen: bitte beschränkt eure Antworten auch auf das System des TE. Ansonsten seh ich mich gezwungen, das auch mit Verlust zu trennen.

[willy4711]

Upppsss
Aber so verkehrt war mein Beitrag ja nun wieder auch nicht.

Es ist doch zumindest sehr ungewöhnlich, dass beim TE die Intrids für Kali und Debian auf der
gleichen Partition + Verzeichnis liegen (sda1 8:1 0 500M 0 part /boot), die dann auf unterschiedliche LV's verweisen.

Mag ja alles gehen, wenn man händisch eingreift. Aber die "Intelligenz" von update-grub scheint
darauf nicht geschult worden zu sein.

[schwedenmann]

Hallo

@willy4711
Es ist doch zumindest sehr ungewöhnlich, dass beim TE die Intrids für Kali und Debian auf der
gleichen Partition + Verzeichnis liegen (sda1 8:1 0 500M 0 part /boot), die dann auf unterschiedliche LV's verweisen.

Wieso wenn es nur eine /boot gibt aber 2 LVm mit jeweisl einer / und damn dann bei der Installation von debian lvm1 die seperate /boot angibt grub in den MBR und bei Kali grnau daselbe, dann kommtz so ein Unsinn dabei raus.


Bei Multiboot

1. Ein OS installert grub und generiert das grub-boot-Menü

2. alle anderen OS installieren keinen bootloader, oder eben in die eigene /root-Partition, fertig.

3. leider funktioniert das mit dem ohne grub nicht mit allen Installern der distributuionen, habe ich öfters festgetsellt.

4. kleienr nachteil bei Methode 1, man muß das hauptsystem das grub installeirt hat, jeweils starten und update-grub ausführen, wenn auf den anderen OS ei kernelupdate stattgefunden hat, kann man ev. nach @smutbert, iczh vermute dahin ging sdein Tip, per chainloading oder eigenen grubeintrag umgehen. m.M. ist 1) der saubere Weg.

mfg
schwedenmann

[TRex]

Hallo

@willy4711

Es ist doch zumindest sehr ungewöhnlich, dass beim TE die Intrids für Kali und Debian auf der
gleichen Partition + Verzeichnis liegen (sda1 8:1 0 500M 0 part /boot), die dann auf unterschiedliche LV's verweisen.

Wieso wenn es nur eine /boot gibt aber 2 LVm mit jeweisl einer / und damn dann bei der Installation von debian lvm1 die seperate /boot angibt grub in den MBR und bei Kali grnau daselbe, dann kommtz so ein Unsinn dabei raus.


Bei Multiboot

1. Ein OS installert grub und generiert das grub-boot-Menü

2. alle anderen OS installieren keinen bootloader, oder eben in die eigene /root-Partition, fertig.

3. leider funktioniert das mit dem ohne grub nicht mit allen Installern der distributuionen, habe ich öfters festgetsellt.

4. kleienr nachteil bei Methode 1, man muß das hauptsystem das grub installeirt hat, jeweils starten und update-grub ausführen, wenn auf den anderen OS ei kernelupdate stattgefunden hat, kann man ev. nach @smutbert, iczh vermute dahin ging sdein Tip, per chainloading oder eigenen grubeintrag umgehen. m.M. ist 1) der saubere Weg.

mfg
schwedenmann

Dein Beitrag liest sich besser, wenn du Zitate entsprechend markierst. Ich hab das mal hier entsprechend vorgemacht. Kannst du übrigens aus dem Antworten-Dialog raus tun.

[willy4711]

Da ich die Nase Voll hatte von os-prober bzw. der händischen Korrektur via grub-customizer
hab ich mein Dual- Boot System mit Chainloading gelöst. Seitdem ist Ruhe.
Jedes System erstellt bei Kernel-Updates seinen eigenen Grub
Auf der Startplatte wurde eine /etc/grub.d/40_custom angelegt:

Code: Alles auswählen

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "Debian SID Xfce" {
	insmod ext2
	search --fs-uuid --no-floppy --set=root f8e37245-8f05-4fb5-93bc-e76299146c13
	configfile /boot/grub/grub.cfg
	chainloader +1
}

In der /boot/grub/grub.cfg sieht das dann so aus:

Code: Alles auswählen

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "Debian SID Xfce" {
	insmod ext2
	search --fs-uuid --no-floppy --set=root f8e37245-8f05-4fb5-93bc-e76299146c13
	configfile /boot/grub/grub.cfg
	chainloader +1
}
### END /etc/grub.d/40_custom ###

Einziger Nachteil: Man durchläuft dabei 2x Grub,, was mich aber nicht stört
Vorteile:
Jedes System kann via Auswahl der Startplatte problemlos separat gestartet werden.
Absolut wartungsfrei

Hatte mal dazu einen Thread gehabt:
viewtopic.php?f=29&t=178120

[Livingston]

Zur ursprünglichen Fragestellung: Man kann einfach einen der beiden grubse deinstallieren. Ich würde den grub des Systems stehenlassen, mit dem ich hauptsächlich arbeite.

[Bluesky787]

Hallo zusammen,

da hab ich ja eine rege Diskussion ausgelöst. xD
Das bei mir in /boot alle Systeme drin liegen, hat den Grund, dass ich ursprünglich auf meinem alten Laptop nur eine Festplatte drin hatte und somit die drei Systeme nur auf einer Festplatte lagen. Die Boot und LUKS-Partitionen und Windows ließen sich aber allesamt nur auf aktiven Partitionen installieren (Unter BIOS/MBR waren nur 4 Partitionen erlaubt, logische Partitionen konnten weiter unterteilt werden, waren aber nicht bootfähig). Da hab ich so rumgetrickst, dass Windows, Windows-Boot und der LUKS-Container jeweils eine aktive Partition bekommen haben und dann nur noch eine Partition als Logische Partition für das LVM für zur Verfügung stand. Grub war dann auf dem MBR installiert.

Nun wollte ich das alles umziehen und hab daher die alte Anleitung rausgekramt, wie ich die beiden Linuxe im selben LUKS-Container mit LVM installieren kann, auch wenn jetzt eine aktive Partition (die alte Windows-Partition) wieder frei gewesen wäre. Umziehen hat übrigens nicht funktioniert, sodass ich beide Systeme neu installieren musste (wegen Umzug von BIOS auf EFI).

@smuthbert:
Grub-PC ist bei mir nicht installiert, weil bei mir nun alles auf EFI läuft. Wie deaktiviere ich Grub auf Debian, wenn ich EFI nutze?

Der allgemeinen Diskussion entnehme ich aber, dass Debian gerade wegen den ganzen Boot-Images des anderen Linux verwirrt ist und deswegen Grub nicht mehr sinnvoll konfigurieren kann. Insofern würde ich nun einfach Grub auf Debian deaktivieren und bei jedem größeren Update die Boot-Einträge von Kali bzw. per Hand mit Grub-Customizer aktualisieren.
Debian scheint da aber auch nicht so häufig Updates zu machen, bei denen die Boot-Einträge aktualisiert werden müssten, insofern komme ich mit der Lösung gut klar.
Die Alternative dazu wäre dann wahrscheinlich, Debian eine eigene Boot-Partition zuzuweisen, oder?

Viele Grüße
Bluesky787

[schwedenmann]

Hallo

Die Alternative dazu wäre dann wahrscheinlich, Debian eine eigene Boot-Partition zuzuweisen, oder?

Nö, einfach /boot als Verzeichn is von / nutzen.

1. grub von Debian entfernen, bzw nicht in den MBR, sondern in / installieren. Wobei ohne grub wohl hier bei UEFI die bessere wahl wäre, bei legacy boot geht sowas ohne Probleme.

grub entferne per apt-get purge grub-blablabla, je nachdem, wie die Pakete heißen, oder apt-get purge grub* (syntax ungetestet).

mfg
schwedenmann

[smutbert]

@smuthbert:
Grub-PC ist bei mir nicht installiert, weil bei mir nun alles auf EFI läuft. Wie deaktiviere ich Grub auf Debian, wenn ich EFI nutze?

Einfach dafür sorgen, dass die EFI Partition nicht mehr unter /boot/efi gemountet wird, indem du beispielsweise den fstab-Eintrag dafür auskommentierst.

[Bluesky787]

@smutbert Eine etwas späte Erfolgsmeldung, aber das hat geholfen, vielen Dank!
Allen zukünftigen Lesern dieses Threads kann ich nur empfehlen, die Boot-Partitionen zweier Linux-Systeme nicht zusammen auf eine Partition zu installieren. xD

Viele Grüße
Bluesky787