☰

So geben Sie eine EFI-Bootpartition frei

tag-icon • tag-icon linux boot arch-linux uefi efi
So geben Sie eine EFI-Bootpartition frei

Ich habe zwei Archlinux-Installationen auf einem EFI-System, das mit Gummiboot eingerichtet wurde. Eine ist unter /dev/sda2 verwurzelt, die andere unter /dev/sdb1. Beide verwenden /dev/sda1, die EFI-Systempartition, als ihre /boot-Partition, platzieren ihre Kernel-Images jedoch an unterschiedlichen Orten:

/boot/loader/entries/arch.conf:

title   Arch Linux
linux   /vmlinuz-linux
initrd  /intel-ucode.img
initrd  /initramfs-linux.img
options root=/dev/sda2 rw

/boot/loader/entries/arch-here.conf:

title   HERE Arch Linux
linux   /here-img/vmlinuz-linux
initrd  /here-img/intel-ucode.img
initrd  /here-img/initramfs-linux.img
options cryptdevice=/dev/sdb1:cryptroot root=/dev/mapper/cryptroot rw

Das ging gut, bis ich den Kernel von 4.8.13 auf 4.9 aktualisiert habe sdb. Beim nächsten Booten sdaschlug es fehl mit

Warning: /lib/modules/4.8.13-1-ARCH/modules.devname not found
...
ERROR: device '/dev/sda2 not found. Skipping fsck.
...

Ich habe wieder in gebootet sdb, Kernel 4.8.13 neu installiert und festgestellt, dass ich sdawieder in booten konnte. Jetzt konnte ich jedoch nicht mehr in booten sdb, da der zum Öffnen von /dev/sdb1 erforderliche Verschlüsselungs-Hook nicht geladen werden konnte.

Ich habe das Problem gelöst, indem ich von in /dev/sdb1 chrootete sdaund 4.9 erneut installierte. Dadurch konnte ich in booten, sdbaber nicht in sda.

Jetzt stecke ich in einer Schleife fest, in der ich jedes Mal, wenn ich zwischen Installationen wechseln möchte, mein Kernel-Image neu erstellen muss. Es scheint, dass die beiden Kernel sich irgendwie gegenseitig behindern.

Hier sind die Schritte, die ich bei meiner Installation jedes Mal durchführe, sdawenn ich booten möchte sdb:

sudo cryptsetup open /dev/sdb1 cryptroot
sudo mount /dev/mapper/cryptroot /mnt/
sudo mount /dev/sda1 /mnt/boot/
chroot /mnt/
sudo pacman -U /var/cache/pacman/pkg/linux-4.8.13-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/nvidia-375.20-3-x86_64.pkg.tar.xz /var/cache/pacman/pkg/nvidia-utils-375.20-3-x86_64.pkg.tar.xz

Die Schritte, die ich durchlaufe, sdbwenn ich wechseln möchte, sdasind ähnlich, aber schlägt fehl mit

/lib/modules/4.8.13-1-ARCH is not a valid kernel module directory

Ich löse dies, indem ich einen symbolischen Link von /lib/modules/4.9-1-ARCH zu /lib/modules/4.8.13-1-ARCH erstelle.

Ich bin sicher, dass ich hier mindestens eine, wenn nicht sogar mehrere Dinge falsch mache (dieser symbolische Link scheint ein schrecklicher Hack zu sein). Es scheint, als würden meine Kernel irgendwie stören. Wie kann ich das beheben?

Antwort1

Es gelang mirHilfe holenin den Arch-Foren und wollte es hier teilen.

Obwohl jedes System in ein anderes initramfs-Image schrieb, überschrieben beide den gleichen Kernel.linuxDas in den Repos enthaltene Paket platziert das Image immer unter /boot/vmlinuz-linux. Es wurden einige Optionen besprochen:

  1. Installieren Sie ein anderes Mainline-Linux-Paket auf einem System.
  2. Erstellen Sie aus dem AUR ein benutzerdefiniertes Linux-Paket, das den Kernel umbenennt.
  3. Verwenden Sie für jedes System eine separate EFI-Partition.

Ich habe mich für 1 entschieden, da dies am einfachsten erschien. Die Installation auf einem System linux-ltsstatt linuxauf einem verhinderte, dass sich die Kernel gegenseitig störten. Die Booteinträge sehen jetzt so aus:

/boot/loader/entries/arch.conf

title   Arch Linux
linux   /vmlinuz-linux
initrd  /intel-ucode.img
initrd  /initramfs-linux.img
options root=/dev/sda2 rw

/boot/loader/entries/arch-here.conf

title   HERE Arch Linux
linux   /vmlinuz-linux-lts
initrd  /initramfs-linux-lts.img
options cryptdevice=/dev/sdb1:cryptroot root=/dev/mapper/cryptroot rw

nvidia-ltsBeachten Sie, dass Nvidia-Benutzer, die diesen Ansatz verwenden möchten, anstelle von installieren müssen nvidia.

verwandte Informationen