%20grub-update%20findet%20kein%20System%20auf%20einem%20anderen%20Laufwerk%20(Fedora%2034%20KDE).png)
Ich habe mehrere Systeme installiert; zuerst in chronologischer Reihenfolge Windows 10, dann Kubuntu 20.04, dann Fedora 34 KDE und dann KaOS. Fedora befindet sich allein auf einem zweiten Laufwerk mit seinem separaten EFI, teilt sich dieses aber mit KaOS.
Die Konfiguration ist also:
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 739327 737280 360M EFI System
/dev/nvme0n1p2 739328 1001471 262144 128M Microsoft reserved
/dev/nvme0n1p3 1001472 457750527 456749056 217,8G Microsoft basic data
/dev/nvme0n1p4 457750528 459757567 2007040 980M Windows recovery environment
/dev/nvme0n1p5 459757568 500107263 40349696 19,2G Microsoft basic data
/dev/nvme0n1p6 500107264 644737022 144629759 69G Linux filesystem
/dev/nvme0n1p7 644737023 976773134 332036112 158,3G Linux filesystem
Device Start End Sectors Size Type
/dev/sda1 2048 1230847 1228800 600M EFI System
/dev/sda2 251660288 1258293247 1006632960 480G Linux filesystem
/dev/sda3 1258293248 1875384319 617091072 294,3G Microsoft basic data
/dev/sda4 1230848 3327999 2097152 1G Linux filesystem
/dev/sda5 3328000 251660287 248332288 118,4G Linux filesystem
/dev/nvme0n1p1
ist die EFI-Partition für Windows (installiert auf /dev/nvme0n1p2
) 5
und Ubuntu (installiert auf nvme0n1p6
),
/dev/sda1
ist die EFI für Fedora ( /dev/sda4
und 5
) und KaOS ( /dev/nvme0n1p7
)
Diese merkwürdige Wahl hängt mit der Tatsache zusammen, dass die vorherige Installation eines anderen Linux-Systems neben Kubuntu, das dasselbe EFI wie Windows verwendete, zu einer Beschädigung des Windows-Startvorgangs führte. Dies wurde durch eine Neuinstallation von Kubuntu behoben, wodurch Windows zu seinem Startmenü hinzugefügt wurde. Ich wollte derartige Störungen mit Windows vermeiden und habe daher Fedora auf einem separaten Laufwerk mit seinem eigenen EFI installiert. Als ich dann KaOS auf demselben Laufwerk wie Windows installiert habe, habe ich ausgewählt, das EFI des anderen Laufwerks zu verwenden und es mit Fedora zu teilen.
Nach der Installation von KaOS ist das Bootmenü (ausgeführt von systems-boot
, nicht grub
)die anderen Systeme wurden nicht angezeigt.
Die Bootmenüs von Fedora und Ubuntu waren in der UEFI-Firmwareschnittstelle versteckt. Bei Fedora waren alle Systeme enthalten.kUbuntus Boot-Menü enthielt alle außer Fedora.
Ich habe die Boot-Reparatur verwendet, um Fedoras Boot-Menü zum Standard zu machen, da es das vollständigste war (durch die Installation von Grub auf sda1
), aber es gab keine Option, Fedora „zuerst zu booten“: also habe ich Kubuntu ausgewählt. Das Ergebnis warDas Startmenü von Kubuntu wird zum Standard, nur Fedora fehlt.
Da Kubuntu Grub jetzt die Kontrolle hat, würde ich das gerne verwenden und einfach Fedora hinzufügen. Ein Update von Grub hilft nicht.
EDIT-1, nach Kommentaren von @oldfred:
Boot-Reparatur-Bericht überPastebin-AuchHIER(in Kommentaren gefragt)
EDIT-2, nach Antwort von @oldfred:
Ich habe in den grub.cfg-Dateien von Kubuntu nachgeschaut und festgestellt, dass die Kubuntu-Bootliste durch die Datei bestimmt wird, boot/grub/grub.cfg
indem dort ein Menüeintrag hinzugefügt wird.
Beim Betrachten von Fedoras eigener grub.cfg-Datei, die ich finden konnte, fehlen dort Fedora-Einträge, nur der Rest der Systeme ist aufgelistet. Nur diese sind auch im Grub Customizer auf Fedora zu sehen: Fedora-Einträge in seiner eigenen Bootliste scheinen durch die separaten Dateien aus /loader/entries/
seiner 1 GB großen Root-Ext4-Partition (sda4) bestimmt zu sein. Das Kopieren dieser in Kubuntus /boot/efi/loader/entries/ hat keine Wirkung.
Da ich kein Fedora-eigenes Modell für einen Eintrag in Kubuntu habe boot/grub/grub.cfg
, habe ich die Zeilen, die ich dort für KaOS finde, kopiert und geändert – indem ich Fedoras Spezifikationen, nämlich die UUID, hinzugefügt habe. Ich bin nicht sicher, ob die Formatierung korrekt ist; in dieser Datei ist genau die gleiche wie für KaOS, nur der Name der Distribution und die UUID wurden angepasst:
menuentry 'Fedora 34 KDE' --class Fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-4834b108-13c9-406c-8a7b-a9c53440283c' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod fat
set root='hd0,gpt1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 F4F4-1172
else
search --no-floppy --fs-uuid --set=root F4F4-1172
fi
echo 'Loading Linux linux ...'
linux /vmlinuz-linux root=UUID=4834b108-13c9-406c-8a7b-a9c53440283c rw quiet
echo 'Loading initial ramdisk ...'
initrd /initramfs-linux.img
}
Auf diese Weise wird der Name Fedora natürlich zur Bootliste hinzugefügt, aber es funktioniert nicht:
mit der UUID der bfrs
Partition ( sda5
) erhalte ich die Meldung:
mount: new/-root: unknown filesystem type ‘btrfs’
Ich habe es vorsichtshalber mit der UUID der „Root“-Fedora-Partition ( sda4
) versucht und erhalte die Meldung:
Error: root device mounted successfully but sbin/init does not exist
Der richtige Weg ist meiner Meinung nach, die UUID der sda5
Partition hinzuzufügen; diese ist diejenige, die in allen drei oben genannten Dateien auf Fedoras/loader/entries/
Es scheint, dass Grub btrfs nicht erkennt.
Ich habe alle „btrfs“-bezogenen Dateien installiert, die ich mit Apper finden konnte, ungefähr 30 Pakete, aber es passiert das Gleiche.
BEARBEITEN-3
Aus weiteren Kommentaren verstehe ich, dass ich boot/grub/grub.cfg
die Datei nicht bearbeiten darf, sondern etc/grub.d/40_custom
nur Teile anderer Dateien kopieren muss. Aber ich verstehe nicht, welche Dateien ich verwenden soll. Ich konnte auf Fedoras eigenen Partitionen nichts finden, das mit seinem eigenen Boot und seinem eigenen Eintrag in der Bootliste zu tun hat, außer Dateien in ext4
- /loader/entries
. Soll ich also eine davon kopieren?
Ist es etwas wie das hier, das kopiert wurde /media/root/651b659a-8fc5-46d6-b291-22b3b523ebaf/loader/entries/a037a4898b9540bfbc52f3f377b2ff4d-5.13.19-200.fc34.x86_64.conf
(also von Fedoras 1 GB großer ex4-Partition sda4):
title Fedora (5.13.19-200.fc34.x86_64) 34 (KDE Plasma)
version 5.13.19-200.fc34.x86_64
linux /vmlinuz-5.13.19-200.fc34.x86_64
initrd /initramfs-5.13.19-200.fc34.x86_64.img
options root=UUID=4834b108-13c9-406c-8a7b-a9c53440283c ro rootflags=subvol=root rhgb quiet
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel
Oder ist es so etwas wie der Eintrag für KaOS in der Datei von Kubununtu, der boot/grub/grub.cfg
oben unter EDIT-2 gepostet wurde?
Antwort1
Ich hatte Fedora einmal installiert, aber vorher verwendete es btrfs. Aber mein Grub-Eintrag in Ubuntu wurde per Chainloading oder Konfigurationsdatei in den UEFI-Boot-Eintrag geladen. Ich habe diese zu 40_custom in Ubuntus Grub hinzugefügt. Die UUIDs sind eindeutig und Sie müssen sie in die UUIDs Ihrer Installation ändern. Um direkt in Grub zu booten
menuentry "Fedora UEFI" {
search --file --no-floppy --set=root F496-1330
chainloader (${root})/efi/fedora/grub.cfg
}
Sie können oft einfach eine Boot-Strophe für Grub von einer Installation in eine andere kopieren. Das macht os-prober. Sie benötigen möglicherweise zusätzliche Treiber (btrfs) oder .mod-Dateien von Grub2 (wie btrfs.mod), damit es verschiedene Formate oder Konfigurationen erkennt. Wenn Sie rEFInd verwenden, müssen Sie die Grub-Strophe in refind.conf übersetzen. Eine Konfigurationsdatei ist ein Link zu einer anderen Datei, die Grub ist oder Boot-Strophen vom Typ Grub hat.
menuentry "Fedora UEFI" {
search.fs_uuid a9bd9a65-bc8c-41b1-95b1-2dceb66b2652 root hd1,gpt2
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg
}
Verwenden von 40_custom und benutzerdefiniertem Menü
https://help.ubuntu.com/community/Grub2/CustomMenus
Konfigurationsdatei:
https://www.gnu.org/software/grub/manual/grub/grub.html#Multi_002dboot-manual-config
https://ubuntuforums.org/showthread.php?t=2076205&page=54&p=13788092#post13788092