Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

quelques mystères (pour moi...)

12 réponses
Avatar
Fran=c3=a7ois Patte
Bonjour,

Je viens vous soumettre quelques points qui me paraissent mystérieux et
sur lesquels j'aimerais avoir des explications.

Du temps où j'avais 2 systèmes d'exploitation sur ma machine, j'avais
partitionné mes disques avec 2 racines et 2 /boot pour chacun des
systèmes qui montaient les mêmes partition /home et /opt.

J'ai abandonné l'un des deux systèmes et conservé le même
partitionnement en m'en servant pour les changements de version du
système (intallant la nouvelle version sur une des partitions tout en
conservant l'ancienne version sur l'autre).

Puis vint le moment où le système mis au point la possibilité de changer
de version avec le logiciel de gestion des paquets et je n'utilise plus
qu'un seul des deux partitionnements.

La distribution est fedora et mon système utilise le raid1 logiciel et lvm.

J'ai donc 4 partitions:
/boot (A) et /dev/mapper/systemA montée sur /
/boot (B) et /dev/mapper/systemB inutilisées

Il y a quelques mois, les mises à jour du noyau ont changé: le script
d'intallation du noyau s'est mis à écrire un fichier grub.cfg utilisant
comme partition racine, non pas /dev/mapper/systemA mais
/dev/mapper/systemB et, évidemment ça ne marchait pas....

Je rétablissait un "bon" grub.cfg en utilisant grub2-mkconfig qui, lui
écrivait la bonne configuration.

Voilà pour les antécédants... J'ai fini par trouvé ce qui clochait en
jetant un œil dans le fichier fstab où trainait la suivante:
/dev/mapper/sytemB / ext4 noatime,discard,errors=remount-ro 1 1

J'en ai conclu que le script de mise à jour des noyaux jetait aussi un
œil dans fstab pour écrire le fichier grub.cfg mais c'est là que
commencent les mystères pour moi:

mystère 1: Pourquoi la partition /dev/mapper/sytemB n'était-elle jamais
montée bien que figurant dans le fichier fstab?

mystère 2: Pourquoi, une fois le bon fichier grub.cfg réécrit avec la
bonne partition racine (/dev/mapper/sytemA), celle-ci était montée bien
que ne figurant pas dans le fichier fstab?

mystère 3: Pourquoi grub2-mkconfig était-il capable de savoir qu'elle
était la bonne partition racine et pas le script de mise à jour des noyaux?

mystère 4: Quand j'ai découvert la ligne suspecte pointant systemB comme
racine dans le fichier fstab, j'ai commenté la ligne et redémarré la
machine: la partition systemA a été montée (bien que ne figurant
toujours pas dans fstab) mais en lecture seule.... (ce qui n'est pas
très pratique pour rétablir fstab! mais, enfin, on y arrive!). J'ai
alors ajouté la ligne:
/dev/mapper/sytemA / ext4 noatime,discard,errors=remount-ro 1 1
et tout est rentré dans l'ordre: la partition racine a été montée en
lecture-écriture.

Voilà. Si quelqu'un a des explications, je suis preneur (en espérant les
comprendre!).

Merci et bonne journée.

--
François Patte
Université Paris Descartes

2 réponses

1 2
Avatar
Fran=c3=a7ois Patte
Le 21/06/2019 à 14:42, Christophe PEREZ a écrit :
Le Thu, 20 Jun 2019 01:09:06 +0200, Pascal Hambourg a écrit :
Pourquoi ? Si une seule (et la bonne) des deux partitions est montée sur
/boot, il n'y a aucune raison que l'autre soit prise en compte d'une
façon ou d'une autre.

Mais dans le cas présent, je ne suis pas du tout persuadé que
l'utilisateur sache justement quelle partition boot est utilisée dans
chaque cas. La preuve en est, à mes yeux, l'existence d'une ligne dans le
fstab d'une installation, qui correspond à l'autre.
J'ai le sentiment que la même confusion existe au niveau du boot.
Où est son grub ? à quel boot fait-il référence ?

Dans mon cas, il n'y a pas d'ambiguïté: /boot est inscrite dans le
fstab: sa grappe raid1 est repérée par son uuid.
Comme j'ai détruit la deuxième installation, je ne peut pas vérifier que
la situation était symétrique pour l'autre système...
--
François Patte
Université Paris Descartes
Avatar
Pascal Hambourg
Le 20/06/2019 à 01:09, Pascal Hambourg a écrit :
Le 19/06/2019 à 11:26, François Patte a écrit :
Comment ne pas avoir plusieurs partitions /boot si on a
plusieurs systèmes d'exploitation sur une machine?


(...)
c'est une très mauvaise idée de partager la même partition
/boot entre plusieurs installations dans la structure traditionnelle où
les fichiers images des noyaux, initramfs et du chargeur d'amorçage sont
installés directement dans /boot.

Toutefois il est possible de rassembler plusieurs /boot dans une même
partition avec des astuces à base de liens symboliques, "bind mounts",
sous-volumes Btrfs... Mais je ne sais pas si la génération automatique
de configuration de GRUB grub.cfg avec grub-mkconfig/update-grub
fonctionne correctement dans ces circonstances.
1 2