Como compartilhar uma partição de inicialização EFI

1

Eu tenho duas instalações do Archlinux em um sistema EFI configurado com o gummiboot. Um está enraizado em / dev / sda2, o outro em / dev / sdb1. Ambos usam / dev / sda1, a partição do sistema EFI, como sua partição / boot, mas colocam suas imagens do kernel em locais diferentes:

/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

Isso foi bom até que eu atualizei o kernel de 4.8.13 para 4.9 em sdb . A próxima vez que eu iniciei em sda , ele falhou com

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

Eu iniciei de volta em sdb , reinstalei o kernel 4.8.13 e descobri que eu poderia inicializar em sda novamente. No entanto, agora não consegui mais inicializar em sdb , pois ele não conseguiu carregar o gancho de criptografia necessário para abrir / dev / sdb1.

Eu resolvi isso fazendo o cromato em / dev / sdb1 de sda e instalando 4.9 novamente. Isso me permitiu inicializar em sdb , mas não em sda .

Agora estou preso em um loop onde preciso reconstruir minha imagem do kernel toda vez que quiser alternar entre as instalações. Parece que os dois kernels estão interferindo de alguma forma.

Aqui estão os passos que passo no meu sda install toda vez que eu quero inicializar em 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

As etapas que passo em sdb quando quero passar para sda são semelhantes, mas falha com

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

Eu resolvo isso através de symlinking /lib/modules/4.9-1-ARCH para /lib/modules/4.8.13-1-ARCH.

Tenho certeza de que estou fazendo pelo menos uma, se não muitas coisas erradas aqui (esse link simbólico parece um hack horrível). Parece que meus grãos estão interferindo de alguma forma. Como posso consertar isso?

    
por rcorre 02.02.2017 / 15:48

1 resposta

0

Eu consegui obter ajuda nos fóruns do Arch e queria compartilhá-lo aqui.

Embora cada sistema estivesse gravando em uma imagem initramfs diferente, ambos estavam sobrescrevendo o mesmo kernel. O pacote linux incluído nos repositórios sempre coloca a imagem em / boot / vmlinuz-linux. Houve algumas opções discutidas:

  1. Instale um pacote Linux de linha principal diferente em um sistema.
  2. Crie um pacote linux personalizado a partir do AUR que renomeia o kernel.
  3. Use uma partição EFI separada para cada sistema.

Eu fui com 1, como parecia o mais simples. A instalação de linux-lts em vez de linux em um sistema impediu que os kernels interferissem. As entradas de inicialização agora são assim:

/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

Observe que os usuários da nvidia que quiserem usar essa abordagem precisarão instalar nvidia-lts em vez de nvidia .

    
por 06.02.2017 / 00:28