☰

Cómo compartir una partición de arranque EFI

tag-icon • tag-icon linux boot arch-linux uefi efi
Cómo compartir una partición de arranque EFI

Tengo dos instalaciones de Archlinux en un sistema EFI configurado con gummiboot. Uno está rooteado en /dev/sda2, el otro en /dev/sdb1. Ambos usan /dev/sda1, la partición del sistema EFI, como partición /boot, pero colocan sus imágenes del kernel en diferentes ubicaciones:

/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

Esto estuvo bien hasta que actualicé el kernel de 4.8.13 a 4.9 en sdb. La próxima vez que inicié sda, falló con

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

Reinicié de nuevo sdb, reinstalé el kernel 4.8.13 y descubrí que podía iniciar sdade nuevo. Sin embargo, ahora ya no podía iniciar sdb, ya que no pudo cargar el gancho de cifrado necesario para abrir /dev/sdb1.

Resolví esto haciendo chroot en /dev/sdb1 sdae instalando 4.9 nuevamente. Esto me permitió iniciar sdbpero no sda.

Ahora estoy atrapado en un bucle en el que necesito reconstruir la imagen de mi kernel cada vez que quiero cambiar entre instalaciones. Parece que los dos núcleos están interfiriendo de alguna manera.

Estos son los pasos que sigo en mi sdainstalación cada vez que quiero iniciar 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

Los pasos que sigo sdbcuando quiero pasar sdason similares, pero fallan con

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

Resuelvo esto vinculando simbólicamente /lib/modules/4.9-1-ARCH a /lib/modules/4.8.13-1-ARCH.

Estoy seguro de que estoy haciendo al menos una, si no muchas, cosas mal aquí (ese enlace simbólico parece un truco horrible). Parece que mis núcleos están interfiriendo de alguna manera. ¿Cómo puedo arreglar esto?

Respuesta1

Logréconseguir un poco de ayudaen los foros de Arch y quería compartirlo aquí.

Aunque cada sistema escribía en una imagen initramfs diferente, ambos sobrescribían el mismo núcleo. ElLinuxEl paquete incluido en los repositorios siempre coloca la imagen en /boot/vmlinuz-linux. Se discutieron algunas opciones:

  1. Instale un paquete de Linux principal diferente en un sistema.
  2. Cree un paquete de Linux personalizado a partir de AUR que cambie el nombre del kernel.
  3. Utilice una partición EFI separada para cada sistema.

Elegí 1 porque me pareció el más sencillo. La instalación linux-ltsen lugar de linuxen un sistema evitó que los núcleos interfirieran. Las entradas de inicio ahora se ven así:

/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

Tenga en cuenta que los usuarios de nvidia que quieran adoptar este enfoque deberán instalar nvidia-ltsen lugar de nvidia.

información relacionada