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!).
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.
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.
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 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.
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.
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
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:
Le mardi 18 Juin 2019 à 10:06 par 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
Réponse rapide: denisrenebordet@gmail.com
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: denisrenebordet@gmail.com
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 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
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...)
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 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
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?
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 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 -+-
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 -+-
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 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.
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.
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 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.
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.
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 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.
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.
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 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 ?
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 ?
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 ?
