Lecture de disque OpenBSD (ffs v2)

Support Debian
#1

Salut,

Je cherche à lire un disque OpenBSD de 2To sur ma Debian Stretch. Je lis facilement les disques jusqu’à 1To avec la commande :

mount -r -t ufs -o ufstype=44bsd /dev/sdc4 /mnt/BSD

Les disques de 2To sont, paraît-il, formatés en ffs v2, mais quand j’essaie

mount -r -t ufs -o ufstype=ufs2 /dev/sdc4 /mnt/BSD

j’ai le message suivant :

mount: mauvais type de système de fichiers, option erronée, superbloc erroné sur /dev/sdc4, page de code ou programme auxiliaire manquant, ou autre erreur

Dans certains cas des renseignements utiles sont dans le journal
système — essayez « dmesg | tail » ou quelque chose du genre.

Même chose si je garde 44bsd (ce qui semble normal) ou si j’essaie 5xbsd.
Pourtant, le man indique bien que ufs2 est supporté en lecture et en écriture… Que se passe-t-il donc ? Comment lire ce disque (je n’ai pas besoin d’y écrire) ?

Je n’ai pas de Debian Buster sous la main, mais éventuellement je pourrais en monter une. Aurais-je alors la chance de pouvoir lire ce disque ?

#2

Que dit dmesg | tail quand tu cherches à le monter ?
(comme le demande le message)

#3 
# dmesg | tail -n 27

[18240.775154] scsi 10:0:0:0: Direct-Access TOSHIBA HDWA120 ACF0 PQ: 0 ANSI: 2 CCS
[18240.776537] sd 10:0:0:0: Attached scsi generic sg3 type 0
[18240.778733] sd 10:0:0:0: [sdc] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
[18240.779609] sd 10:0:0:0: [sdc] Write Protect is off
[18240.779618] sd 10:0:0:0: [sdc] Mode Sense: 00 38 00 00
[18240.780473] sd 10:0:0:0: [sdc] Asking for cache data failed
[18240.780486] sd 10:0:0:0: [sdc] Assuming drive cache: write through
[18240.804690] sdc: sdc4
sdc4: <openbsd: sdc5 >
[18240.807596] sd 10:0:0:0: [sdc] Attached SCSI disk
[18241.146268] ufs: ufs was compiled with read-only support, can’t be mounted as read-write
[18241.147109] ufs: You didn’t specify the type of your ufs filesystem

          mount -t ufs -o ufstype=sun|sunx86|44bsd|ufs2|5xbsd|old|hp|nextstep|nextstep-cd|openstep ...
         
          >>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old

[18241.148294] ufs: ufs_fill_super(): bad magic number
[18241.249246] ufs: ufs was compiled with read-only support, can’t be mounted as read-write
[18241.249532] ufs: You didn’t specify the type of your ufs filesystem

          mount -t ufs -o ufstype=sun|sunx86|44bsd|ufs2|5xbsd|old|hp|nextstep|nextstep-cd|openstep ...
         
          >>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old

[18241.250516] ufs: ufs_fill_super(): bad magic number
[19205.064195] ufs: ufs_fill_super(): bad magic number
[19589.274948] ufs: ufs_fill_super(): fragment size 8192 is too large
[19651.730486] ufs: ufs_fill_super(): fragment size 8192 is too large

#4

Salut,

Bon, personne n’a une solution ou une explication sur le fait que je n’arrive pas à lire ce disque alors que le man semble dire que c’est théoriquement possible ?

#5

Essaye de monter en lecture seule:

#6

Mon idée vient de là:

#7

Salut,

Merci pour ta suggestion, mais ça ne résoud rien :disappointed_relieved: que ce soit avec ufstype=ufs2 ou avec ufstype=44bsd (formatage par défaut des disques < 2To. Pour ce disque de 2To, je ne l’ai pas formaté différemment des autres, mais on m’a dit que dans ce cas le fs est ufs v2)

Je m’y attendais : l’option -r que j’avais mise est déjà pour le montage en read only.

J’avoue assez mal comprendre ce que sort dmesg : déjà cette histoire de read only qui ne colle pas avec le man… Bon, peut-être, puisqu’il ne semble pas reconnaître ufstype, qu’il se base sur l’un de ceux qui sont effectivement en read only :

Je ne sais d’ailleurs pas ce qu’il en est de ceux pour lesquels rien n’est spécifié ? En tous cas, les disques de moins de 2Go (44bsd) se montent en lecture seule :

# mount -t ufs -o ufstype=44bsd /dev/sdc4 /mnt/BSD
mount: /dev/sdc4 est protégé en écriture, sera monté en lecture seule

Ce qui laisse penser que s’il y avait un problème d’option de montage -r ou -o ro, le montage se ferait malgré tout, en lecture seule et avec le warning…

Ce qui m’interroge plus, ce sont les autres erreurs reportées par dmesg :

Ben si ! Et pourquoi me le répéter deux fois ?

Répété plusieurs fois… De même pour :

Bon, je pense que certains de ces messages sont dûs au fait que le bon ufstype n’est pas pris en compte. Mais pourquoi ne l’est-il pas, pourquoi est-il même signalé comme absent alors que bien précisé dans la commande ?

#8

Ben et si tu essayes ufstype=old pour voir ?

#9

Je n’y croyais pas non plus, et l’essai l’a confirmé : mêmes message d’erreur en console et dans dmesg…

J’ai aussi fait l’essai avec un disque de 250Go (que je lis sans problème avec ufstype=44bsd) : il se monte sans message d’erreur à la console, mais /mnt/BSD/ est vide ! dmesg me dit :

error (device sdc4): ufs_check_page: bad entry in directory #2: rec_len is too small for name_len - offset=0, rec_len=12, name_len=260
#10

Alors dans les trucs subtils et on ne sait pas pourquoi ça marcherais mieux, je n’avais pas fait attention à ton -r quand je t’ai suggéré le -o ro et je l’avais remis dans ma commande de mount, mais essaye avec uniquement le -o ro, sans le -r, je crois que tu n’as pas testé ça:
mount -t ufs -o ro,ufstype=ufs2 /dev/sdc4 /mnt/BSD

#11

Déjà essayé, sans succès :frowning:

J’ai bien trituré la commande dans tous les sens (divers ufstypes, ro ou pas, -r ou -r -o ro ou -o ro etc.), je ne pense pas que ça vienne de là : avec des disques de moins de 1 To, soit la commande est valide et elle fonctionne, soit on a un message d’erreur assez conforme à la situation, soit en console soit au moins dans dmesg. Dans aucun cas (même avec des disques FreeBSD) je n’ai eu ce message disant qu’il manque l’ufstype alors qu’il y est…

J’en viens plutôt à me demander si le support ffs v2 (ufs2 ou 5xbsd) est bien installé. Je n’avais rien eu à faire pour 44bsd, installé d’origine, mais peut-être que pour ufs2 c’est différent ? Pourtant, ce n’est pas ce qui est dit ici…

Edit : Oui, oui, j’ai bien essayé de faire le modprobe !

Edit 2 : Je n’ai plus de disque FreeBSD, mais à l’époque où j’avais testé, ça fonctionnait parfaitement, et donc avec ufstype=ufs2. Par contre, je ne me souviens plus sur quelle version de Debian (ou autre distrib…) j’avais fait ça. Mais probablement pas sous Stretch…

#12

test avec des outils plus à jour, j’ai rencontré et d’autre aussi le même problème avec des filesystem en ufs2 OpenBSD sur du sysrescuecd pas à jour.

2 J'aime
#13

C’est pas inintéressant comme réflexion.
Je ne sais pas ce que tu as essayé de “modprober”, mais si c’est du filesystem un peu ancien et plus ou moins abandonné, il est possible que pour allèger, debian ne l’ai pas activé ni dans le noyau ni en module.
Faudrait regarder les flags correspondant dans /boot/config-`uname -r` (flags que je ne connais pas, vu que je ne connais même pas les composants noyaux concernés)

#14

En cherchant sur ton probléme, j’ai beaucoup vu le passage jessie suggéré comme solution à ton probléme, autour de sa sortie.

#15

Salut,

Merci à tous les deux pour vos réponses :slight_smile:

Bon, ça veut dire qu’il faudrait que j’essaie avec Buster (mes Stretch sont à jour !) ? C’est effectivement la question que je me posais dès le départ. Bon, pas eu encore le temps de passer mes postes de travail sous Buster, ça va être l’occasion ! Ou alors, il faut que j’essaie sur mon serveur, mais c’est bien moins pratique… Ou que j’essaie avec une version live, mais je n’ai que la version netinstall… Bon, je vais voir ça ASAP.

Ben, ce qui est préconisé dans le document que j’ai mentionné (c’est à dire la présence du module ufs) :wink:

Ben non, ils n’auraient pas laissé ufstype=old et ufstype=44bsd, les plus anciens, et supprimé ufstype=ufs2, version la plus récente !

Euh… Ce n’est pas équivalent à ce qu’on peut voir avec modprobe ?

??? Ça voudrait dire que ça fonctionnait avec Jessie et que ça ne fonctionne plus avec Stretch ? Pareil que ce que tu as dit plus haut : ils ne vont quand même pas supprimer les versions les plus récentes d’UFS et conserver les plus anciennes ?

#16

Tu peux sans doute essayer d’abord avec chroot, ou un container, voir plus simple avec une ISO live.

1 J'aime
#17

Alors non, quand tu compiles ton noyau, tu peux décider de compiler un composant en dur dans le noyau (il n’y a pas de module externe a modprober, le module est là dans le noyau), ou bien en tant que module externe (que tu peux modprober), ou bien pas du tout intégré au noyau ni en interne ni en externe.
En gros, tu ne peux modprober qu’en disant à la compil que tu veux le module, et que tu veux qu’il soit externe.
Au niveau des flags, ça donne ça:

mj@mercure:~$ grep UFS /boot/config-4.19.0-6-amd64 
CONFIG_SCSI_UFSHCD=m
CONFIG_SCSI_UFSHCD_PCI=m
# CONFIG_SCSI_UFS_DWC_TC_PCI is not set
# CONFIG_SCSI_UFSHCD_PLATFORM is not set
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set
# CONFIG_UFS_DEBUG is not set
mj@mercure:~$ find /lib/modules/4.19.0-6-amd64/ -name ufs
/lib/modules/4.19.0-6-amd64/kernel/fs/ufs
/lib/modules/4.19.0-6-amd64/kernel/drivers/scsi/ufs

Et par exemple, là on voit bien la config noyau de 3 trucs UFS en module:
https://cateee.net/lkddb/web-lkddb/SCSI_UFSHCD.html
https://cateee.net/lkddb/web-lkddb/UFS_FS.html
https://cateee.net/lkddb/web-lkddb/SCSI_UFSHCD_PCI.html
et des trucs complètement désactivés (is not set), comme l’écriture UFS.
C’est peut être cette partie expérimentale CONFIG_UFS_FS_WRITE qui manque ?
[edit: en fait les UFS_SCSI concernent la gestion de cartes Universal Flash Storage, je viens de voir que seul les flags UFS_FS concernent ton soucis]

Oui, c’est vrai que ce ne serait pas super logique.

#18

Ou une vm…
Ou juste en installant un noyau jessie.

1 J'aime
#19

Bon, du coup j’ai été à ce qui était finalement le plus simple : mettre le disque dans mon serveur qui est sous Buster (à jour). Et là, ça change effectivement pas mal :

# mount -r -t ufs -o ufstype=44bsd /dev/sdc4 /mnt/BSD

mount: /mnt/BSD: wrong fs type, bad option, bad superblock on /dev/sdc4, missing codepage or helper program, or other error.

(je déteste ce forum : pas moyen de mettre proprement du code…)
et dmesg me dit :

ufs: ufs_fill_super(): bad magic number

Ok, j’ai testé pour voir avec le mauvais ufstype (parait-il qu’OpenBSD utilise par défaut ffs v1 pour moins de 2To et ufs v2 à partir de 2To)
Essayons avec ufs2 :

# mount -r -t ufs -o ufstype=ufs2 /dev/sdc4 /mnt/BSD

mount: /mnt/BSD: wrong fs type, bad option, bad superblock on /dev/sdc4, missing codepage or helper program, or other error.

et dmesg dit :

ufs: ufs_fill_super(): fragment size 8192 is too large

C’est déjà beaucoup mieux ! Mais si je comprends bien, ufs2 ne gère pas (encore) les fragments de 8192 octets, taille obligatoire sur un disque de 2To. Pas pu essayer faute de disque correspondant, mais je suppose qu’avec une taille de fragments de 4096 ou moins, ça doit se monter sans problème (c’est ce que j’avais expérimenté autrefois en tous cas).

Bon, à moins qu’il y ait un moyen de s’adapter à cette taille de fragments, je crois bien qu’il ne me reste plus qu’à récupérer mes données sous OpenBSD…

1 J'aime
#20

Depuis une vm sur ta box linux, par exemple.