GRUB Dual-Boot Autre OS non-détecté (LUKS - LVM) Le sujet est résolu

[dezix]

Bonjour,

La situation sortant du plan classique, je plante le décor



J'ai 2 systèmes ADMIN et OFFICE installés sur la même machine
comme décrit dans PC : Sécurité : Définir une stratégie globale


Le partitionnement de base étant :

Code : Tout sélectionner

sda                                                                                                       
├─sda1		vfat			EFI
├─sda2		ext2			ADM_BOOT
├─sda3		crypto_LUKS		ADM_SYSTEM
├─sda4		ext2			OFF_BOOT
├─sda5		crypto_LUKS		OFF_SYSTEM
└─sda6		crypto_LUKS		DATA              

Pour ADMIN,
j'ai tenté de suivre les recommandations de l'ANSSI,
avec :

Code : Tout sélectionner

sda
├─sda1     /boot/efi
├─sda2     /boot    
└─sda3              
  └─sda3_crypt      
    ├─vg_adm-racine 
    ├─vg_adm-home   
    ├─vg_adm-usr    
    ├─vg_adm-swap   
    ├─vg_adm-opt    
    ├─vg_adm-srv    
    ├─vg_adm-tmp    
    ├─vg_adm-var    
    ├─vg_adm-varlog 
    └─vg_adm-vartmp 

Pour OFFICE,
j'ai opté pour une partition plus simple :

Code : Tout sélectionner

sda
├─sda1     /boot/efi
├─sda4     /boot
└─sda5
  └─sda5_crypt      
    ├─vg_off-racine 
    ├─vg_off-home   
    └─vg_off-swap

Notez que la partition EFI (sda1) est partagée par les 2 systèmes


Ce qui donne globalement :

Code : Tout sélectionner

# lsblk -f
NAME                FSTYPE      FSVER    LABEL      UUID                                   FSAVAIL FSUSE% MOUNTPOINT
sda                                                                                                       
├─sda1              vfat        FAT32               8189-3624                               181,8M     3% /boot/efi
├─sda2              ext2        1.0      ADM_BOOT   d3d56015-6272-491a-93e1-ce060df543ca                  
├─sda3              crypto_LUKS 2                   966aa6ce-980e-433e-9207-15e2b6698fa4                  
│ └─sda3_crypt      LVM2_member LVM2 001            704SfP-eCV8-t09W-BsuQ-zMSp-QZvx-QrcKWK                
│   ├─vg_adm-racine ext4        1.0      ADM_RACINE 5e6c5a02-8076-4b95-9f87-ba2ab64091a0                  
│   ├─vg_adm-home   ext4        1.0      ADM_HOME   9a97fe0a-be21-49b1-90a4-f9d61579c6ba                  
│   ├─vg_adm-usr    ext4        1.0      ADM_USR    cd59d37a-c1f8-4f8b-8a72-aaea8e5a85c2                  
│   ├─vg_adm-swap   swap        1                   37c55711-9bbc-49f3-88a6-8c9233029e8a                  
│   ├─vg_adm-opt    ext4        1.0      ADM_OPT    2c90fe90-eb69-44e4-b819-6f0c47383333                  
│   ├─vg_adm-srv    ext4        1.0      ADM_SRV    c62eead4-ded5-4f4a-b483-7a4099611946                  
│   ├─vg_adm-tmp    ext4        1.0      ADM_TMP    580387c8-196d-4d86-8df0-05d66acaa96e                  
│   ├─vg_adm-var    ext4        1.0      ADM_VAR    6eb7e69e-0349-44ba-a485-b1e1f04edac8                  
│   ├─vg_adm-varlog ext4        1.0      ADM_VARLOG 4a3c3e8e-52b2-4a55-90a7-b5e425c2fee3                  
│   └─vg_adm-vartmp ext4        1.0      ADM_VARTMP a4ccd8fe-9266-4bcf-a3aa-db9a28c5c10d                  
├─sda4              ext2        1.0      OFF_BOOT   a7dbfc8b-93bc-4b47-bb36-af9f8c7cd688    192,4M    25% /boot
├─sda5              crypto_LUKS 2                   1198c197-086d-4f33-8e4f-8877bbbff529                  
│ └─sda5_crypt      LVM2_member LVM2 001            eEaMr2-BqXF-9MAo-yyQj-tFAG-Z5qF-spRs9I                
│   ├─vg_off-racine ext4        1.0      OFF_RACINE ecd4f807-250e-4240-b2d2-0fe7c141885d     20,8G    19% /
│   ├─vg_off-home   ext4        1.0      OFF_HOME   d93e1148-4dd6-4796-b2d1-da83b2c23890      4,7G    43% /home
│   └─vg_off-swap   swap        1                   27de1a51-4052-4780-b7f6-ae9f4ab029b2                  [SWAP]
└─sda6              crypto_LUKS 2                   f94a95fd-7e9c-4c0a-94ab-7f2bfb1efce8                  
  └─sda6_crypt      ext4        1.0      DATA       4a42e559-5abe-4159-b4a1-68ead0cc92f9     84,6G    37% /home/data

Depuis ADMIN (debian stable) pas de problème,
update-grub détecte correctement le 2d OS.


Problème

OFFICE (debian testing)
ne détecte pas ADMIN lors de : update-grub



Voici les tests que j'ai pu faire depuis OFFICE :

Code : Tout sélectionner

# os-prober
(ne renvoie rien)

# linux-boot-prober /dev/sda1
(ne renvoie rien)

# linux-boot-prober /dev/sda2
/dev/sda2:/dev/sda2::/vmlinuz-4.19.0-13-amd64:/initrd.img-4.19.0-13-amd64:root=/dev/sda2
/dev/sda2:/dev/sda2::/vmlinuz-4.19.0-14-amd64:/initrd.img-4.19.0-14-amd64:root=/dev/sda2

# linux-boot-prober /dev/sda3
(ne renvoie rien => normal le volume est chiffré)

Ouverture du volume chiffré portant ADMIN

Code : Tout sélectionner

# cryptsetup luksOpen /dev/sda3 sda3_crypt


# os-prober
ne renvoie toujours rien

mais,

# linux-boot-prober /dev/mapper/vg_adm-racine

/dev/mapper/vg_adm-racine:/dev/sda2:Debian GNU/Linux:/boot/vmlinuz-4.19.0-14-amd64:/boot/initrd.img-4.19.0-14-amd64:root=/dev/mapper/vg_adm-racine ro quiet
/dev/mapper/vg_adm-racine:/dev/sda2:Debian GNU/Linux, avec Linux 4.19.0-14-amd64:/boot/vmlinuz-4.19.0-14-amd64:/boot/initrd.img-4.19.0-14-amd64:root=/dev/mapper/vg_adm-racine ro quiet
/dev/mapper/vg_adm-racine:/dev/sda2:Debian GNU/Linux, with Linux 4.19.0-14-amd64 (recovery mode):/boot/vmlinuz-4.19.0-14-amd64:/boot/initrd.img-4.19.0-14-amd64:root=/dev/mapper/vg_adm-racine ro single
/dev/mapper/vg_adm-racine:/dev/sda2:Debian GNU/Linux, avec Linux 4.19.0-13-amd64:/boot/vmlinuz-4.19.0-13-amd64:/boot/initrd.img-4.19.0-13-amd64:root=/dev/mapper/vg_adm-racine ro quiet
/dev/mapper/vg_adm-racine:/dev/sda2:Debian GNU/Linux, with Linux 4.19.0-13-amd64 (recovery mode):/boot/vmlinuz-4.19.0-13-amd64:/boot/initrd.img-4.19.0-13-amd64:root=/dev/mapper/vg_adm-racine ro single
/dev/mapper/vg_adm-racine:/dev/sda2:Debian GNU/Linux, with Linux 4.19.0-13-amd64 (sur /dev/mapper/vg_off-racine):/boot/vmlinuz-4.19.0-13-amd64:/boot/initrd.img-4.19.0-13-amd64:root=/dev/mapper/vg_off-racine ro quiet
/dev/mapper/vg_adm-racine:/dev/sda2:Debian GNU/Linux, with Linux 4.19.0-13-amd64 (recovery mode) (sur /dev/mapper/vg_off-racine):/boot/vmlinuz-4.19.0-13-amd64:/boot/initrd.img-4.19.0-13-amd64:root=/dev/mapper/vg_off-racine ro single

et

Code : Tout sélectionner

# update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.10.0-6-amd64
Found initrd image: /boot/initrd.img-5.10.0-6-amd64
Found linux image: /boot/vmlinuz-5.10.0-5-amd64
Found initrd image: /boot/initrd.img-5.10.0-5-amd64
Found linux image: /boot/vmlinuz-4.19.0-13-amd64
Found initrd image: /boot/initrd.img-4.19.0-13-amd64
Adding boot menu entry for EFI firmware configuration
done

ne trouve que les images du système OFFICE et le firmware UEFI de la carte-mère.

Code : Tout sélectionner

# apt list linux-image-* | grep install
linux-image-4.19.0-13-amd64/now 4.19.160-2 amd64  [installé, local]
linux-image-5.10.0-5-amd64/now 5.10.26-1 amd64  [installé, local]
linux-image-5.10.0-6-amd64/testing,unstable,now 5.10.28-1 amd64  [installé, automatique]
linux-image-amd64/testing,unstable,now 5.10.28-1 amd64  [installé]

Au niveau de grub j'ai la même installation :

Code : Tout sélectionner

# apt list *grub* | grep install

grub-common/testing,unstable,now 2.04-17 amd64  [installé]
grub-efi-amd64-bin/testing,unstable,now 2.04-17 amd64  [installé, automatique]
grub-efi-amd64-signed/testing,unstable,now 1+2.04+17 amd64  [installé]
grub-efi-amd64/testing,unstable,now 2.04-17 amd64  [installé]
grub2-common/testing,unstable,now 2.04-17 amd64  [installé, automatique]

que sur une installation de test préalable
qui fonctionne parfaitement avec 2 systèmes stables
(le système "ADMIN" ayant un partitionnement nettement moins fractionné => racine/home/swap)



Pour info supplémentaire :

OFFICE est en testing car c'est la distribution que j'utilisais déjà sur cette même machine.


Ma première intention (et tentative) était de "simplement" créer les volumes nécessaires pour ce second système
et d'y restaurer les dernières sauvegardes (partclone) de mon ancien système.

Comme après ce "clonage" j'ai rencontré ce problème de GRUB,
j'ai mis cela sur le compte de ma technique de clonage.

Du coup,
j'ai supprimé les volumes de ce système cloné qui fonctionnait,
et
je suis reparti sur une installation neuve "classique" en stable,
avec ensuite upgrade vers testing pour obtenir le système actuel.

Ce qui m'a permis de repartir sur une "page blanche" (installation plus légère)
et
de me rendre compte que le problème de "GRUB" est ailleurs


... Mais OÙ ?

Merci.

[PascalHambourg]

Je soupçonne que c'est à cause de /usr séparé, en conjonction avec la fusion de /lib dans /usr/lib. os-prober cherche la présence de /lib/ld*.so* mais celui-ci est dans /usr/lib qui est séparé, donc il ne le trouvera pas s'il n'est pas monté.

Essaie os-prober après avoir monté /dev/mapper/vg_adm-racine sur /mnt et /dev/mapper/vg_adm-usr sur /mnt/usr.
Si ça fonctionne, tu peux contourner le problème de deux façons :
- en créant un fichier /etc/lsb-release qui est utilisé par une autre méthode de détection d'os-prober. Ce fichier doit contenir des champs comme l'exemple ci-dessous, qui conditionnent l'affichage dans GRUB :

Code : Tout sélectionner

DISTRIB_ID=xxx
DISTRIB_DESCRIPTION=xxx
DISTRIB_RELEASE=xxx
DISTRIB_CODENAME=xxx

Pour les valeurs, tu peux prendre celles affichées par

Code : Tout sélectionner

lsb_release -a

- ou en créant un fichier /usr/lib/ld.so bidon dans /dev/mapper/vg_adm-racine lorsque le volume usr n'est pas monté.

Evidemment il faudra que le volume chiffré soit ouvert et les volumes logiques actifs pour que l'OS soit détectable.

Deux questions :
1) Pourquoi avoir séparé /usr ? Pour le monter en lecture seule ?
2) Pourquoi vouloir que l'OS office détecte l'OS admin ? De toute façon il ne peut y avoir qu'un seul GRUB puisque les deux Debian l'installent au même endroit dans la partition EFI /boot/efi/EFI/debian et l'enregistrent sous le même nom "debian" dans les variables de boot EFI (ce qui est un problème pour avoir plusieurs installations de Debian indépendantes sur la même machine).

[dezix]

Je soupçonne que c'est à cause de /usr séparé

... Net et sans bavure !


Le test

Code : Tout sélectionner

# mount /dev/mapper/vg_adm-racine /mnt
# mount /dev/mapper/vg_adm-usr /mnt/usr

# os-prober
/dev/mapper/vg_adm-racine:Debian GNU/Linux 10 (buster):Debian:linux

La configuration

Je le précise pour les autres lecteurs car j'ai fait la bourde,
/etc/release => c'est sur le système à détecter (ici ADMIN) et pas sur celui qui détecte... avec os-prober


Donc depuis OFFICE ça donne :

Code : Tout sélectionner

# cryptsetup luksOpen /dev/sda3 sda3_crypt
Saisissez la phrase secrète pour /dev/sda3 : 

# mount /dev/mapper/vg_adm-racine /mnt

# vim /mnt/etc/lsb-release

=> édition avec :

DISTRIB_ID=Debian
DISTRIB_DESCRIPTION=Debian GNU/Linux 10 (buster)
DISTRIB_RELEASE=10
DISTRIB_CODENAME=buster



# os-prober
/dev/mapper/vg_adm-racine:Debian GNU/Linux 10 (buster) (10):Debian:linux

Après quoi,

Code : Tout sélectionner

# update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.10.0-6-amd64
Found initrd image: /boot/initrd.img-5.10.0-6-amd64
Found linux image: /boot/vmlinuz-5.10.0-5-amd64
Found initrd image: /boot/initrd.img-5.10.0-5-amd64
Found linux image: /boot/vmlinuz-4.19.0-13-amd64
Found initrd image: /boot/initrd.img-4.19.0-13-amd64
Found Debian GNU/Linux 10 (buster) (10) on /dev/mapper/vg_adm-racine

BINGO!

et enfin

Code : Tout sélectionner

# grub-install /dev/sda
Installation pour la plate-forme x86_64-efi.
Installation terminée, sans erreur.

Redémarrage du PC...

Tout fonctionne correctement! Merci!

Pourquoi avoir séparé /usr ? Pour le monter en lecture seule ?

Effectivement, c'est pour préciser l'option de montage,
ANSSI ne va pas jusque là et recommande "simplement" nodev

Pourquoi vouloir que l'OS office détecte l'OS admin ?

Parce que sur le fixe,
Office est en testing et donc les MàJ de linux-image-* vont avoir lieu plus souvent et pas synchronisées avec Admin en stable.

Sur le portable (second poste) je vais installer 2x stable, ça sera plus simple à gérer.

Et puis j'aime bien avoir le système par défaut en tête de liste
(c'est pas très rationnel.. mais bon)

[PascalHambourg]

ANSSI ne va pas jusque là et recommande "simplement" nodev

Je n'ai jamais bien compris l'intérêt de monter en nodev les systèmes de fichiers que seul root peut monter et écrire.
Ceci dit, à ce compte-là autant monter toute la racine en nodev puisque tous les fichiers spéciaux de périphériques sont censés être contenus dans /dev qui est un tmpfs séparé monté par l'initramfs avant le démarrage de l'init. Du coup plus besoin de séparer /usr.

[dezix]

Ceci dit, à ce compte-là autant monter toute la racine en nodev puisque tous les fichiers spéciaux de périphériques sont censés être contenus dans /dev qui est un tmpfs séparé monté par l'initramfs avant le démarrage de l'init. Du coup plus besoin de séparer /usr.

Oui, c'est plus simple ... je vais faire ça à partir de maintenant.

C'est d'autant plus intéressant, si on est limité au niveau de l'espace,
ça fait économiser une "queue" de volume.