2 votes

Comment partager une partition de démarrage EFI

J'ai deux installations Archlinux sur un système EFI configuré avec gummiboot. L'une est enracinée sur /dev/sda2, l'autre sur /dev/sdb1. Les deux utilisent /dev/sda1, la partition système EFI, comme partition /boot, mais placent leurs images de noyau à des endroits différents :

/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

Tout allait bien jusqu'à ce que je mette à jour le noyau de 4.8.13 à 4.9 sur sdb . La prochaine fois que j'ai démarré dans sda il a échoué avec

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

J'ai redémarré dans sdb j'ai réinstallé le noyau 4.8.13, et j'ai trouvé que je pouvais démarrer dans sda à nouveau. Cependant, je ne pouvais plus démarrer dans sdb car il n'a pas réussi à charger le hook d'encryptage nécessaire pour ouvrir /dev/sdb1.

J'ai résolu ce problème en accédant à /dev/sdb1 à partir de sda et en installant à nouveau la 4.9. Cela m'a permis de démarrer dans sdb mais pas sda .

Maintenant, je suis coincé dans une boucle où je dois reconstruire mon image de noyau chaque fois que je veux passer d'une installation à l'autre. Il semble que les deux noyaux interfèrent d'une manière ou d'une autre.

Voici les étapes que j'ai suivies sur mon sda installer à chaque fois que je veux démarrer dans 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

Les étapes que je passe sur sdb quand je veux passer à sda sont similaires, mais échouent avec

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

Je résous ce problème en établissant un lien symbolique entre /lib/modules/4.9-1-ARCH et /lib/modules/4.8.13-1-ARCH.

Je suis sûr que je fais au moins une, sinon plusieurs choses de travers ici (ce lien symbolique semble être un horrible hack). Il semble que mes noyaux interfèrent d'une manière ou d'une autre. Comment puis-je corriger cela ?

1voto

Robin Charlton Points 180

J'ai réussi à obtenir de l'aide sur les forums d'Arch et je voulais le partager ici.

Bien que chaque système écrivait sur une image initramfs différente, les deux écrasaient le même noyau. Le site linux inclus dans les dépôts place toujours l'image dans /boot/vmlinuz-linux. Quelques options ont été discutées :

  1. Installer un paquetage linux différent sur un système.
  2. Construire un paquet linux personnalisé à partir de l'AUR qui renomme le noyau.
  3. Utilisez une partition EFI séparée pour chaque système.

J'ai choisi la première, car elle semblait la plus simple. Installation de linux-lts au lieu de linux sur un système a empêché les noyaux d'interférer. Les entrées de démarrage ressemblent maintenant à ceci :

/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

Notez que les utilisateurs de nvidia qui veulent adopter cette approche devront installer nvidia-lts au lieu de nvidia .

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X