quelques mystères (pour moi...)

Le
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
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #26519408
Mauvais sujet qui ne donne aucune information sur le contenu du message.
Le 18/06/2019 à 10:06, François Patte a écrit :
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?

Parce que généralement la racine n'est pas montée en lisant fstab mais
avec le paramètre "root" passé à la ligne de commande du noyau spécifiée
dans grub.cfg. Ne pas oublier que fstab est sur la racine, il n'est donc
pas lisible avant que la racine soit montée (sauf si le démarrage
utilise un initramfs et si celui-ci contient une copie de 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?

Ça, c'est le vrai mystère car je ne connais pas Fedora mais logiquement
le script de mise à jour du noyau devrait générer grub.cfg en exécutant
grub2-mkconfig ou son wrapper update-grub2.
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.

Généralement, la racine est initialement montée en lecture seule (à
cause du paramètre "ro" dans la ligne de commande du noyau). Cela permet
de faire une vérification du système de fichiers racine avant de le
remonter en lecture-écriture [1]. Il se peut que le remontage en
lecture-écriture n'ait lieu que si la racine est définie dans /etc/fstab.
[1] Si la vérification du système de fichiers racine est faite dans
l'initramfs avant son montage, alors il n'est plus nécessaire de le
monter initialement en lecture seule.
Christophe PEREZ
Le #26519449
Le Tue, 18 Jun 2019 11:56:55 +0200, Pascal Hambourg a écrit :
Ça, c'est le vrai mystère car je ne connais pas Fedora mais logiquement
le script de mise à jour du noyau devrait générer grub.cfg en exécutant
grub2-mkconfig ou son wrapper update-grub2.

Je ne suis pas sûr d'avoir tout compris, mais déjà le fait d'avoir 2
partitions /boot me semble source d'erreurs de ce genre.
laurent144 Hors ligne
Le #26519479
Le mardi 18 Juin 2019 à 10:06 par François 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


Réponse rapide:

Bonjour, Je suis un particulier qui offre des prêts. Disposant d'un capital qui servira à octroyer des prêts entre particuliers à court et long terme allant de 5.000 à 500.000€ à toutes personnes sérieuses étant dans le réel besoins, le taux d'intérêt est de 2% l'an. J'octroie des prêts Financier , Prêt immobilier , Prêt à l'investissement, Prêt automobile , Prêt personnel . Je suis disponible à vous satisfaire en intervalle de 03 Jours en fonction de votre promptitude.

Mail:
Fran=c3=a7ois Patte
Le #26519495
Le 18/06/2019 à 11:56, Pascal Hambourg a écrit :
Mauvais sujet qui ne donne aucune information sur le contenu du message.
Le 18/06/2019 à 10:06, François Patte a écrit :


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?

Ça, c'est le vrai mystère car je ne connais pas Fedora mais logiquement
le script de mise à jour du noyau devrait générer grub.cfg en exécutant
grub2-mkconfig ou son wrapper update-grub2.

Chez fedora, on me dit que c'est grubby et non pas grub2-mkconfig qui
est utilisé.... Certains ajoutent que grubby est buggé...
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.

Généralement, la racine est initialement montée en lecture seule (à
cause du paramètre "ro" dans la ligne de commande du noyau). Cela permet
de faire une vérification du système de fichiers racine avant de le
remonter en lecture-écriture [1]. Il se peut que le remontage en
lecture-écriture n'ait lieu que si la racine est définie dans /etc/fstab.

Mais cela ajoute au mystère: pendant plusieurs mois (années?) mon fstab
ne mentionnait pas le vraie partition racine, mais une partition racine
désafectée et, qui plus est, erronée. Suffirait-il que "mount" voit "/"
dans fstab pour convertir le montage ro en montage rw sans plus se
préoccupé de ce qui est monté à la racine?
[1] Si la vérification du système de fichiers racine est faite dans
l'initramfs avant son montage, alors il n'est plus nécessaire de le
monter initialement en lecture seule.

Comment put-on savoir ça? le fichier initramfs est illisible
(humainement...)
--
François Patte
Université Paris Descartes
Fran=c3=a7ois Patte
Le #26519494
Le 18/06/2019 à 19:10, Christophe PEREZ a écrit :
Le Tue, 18 Jun 2019 11:56:55 +0200, Pascal Hambourg a écrit :
Ça, c'est le vrai mystère car je ne connais pas Fedora mais logiquement
le script de mise à jour du noyau devrait générer grub.cfg en exécutant
grub2-mkconfig ou son wrapper update-grub2.

Je ne suis pas sûr d'avoir tout compris, mais déjà le fait d'avoir 2
partitions /boot me semble source d'erreurs de ce genre.

Avoir une partition /boot est (était?) nécessaire si on utilise
(utilisait) lvm. Comment ne pas avoir plusieurs partitions /boot si on a
plusieurs systèmes d'exploitation sur une machine?
--
François Patte
Université Paris Descartes
Jo Engo
Le #26519497
Le Wed, 19 Jun 2019 11:26:09 +0200, François Patte a écrit :
Comment put-on savoir ça? le fichier initramfs est illisible
(humainement...)

Et avec un archiveur ?

--
Brèves sont pour les pauvres hommes les douceurs de la vie.
-+- Lucrèce (98-55 av. J.-C.), Livre III verset 912 -+-
Christophe PEREZ
Le #26519556
Le Wed, 19 Jun 2019 11:26:17 +0200, François Patte a écrit :
Comment ne pas avoir plusieurs partitions /boot si on a plusieurs
systèmes d'exploitation sur une machine?

Je ne sais pas comment répondre à cette question.
Il n'y a juste pas besoin de plusieurs partitions de boot, à mon humble
avis.
Alors comment n'en avoir qu'une ?
En n'en faisant pas plusieurs.
Pascal Hambourg
Le #26519564
Le 19/06/2019 à 11:26, François Patte a écrit :
Le 18/06/2019 à 19:10, Christophe PEREZ a écrit :
Je ne suis pas sûr d'avoir tout compris, mais déjà le fait d'avoir 2
partitions /boot me semble source d'erreurs de ce genre.


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.
Avoir une partition /boot est (était?) nécessaire si on utilise
(utilisait) lvm. Comment ne pas avoir plusieurs partitions /boot si on a
plusieurs systèmes d'exploitation sur une machine?

Il n'est pas nécessaire d'avoir une partition /boot séparée quand la
racine est dans un volume logique LVM car GRUB (1.9x ou 2.x) supporte
LVM. Ce n'était pas le cas de la version précédente GRUB legacy (0.9x).
En revanche 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. Les différents systèmes risquent
d'être incapable de distinguer quels noyaux appartiennent à l'un ou à
l'autre et d'écraser mutuellement leurs fichiers de noyaux, initramfs et
chargeurs d'amorçage.
Pascal Hambourg
Le #26519563
Le 19/06/2019 à 11:26, François Patte a écrit :
Mais cela ajoute au mystère: pendant plusieurs mois (années?) mon fstab
ne mentionnait pas le vraie partition racine, mais une partition racine
désafectée et, qui plus est, erronée. Suffirait-il que "mount" voit "/"
dans fstab pour convertir le montage ro en montage rw sans plus se
préoccupé de ce qui est monté à la racine?

Il me semble que oui.
[1] Si la vérification du système de fichiers racine est faite dans
l'initramfs avant son montage, alors il n'est plus nécessaire de le
monter initialement en lecture seule.

Comment put-on savoir ça? le fichier initramfs est illisible
(humainement...)

Avec un outil comme lsinitramfs, lsinitrd ou équivalent, on peut lister
le contenu d'un fichier initramfs et voir si des programmes *fsck* sont
inclus.
Christophe PEREZ
Le #26519702
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 ?
Publicité
Poster une réponse
Anonyme