Disque sans méta-données

Le Mon, 23 Nov 2015 22:50:32 +0100
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a écrit :

Nicolas George a écrit :
> Yliur , dans le message <20151123222204.7eebfc09@free.fr>, a
> écrit :
>> Type d'étiquette de disque : gpt
>> Type d'étiquette de disque : dos
>
> C'est peut-être ça la différence la plus importante.

C'est un peu court. Que je sache, les méta-données du système de
fichiers sont indépendantes du format de table de partition.

J'espère ne pas avoir employé de mauvais termes : quand j'ai parlé de
"méta-données" je ne voulais dire rien de plus que ce que j'ai écrit
dans mon message initial (y compris le fait que le système de fichiers
(ext4) ne soit pas découvert tout seul par mount).

Curieusement parted semble s'apercevoir que la partition est en ext4
mais mount ne le devine pas tout seul.

Le Mon, 23 Nov 2015 23:27:50 +0100
Ascadix <ascadix.ng@free.fr> a écrit :

Pascal Hambourg a exprimé avec précision :
> Nicolas George a écrit :
>> Yliur , dans le message <20151123222204.7eebfc09@free.fr>, a
>> écrit :
>>> Type d'étiquette de disque : gpt
>>> Type d'étiquette de disque : dos
>>
>> C'est peut-être ça la différence la plus importante.
>
> C'est un peu court. Que je sache, les méta-données du système de
> fichiers sont indépendantes du format de table de partition.

Si on part sur l'idée que le ok est en GPT, et le ko en MBR, on peut
se demander si il n'y aurait pas eu utilisation sur le PC d'un soft X
"ancien" gerne partitionneur ou truc du même acabit pas sympa qui
aurait mal tripatouillé la partition sur le DD MBR mais n'a p'tet pas
touché la partition sur le DD GPT car il aurait buté sur la pseudo
table MBR de protection du GPT ?

Mais c'est un peu tiré par les cheveux.

Je n'ai pas souvenir d'avoir fait un truc particulièrement tordu
récemment sur ces disques.

Le 23 Nov 2015 21:37:52 GMT
Nicolas George <nicolas$george@salle-s.org> a écrit :

Yliur , dans le message <20151123222204.7eebfc09@free.fr>, a écrit :
> Type d'étiquette de disque : gpt
> Type d'étiquette de disque : dos

C'est peut-être ça la différence la plus importante.

Est-ce que c'est indépendant des uuid ? Par exemple si je fais
ls -al /dev/disk/by-uuid

j'ai des liens symboliques dont aucun ne pointe sur /dev/sdd1 : le
disque semble ne vraiment plus avoir d'uuid. Et comme avant il était
monté par son uuid dans fstab c'est sûr qu'il en avait un.

Comment ces uuid sont-ils générés ? Est-ce que c'est possible
qu'une partition n'en ait pas en temps normal ?

Le Tue, 24 Nov 2015 00:14:29 +0100
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a écrit :

Yliur a écrit :
>
> Curieusement parted semble s'apercevoir que la partition est en ext4
> mais mount ne le devine pas tout seul.

A ce propos, le message de mount n'est pas très clair : "plus de
systèmes de fichiers ont été trouvés". Plus que quoi ? Ça ne sonne pas
très français, je soupçonne une traduction approximative. Tu pourrais
relancer la commande en la préfixant avec LANC=C pour afficher le
message en anglais.

C'est pareil en anglais : on dirait qu'il en a trouvé plusieurs ou plus
que prévu (?) .

mount: /dev/sdd1: more filesystems detected. This should not happen,
use -t <type> to explicitly specify the filesystem type or
use wipefs(8) to clean up the device.

Et éventuellement exécuter la commande wipefs comme suggéré ensuite,
mais en lecture seule, pour identifier les métadonnées présentes sur
la partition.

Sur le disque qui marche et sa partition :

# wipefs /dev/sdc
offset type
----------------------------------------------------------------
0x200 gpt [partition table]

0x3fc00 zfs_member [raid]

]# wipefs /dev/sdc1
offset type
----------------------------------------------------------------
0x438 ext4 [filesystem]
UUID: d401716c-deb2-4ba4-9c76-2944d1e78d4b


Sur celui qui est bizarre et sa partition :

# wipefs /dev/sdd
offset type
----------------------------------------------------------------
0x1fe dos [partition table]

0x3fc00 zfs_member [raid]
LABEL: ddzfs
UUID: 15481972323858100681


# wipefs /dev/sdd1
offset type
----------------------------------------------------------------
0x7470abfc00 zfs_member [raid]
LABEL: ddzfs
UUID: 15481972323858100681

0x438 ext4 [filesystem]
UUID: 73732a4b-362a-4339-a03f-d19bc918a3a1


On voit qu'il reste des traces liées à zfs. Et sur /dev/sdd1 on voit
qu'il semble y avoir deux infos différentes, contrairement à /dev/sdc1.

On note que l'UUID écrit sur la toute dernière ligne est celui qui a
"disparu" : c'est bien celui que j'avais écrit dans mon fstab avant de
désactiver la ligne parce que l'uuid de ce disque n'est plus reconnu
(par exemple absent de /dev/disk/by-uuid).

Est-ce que là il faudrait que j'utilise wipefs pour retirer l'info sur
le système de fichiers zfs ? Par exemple un truc comme ça ?
wipefs --offset 0x7470abfc00 --backup /dev/sdd1

(sdd1, le numéro de la partition qui semble avoir deux infos de
systèmes de fichiers et pas sdd, le disque lui-même, je suppose ?)

Le Tue, 24 Nov 2015 20:15:42 +0100
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a écrit :

Yliur a écrit :
>
> # wipefs /dev/sdd
> offset type
> ----------------------------------------------------------------
> 0x1fe dos [partition table]
>
> 0x3fc00 zfs_member [raid]
> LABEL: ddzfs
> UUID: 15481972323858100681
>
>
> # wipefs /dev/sdd1
> offset type
> ----------------------------------------------------------------
> 0x7470abfc00 zfs_member [raid]
> LABEL: ddzfs
> UUID: 15481972323858100681

Cet offset est situé vers 500 Go, soit la fin du disque.

> 0x438 ext4 [filesystem]
> UUID: 73732a4b-362a-4339-a03f-d19bc918a3a1

Cet offset est au début du disque, dans l'espace entre le MBR et le
début de la partition qui peut servir à contenir une partie de GRUB.

> On voit qu'il reste des traces liées à zfs. Et sur /dev/sdd1 on voit
> qu'il semble y avoir deux infos différentes, contrairement
> à /dev/sdc1.

Le disque a-t-il réellement été utilisé avec ZFS (que je ne connais
que de nom) ou est-ce un faux positif ?

Non, il a bien servi à ça. J'avais les deux disques dans un groupe zfs
et j'ai décidé de virer tout ça pour avoir eux disques séparés en ext4.
Ça m'étonne que je n'ai pas fait la même opération sur les deux mais
c'était il y a un moment. Ce qui m'intrigue le plus c'est que ça n'ait
posé un problème que récemment. Je suis presque certain de ne rien
avoir touché de ce côté ces temps-ci, et surtout de ne pas avoir fait
de bidouilles. Et je suis sûr que le montage du deuxième disque
fonctionnait un jour avec son uuid.

> On note que l'UUID écrit sur la toute dernière ligne est celui qui a
> "disparu" : c'est bien celui que j'avais écrit dans mon fstab avant
> de désactiver la ligne parce que l'uuid de ce disque n'est plus
> reconnu (par exemple absent de /dev/disk/by-uuid).

Il n'y a aucune raison que cet UUID ait changé tout seul.

> Est-ce que là il faudrait que j'utilise wipefs pour retirer l'info
> sur le système de fichiers zfs ? Par exemple un truc comme ça ?
> wipefs --offset 0x7470abfc00 --backup /dev/sdd1

Je dirais oui mais prudemment, éventuellement près s'être assuré avec
debugfs que le bloc correspondant n'est pas alloué.

debugfs: testb 0x7470abfc00
Illegal block number passed to ext2fs_test_block_bitmap #500106525696
for block bitmap for /dev/sdd1 Block 500106525696 not in use

Ça l'air bon, si je comprends bien c'est au-delà de mon système de
fichiers ext4. Au contraire du bloc 0x438, pour lequel j'ai une réponse
différente.

Bon, j'ai exécuté wipefs, par contre l'option --backup je n'ai pas
l'impression que ça ait fonctionné. Et ça n'a pas vraiment marché :
maintenant j'ai la même chose sauf que la valeur "offset" est
différente (un peu plus petite). J'ai essayé d'en enlever plusieurs
mais au bout d'une vingtaine j'ai laissé tomber.

J'ai aussi essayé d'utiliser wipefs pour supprimer toute l'info sur ce
système de fichiers :
wipefs -tzfs_member /dev/sdd1

Ça n'a rien fait, si j'ai bien compris wipefs gère un peu les mêmes que
mount, et zfs n'en fait pas partie (il a son propre bazar pour le
montage). J'ai essayé avec "zfs" et "zfs_member".

J'ai même essayé un truc plus radical (supprimer tout sauf ext4, en
espérant bien lire le manuel) et ça n'a pas marché (ou je m'y suis mal
pris) :
wipefs -a -tnoext4 /dev/sdd1

Là je crois que je vais arrêter de jouer avec wipefs avant de faire une
connerie, à moins que tu aies une idée précise...

> (sdd1, le numéro de la partition qui semble avoir deux infos de
> systèmes de fichiers et pas sdd, le disque lui-même, je suppose ?)

Bah, pourquoi pas les deux, même si la présence d'une signature ZFS au
début de /dev/sdd ne semble pas perturber.

Je vais éviter de tenter le diable en touchant des trucs qui ne
semblent pas poser problème, même si ce n'est pas très propre :) .


À moins d'une autre idée je vais laisser ça, tant pis. J'aurais bien
aimé savoir pourquoi ce problème est survenu brusquement (est-ce que ça
pourrait être quelque chose qui a disparu plutôt, laissant apparaître
les infos zfs qui suivent ?), mais bon... j'ai appris quelques trucs
pour satisfaire ma curiosité, je vais sas doute m'en contenter.

Le montage marche dans fstab en laissant tomber l'uuid au profit
de "/dev/sdd1" et en précisant explicitement le système de fichier
"ext4", c'est un peu bizarre mais au moins le disque peut être monté
normalement au démarrage.

Merci pour votre aide en tout cas.

Le 25 novembre 2015, Yliur a écrit :

Le montage marche dans fstab en laissant tomber l'uuid au profit
de "/dev/sdd1" et en précisant explicitement le système de fichier
"ext4", c'est un peu bizarre mais au moins le disque peut être monté
normalement au démarrage.

Et pourquoi ne repars-tu pas simplement de zéro avec ce disque ?
- réinitialisation de la table de partition,
- réécriture d'un FS ext4,
- recopie du backup sur ce disque fraîchement « reformaté » ?

Le système qui n'arrive pas à détecter un FS aussi banal, ça ne
m'inspirerait pas confiance à ta place...

--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)

Le Wed, 25 Nov 2015 11:51:19 +0100
Lucas Levrel <lucas.levrel@u-pec.fr> a écrit :

Le 25 novembre 2015, Yliur a écrit :

> Le montage marche dans fstab en laissant tomber l'uuid au profit
> de "/dev/sdd1" et en précisant explicitement le système de fichier
> "ext4", c'est un peu bizarre mais au moins le disque peut être monté
> normalement au démarrage.

Et pourquoi ne repars-tu pas simplement de zéro avec ce disque ?
- réinitialisation de la table de partition,
- réécriture d'un FS ext4,
- recopie du backup sur ce disque fraîchement « reformaté » ?

Le système qui n'arrive pas à détecter un FS aussi banal, ça ne
m'inspirerait pas confiance à ta place...

Simplement parce qu'il faudrait prendre le temps de m'en occuper :) .

Et en plus c'est ce que je pensais avoir fait, mais vu toutes les
traces de ZFS qu'il reste...

Je vais y réfléchir.

Yliur wrote:

Le Wed, 25 Nov 2015 11:51:19 +0100
Lucas Levrel <lucas.levrel@u-pec.fr> a écrit :

Le 25 novembre 2015, Yliur a écrit :

> Le montage marche dans fstab en laissant tomber l'uuid au profit
> de "/dev/sdd1" et en précisant explicitement le système de fichier
> "ext4", c'est un peu bizarre mais au moins le disque peut être monté
> normalement au démarrage.

Et pourquoi ne repars-tu pas simplement de zéro avec ce disque ?
- réinitialisation de la table de partition,
- réécriture d'un FS ext4,
- recopie du backup sur ce disque fraîchement « reformaté » ?

Le système qui n'arrive pas à détecter un FS aussi banal, ça ne
m'inspirerait pas confiance à ta place...

Simplement parce qu'il faudrait prendre le temps de m'en occuper :) .

Et en plus c'est ce que je pensais avoir fait, mais vu toutes les
traces de ZFS qu'il reste...

Un petit coup de de dd if=/dev/zero of=/dev/le_disque ne fait pas de mal
dans ce cas.

Le Wed, 25 Nov 2015 20:18:30 +0100
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a écrit :

Yliur a écrit :
>>
>>> Est-ce que là il faudrait que j'utilise wipefs pour retirer l'info
>>> sur le système de fichiers zfs ? Par exemple un truc comme ça ?
>>> wipefs --offset 0x7470abfc00 --backup /dev/sdd1
>>
>> Je dirais oui mais prudemment, éventuellement près s'être assuré
>> avec debugfs que le bloc correspondant n'est pas alloué.
>
> debugfs: testb 0x7470abfc00
> Illegal block number passed to ext2fs_test_block_bitmap
> #500106525696 for block bitmap for /dev/sdd1 Block 500106525696 not
> in use
>
> Ça l'air bon, si je comprends bien c'est au-delà de mon système de
> fichiers ext4.

Non, pas vraiment. Comme je l'ai déjà écrit, c'est à la fin. La
position indiquée par wipefs est exprimée en octets alors que debugfs
manipule des blocs dont la taille est définie dans les méta-données
du système de fichiers (4 Kio en général). Il faut convertir.

Zut, je n'ai pas fait assez attention, j'ai fait un test bidon...

Bon, je n'ai rien cassé, c'est toujours ça.

> Bon, j'ai exécuté wipefs, par contre l'option --backup je n'ai pas
> l'impression que ça ait fonctionné. Et ça n'a pas vraiment marché :
> maintenant j'ai la même chose sauf que la valeur "offset" est
> différente (un peu plus petite).

De combien ? Avec les mêmes caractéristiques (label, UUID) ?
C'est peut-être toujours la même signature effacée incomplètement.

Rien n'a changé à part ce nombre. À chaque fois il a reculé de 1024 si
je compte bien (par exemple on est passé de 0x7470abf800 à
0x7470abf400). Toujours le même écart et les mêmes 8 octets supprimés
par l'opération (la même séquence de valeurs : 0c b1 ba 00 00 00 00 00).

> J'ai essayé d'en enlever plusieurs
> mais au bout d'une vingtaine j'ai laissé tomber.

Tu pourrais essayer d'écrire dans tout l'espace libre du système de
fichiers, mais ça va prendre du temps. Ou bien réduire un peu la
taille du système de fichiers avec resize2fs puis de la partition,
vérifier à nouveau avec wipe2fs, écrire dans l'espace au delà pour
écraser la signature ZFS, réagrandir la partition puis le système de
fichiers.

Hum... tout ça sans faire une connerie, ça commence à devenir hasardeux.

Je crois que je vais garder ma solution de secours... Et merci beaucoup
pour toutes tes explications, je ne pense juste pas me lancer dans
toutes ces opérations parce que j'ai une solution (un peu bancale) qui
fonctionne et que je pense que j'ai plus de chances d'arriver à faire
une bêtise qu'autre chose en me lançant là-dedans.

Merci pour tes analyses et pour ton aide.

> À moins d'une autre idée je vais laisser ça, tant pis. J'aurais bien
> aimé savoir pourquoi ce problème est survenu brusquement (est-ce
> que ça pourrait être quelque chose qui a disparu plutôt, laissant
> apparaître les infos zfs qui suivent ?)

Peut-être un changement dans libblkid ?

Ça se pourrait, il semble que le paquet qui la contient a été mis à
jour (parmi plein d'autres) juste avant le problème.

Le Wed, 25 Nov 2015 22:38:18 +0100
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a écrit :

Yliur a écrit :
>
>>> Bon, j'ai exécuté wipefs, par contre l'option --backup je n'ai pas
>>> l'impression que ça ait fonctionné. Et ça n'a pas vraiment
>>> marché : maintenant j'ai la même chose sauf que la valeur
>>> "offset" est différente (un peu plus petite).
>>
>> De combien ? Avec les mêmes caractéristiques (label, UUID) ?
>> C'est peut-être toujours la même signature effacée
>> incomplètement.
>
> Rien n'a changé à part ce nombre. À chaque fois il a reculé de 1024
> si je compte bien (par exemple on est passé de 0x7470abf800 à
> 0x7470abf400). Toujours le même écart et les mêmes 8 octets
> supprimés par l'opération (la même séquence de valeurs : 0c b1 ba
> 00 00 00 00 00).

Comment as-tu vu cette séquence ?
Cela voudrait dire que la séquence se répète tous les kilo-octets ?
Etrange.

La commande les a affichés à chaque fois que je l'ai tapée.

# wipefs --offset 0x7470abf800 --backup /dev/sdd1
/dev/sdd1: 8 bytes were erased at offset 0x7470abf800 (zfs_member): 0c b1 ba 00 00 00 00 00

>> Tu pourrais essayer d'écrire dans tout l'espace libre du système de
>> fichiers, mais ça va prendre du temps. Ou bien réduire un peu la
>> taille du système de fichiers avec resize2fs puis de la partition,
>> vérifier à nouveau avec wipe2fs, écrire dans l'espace au delà pour
>> écraser la signature ZFS, réagrandir la partition puis le système
>> de fichiers.
>
> Hum... tout ça sans faire une connerie, ça commence à devenir
> hasardeux.

Si tu as le temps, l'écriture d'un fichier de zéros sur tout l'espace
libre ne présente pas de risque particulier :

dd bs=4k if=/dev/zero of=/point/de/montage/effacetout

Sans doute mais il faudrait que je sois sûr de ce qui est libre (en
lisant la table des partitions sans doute).

Parce que cette commande telle quelle ne va pas permettre de faire un
effacement ciblé, il faudrait trouver le premier octet concernée et le
lui indiquer.

J'y reviendra peut-être plus tard.