Problème de montage de partitions ext4 selon ancienneté du noyau (ou autre ?)

Version imprimable

29/04/2018, 16h36
Jipété

1 pièce(s) jointe(s)

Problème de montage de partitions ext4 selon ancienneté du noyau (ou autre ?)
Bonjour,

Gag : avec mes vieilles machines virtuelles Linux (disques formattés en ext4), je peux sans problème accéder à leurs disques virtuels (pour examiner un fichier par ex.) sans démarrer les machines : il me suffit de monter le fichier avec vdfuse puis les partoches qui s'y trouvent à coups de mount -o loop ... et tutti va bene.

Jusqu'à ce que je découvre que ça ne fonctionne plus avec les disques des machines récentes : le fichier se monte bien, mais les partoches qu'il contient, woualou, :aie:
Code:

1 2 3 $ dmesg [ 4118.774614] JBD2: Unrecognised features on journal [ 4118.774618] EXT4-fs (loop0): error loading journal
Je ne suis pas le seul à avoir eu ce genre de problème, mais on rencontre aussi pas mal de boulets sur le web, regardez :
le gars poste ce qu'un autre lui a demandé, et juste après il a trouvé la solution, il clôture le fil, mais le partage de l'info, zap ! :furax:

Pièce jointe 374106
source

J'ai donc comparé les fstab d'une vieille MV (Debian7, noyau 3.8) et d'une récente (Debian9, noyau 4.9) sans noter de différences significatives, alors que faire ?
Où chercher ?
Que chercher ?

Toutes les idées sont les bienvenues,
30/04/2018, 08h36
chrtophe

Quelque chose n'aurait pas changé dans ta config ? version différente de VirtualBox et donc format vdi légèrement différent et mal géré.
30/04/2018, 08h55
Jipété
Salut, chrtophe,

Citation:

Envoyé par chrtophe

Quelque chose n'aurait pas changé dans ta config ? version différente de VirtualBox et donc format vdi légèrement différent et mal géré.

Absolument pas !

La seule chose qui change entre les fichiers qui vont bien et ceux qui vont mal, c'est que ces derniers ont été créés avec une MV récente et donc un noyau récent et des utilitaires récents.

Pour preuve, si je crée un fichier de disque virtuel depuis une mv Debian7 je n'ai aucun problème à travailler avec depuis le host (Debian7 aussi), tout comme avec une mv récente (Debian9).
Mais si je détruis ses partitions depuis cette mv récente et les recrée à l'identique (en termes de taille, de type de fs, de label) alors la vieille mv tout comme le host ne peuvent plus y accéder.

En fait la différence est là :
Debian7
Code:

1 2 # mount -V mount from util-linux 2.20.1 (with libblkid and selinux support)
Debian9
Code:

1 2 # mount -V mount de util-linux 2.29.2 (libmount 2.29.2: selinux, btrfs, assert, debug)
Il y a peut-être une blague avec les options de montage, mais man mount n'en parle pas...
30/04/2018, 09h18
chrtophe

Si tu fais un fsck ça donne quoi ? (faire une copie avant au cas où).

Citation:

Envoyé par chrtophe

Si tu fais un fsck ça donne quoi ? (faire une copie avant au cas où).

Pas encore fait, par contre j'ai fait tourner dumpe2fs mountpoint/Partition1 sur les deux disques, je ne remonte que les différences significatives :
disque créé par debian7
Code:

1 2 3 4 5 Filesystem features: uninit_bg Fonctionalités du journal: (none) Taille du journal: 16M Longueur du journal: 4096 Séquence du journal: 0x00000005
disque créé par debian9
Code:

1 2 3 4 5 Filesystem features: 64bit metadata_csum Fonctionalités du journal: journal_64bit FEATURE_I4 Taille du journal: 32M Longueur du journal: 8192 Séquence du journal: 0x0000000a
Pas sûr que Taille, Longueur et Sequence du journal soient impactantes.

Par contre, on voit bien qu'il y a de grosses différences dans les fonctionnalités du journal : si ça se trouve, la blague est là.
Je retourne dans le man mount,:mrgreen:

Et pour info, les Filesystem features identiques, enlevées de mon rapport pour aller à l'essentiel : has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum

Citation:

Envoyé par chrtophe

Si tu fais un fsck ça donne quoi ? (faire une copie avant au cas où).

Ça donne que ça ne lui plaît pas du tout, ces nouvelles options :
Code:

1 2 3 4 5 # fsck /mountpoint/Partition1 fsck de util-linux 2.20.1 e2fsck 1.42.5 (29-Jul-2012) /mountpoint/Partition1 a une(des) fonctionnalité(s) non supportée(s) : metadata_csum e2fsck: Veuillez obtenir une version plus récente d'e2fsck !
Citation:

Envoyé par jipété

disque créé par debian9

Code:

Filesystem features: 64bit metadata_csum

Fait chichi et je sens que je suis bien coincé sur ce coup-là.

Car, mine de rien, en admettant que je change de host un jour pour avoir une belle machine hardware toute neuve avec un os de la dernière version et qu'à partir de là je crée des disques virtuels, ils seront inutilisables avec les vieilles machines virtuelles...

PS : rien ~~d'intéressant~~ d'utilisable dans le man mount.

30/04/2018, 11h20
mm_71

Citation:

ils seront inutilisables avec les vieilles machines virtuelles...

D'après ton message de 9:30 il semblerait que les vielles VM soient en 32 bits et les nouvelles en 64. Si j'ai raison ça ne peut pas le faire, il faudrait que tes nouvelles VM soient aussi des 32 bits.
30/04/2018, 11h31
Jipété

Yep !

Citation:

Envoyé par mm_71

D'après ton message de 9:30 il semblerait que les vieilles VM soient en 32 bits et les nouvelles en 64. Si j'ai raison ça ne peut pas le faire, il faudrait que tes nouvelles VM soient aussi des 32 bits.

:nono:
Les os sont bien en 32 (vi, j'ai toujours pas évolué, suis long à la détente...), ce qui s'affiche doit être du baratin interne au prog et, de toute façon, rien n'empêche un os 32 bits de travailler avec des données en 64, regarde mes diverses installations Lazarus en 32 bits et son Int64, je n'ai aucun souci. :P
30/04/2018, 12h39
chrtophe

Apperemment, le ext4 a un mode 32 ou 64 bits (je pense que c'est pour ses structures internes).

Tu as une ligne auto_64-bit_support = 1 dans mkfs.conf.

Si tu forces la valeur à 0, cela permettra à mon avis aux ext4 créées depuis un système récent de rester compatible avec d'anciennes versions.

A tester.
30/04/2018, 13h57
disedorgue

Bonjour,

A priori, si tu désactives l'option de checksum en 64 bits, ça devrait fonctionner, mais pour la désactiver, il faut que la partition soit propre (fsck).
Sinon, pour tes anciens systèmes, essaye de passer sur une version fsck 1.43 qui supporte le cksum 64 Bits.

Pour désactiver (bien sur depuis le système qui supporte) :

Code:

tune2fs -O ^metadata_csum /dev/<partoche>
30/04/2018, 14h31
Jipété

Yop !

Citation:

Envoyé par disedorgue

A priori, si tu désactives l'option de checksum en 64 bits, ça devrait fonctionner, mais pour la désactiver, il faut que la partition soit propre (fsck).

J'ai appelé tune2fs, le système m'a demandé d'office fsck, l'ai exécuté, ai rappelé tune2fs et bingo !
:plusser:

Grand merci à toi (et à tous les autres copains aussi),

EDIT
Il me semblait avoir répondu à ça :

Citation:

Envoyé par chrtophe

Tu as une ligne auto_64-bit_support = 1 dans mkfs.conf.

Fichier inexistant chez moi même après updatedb et locate, :aie:
30/04/2018, 15h13
chrtophe

Tu vas encore gueuler pour l'orthographe :
mke2fs.conf
30/04/2018, 18h16
Jipété

Citation:

Envoyé par chrtophe

Tu vas encore gueuler pour l'orthographe :
mke2fs.conf

J'ai rien dit j'ai rien dit, :mouarf:
Juste que je risquais pas de trouver, :ptdr:

Sinon, pas sûr qu'il y ait un rapport :

Citation:

Envoyé par auto_64-bit_support

Cette variable booléenne indique si mke2fs doit automatiquement ajouter la caractéristique « 64bit » si le nombre de blocs pour le système de fichiers nécessite l'activation de celle-ci. La caractéristique resize_inode est alors automatiquement désactivée, puisqu'elle ne gère pas les nombres de blocs sur 64 bits.

source

Autant taper directement là où ça fait mal et suivre la voie de disedorgue, avec un peu de lecture au passage (et plein de gens qui ont rencontré ce problème, il suffit de faire une recherche sur le mot metadata_csum).
10/10/2018, 18h37
Jipété

Bonsoir,

je remonte ce post car ce qu'écrivait l'ami disedorgue, en admettant qu'on arrive à le faire (lire + bas),

Citation:

Envoyé par disedorgue

A priori, si tu désactives l'option de checksum en 64 bits, ça devrait fonctionner, mais pour la désactiver, il faut que la partition soit propre (fsck).

Pour désactiver (bien sûr depuis le système qui supporte) :

Code:

tune2fs -O ^metadata_csum /dev/<partoche>

ne survit pas à un reboot : testé ce matin, à nouveau impossible de monter le disque virtuel dans un OS ancien... :aie:

Par ailleurs,

Citation:

Envoyé par chrtophe

Tu as une ligne auto_64-bit_support = 1 dans mkfs.conf.

Si tu forces la valeur à 0, cela permettra à mon avis aux ext4 créées depuis un système récent de rester compatible avec d'anciennes versions.

A tester.

J'ai testé, c'est pareil...

+++
Passons aux choses sérieuses : je me demande bien, aujourd'hui, comment j'ai pu écrire ça il y a presque six mois (et cocher :resolu:)

Citation:

Envoyé par Jipété

J'ai appelé tune2fs, le système m'a demandé d'office fsck, l'ai exécuté, ai rappelé tune2fs et bingo !

car j'ai bien constaté qu'il était impossible d'exécuter tune2fs sur un système monté, c'est clair, net et sans appel.

Et comme il ne sert à rien de booter en mode "single" car le FS sera monté, en RO, et le fsck ne pouvant alors pas enregistrer ses modifications, on tourne en rond, il n'y a plus qu'une solution, le Live-DVD.

Une fois le Live-DVD booté, attention à choisir un point de montage créé quelque part dans l'arborescence de l'OS du Live, car on a vite fait de se mélanger les pinceaux, l'arbo du Live et celle du disque monté se ressemblant beaucoup (normal, j'avais utilisé ce Live pour créer cette machine), et attention aussi à l'explorateur de fichiers pcManFM qui se prend grave les pieds dans le tapis, faut y aller à la ligne de commande, à l'ancienne, dans un terminal.

Disque virtuel non monté, j'ai donc fait tourner un fsck -f suivi du tune2fs de disedorgue, dans cette configuration ça l'a bien fait, ensuite, pour la persistance, j'ai monté le disque puis édité son /etc/mke2fs.conf (du disque virtuel ! Attention au chemin) pour supprimer cette option metadata_csum, ça a été du sport pour enregistrer le fichier (sous un autre nom dans un dossier temporaire, puis le mettre en place à coup de cp et de mv, ne me demandez pas pourquoi, là je passe des infos pour éviter à celui qui fera pareil un jour de galérer toute la journée), et au final, j'ai arrêté la machine, j'ai pu monter par script le disque dans le host (ce qui est le but initial), le démonter, éjecter le Live-DVD et redémarrer la machine virtuelle sur son disque, y modifier un fichier, l'arrêter à nouveau et re-test de montage du disque dans le host, vérif du fichier modifié c'est tout bon, allez hop, terminé.

Je referai des vérifs demain, ce soir je suis sur les rotules...
12/10/2018, 08h58
Jipété

Bonjour,

Citation:

Envoyé par Jipété

Je referai des vérifs demain, ce soir je suis sur les rotules...

Toutes les vérifications montrent que... tout va bien ! :ccool:

:resolu:

Maintenant, on est d'accord que ce n'est pas très prudent de supprimer une option d'une partoche ext4 récente juste pour pouvoir la lire depuis un OS ancien, et que donc je ne conseille pas de mettre en prod' cette manip', mais en cas de besoin, ça peut dépanner.
:coucou: