Le 11/11/2024 à 15:12, ajh-valmer a écrit :
On Monday 11 November 2024 10:12:25 didier gaumet wrote:
1) Sans trop développer au sujet de mes avertissements du style "j'y
connais rien" :
Je propose un exemple qui vaut 10.000 mots.
Après un update-grub2, extrait ci-dessous d'une partition de boot dans
grub.cfg :
==================
$menuentry_id_option
'gnulinux-6.1.0-27-amd64-advanced-1bffe743-6ba6-4c1a-be28-5f097d151186'
... msdos2 --hint-baremetal=ahci1,msdos2 f181ce70-5727-46d4-9e17-b2f1f0481d74
... --no-floppy --fs-uuid --set=root ddc7151d-bce9-4276-a86e-25f8bab3dbc6
==================
On constate qu'on a trois UUID différents, Et Pourquoi ?
Si au démarrage je boote dans le menu grub sur cette partition,
le boot sera un échec garanti : Voilà ma question.
Bonne journée.
une entrée de grub.cfg équivalente (advanced=sous menu de l'entrée
principale) chez moi:
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option
'gnulinux-advanced-c258e556-11bb-45f8-b8c8-89e2f8bdd48a' {
menuentry 'Debian GNU/Linux, with Linux 6.1.0-27-amd64' --class
debian --class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux
-6.1.0-27-amd64-advanced-c258e556-11bb-45f8-b8c8-89e2f8bdd48a' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod
lzopio; fi
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root
a42afbac-0fa5-497c-a446-aeff8ec15446
echo 'Loading Linux 6.1.0-27-amd64 ...'
linux /vmlinuz-6.1.0-27-amd64
root=/dev/mapper/VG_SSD-LV_ROOT ro quiet splash
echo 'Loading initial ramdisk ...'
initrd /initrd.img-6.1.0-27-amd64
}
tu peux voir que dans mon cas les deux premiers UUID sont identiques et
le troisième (identifié part "set root"), est différent
les deux premiers UUID correspondent chez moi à /dev/dm-1 ce qui
correspond au volume chiffré (chez toi si ce n'est pas chiffré ce doit
être plus simple, ça doit correspondre, je suppose, à la partition racine)
- Le fait que tes deux premiers UUID soient différents pourrait par
exemple provenir d'un contexte scabreux chez toi (plusieurs distros
installées avec plusieurs grub installés, chacun faisant appel à
os-prober, le tout étant parfois un gros bordel). Si en plus tu as joué
avec des changements de disques dans les baies ou des
copies/déplacements de partitions, ça n'aide pas non plus.
Ces deux UUID me paraissent de nature purement informative, a priori,
donc pas de nature à empêcher un démarrage.
- le troisième UUID correspond à la partition sur laquelle se trouve le
/boot du système à démarrer (exemple: soit la partition /boot.soit la
partition /). Le fait que ça ne démarre plus me ferait aussi pencher
pour une intervention foireuse de os-prober dans un contexte
multi-distros avec chacune un grub
=> si tu veux avoir trois UUID identiques dans une entrée grub de ce
genre, je pense qu'il faut que ton contexte ne soit pas bancal au moment
de l'update-grub, et que tu n'aies pas de partition /boot séparée. Et
que tu n'aies pas un système chiffré.
Pour conclure sur une note (toute personnelle, d'autres auront un avis
différent et tout aussi digne de considération) qui te découragera
peut-être, le multi-boot entre Linux et Windows ou BSD, je trouve que ça
se gère sans trop de soucis, le multi-boot entre distros Linux ça peut
rapidement devenir un sac de noeuds avec os-prober (je crois qu'à partir
de Bookworm os-prober n'est plus appelé par défaut par update-grub
justement à cause de ça)
Rappel: tu peux savoir à quoi correspondent les UUID en regardant dans
/etc/fstab et en listant /dev/disk/by-uuid
