NAS HDD problème de montage

Support Debian
#1

Bonjour.

Voila je rencontre un problème, je dispose d’un NAS monter perso. comme on peux le voir sur la photo.

Je dispose de 5 HDD:
1 HDD IDE 80 Go: linux hdd de boot (sda)
1 HDD SATA 500 Go : données divers (sdb)
1 HDD SATA 1000 Go : données divers (sdc)
1 HDD SATA 1500 Go : données divers (sdd)
1 HDD SATA 500 Go : données divers (sde)
pas de raid.

Ancienne carte mère avais un CPU intel socket 775 LGA, je n’avais aucun souci lors du montage auto des HDD, on peux le voir ici dans fstab (ancienne config)

dev/sdb /media/hdd1 auto defaults 0 0
dev/sdc /media/hdd2 auto defaults 0 0
dev/sdd /media/hdd3 auto defaults 0 0
dev/sde /media/hdd4 auto defaults 0 0

Depuis je suis passé sur une carte mère avec un CPU AMD socket AM2 (940). J’ai remonté les HDD correctement en automatique dans fstab ,mais le HDD de 80 Go, quelques fois est nommé SDA et quelques fois SDE.
Et cela fait tout un bizarre au niveau des montages des autres HDD.
J’ai essayer avec blkid.

UUID=9cd7d5e6-a1c4-4af7-982d-d9c1cccecdd2 /media/hdd1 auto defaults 0 0
UUID=2ad55e9f-ff39-4c5c-a4c0-6d696526582e /media/hdd2 auto defaults 0 0
UUID=a274f7b1-13fe-4255-b81b-5b040688ab74 /media/hdd3 auto defaults 0 0
UUID=020388ca-709f-4ece-a8b9-6b0717d83d9f /media/hdd4 auto defaults 0 0

Mais cela ne change rien au contraire je n’ai plus rien qui est monter.
Avez-vous des idées.

#2

Dans le fichier /etc/fstab, mieux vaut utiliser les UUID plutôt que les /dev/sd…, qui dépendent de l’ordre de détection des disques. Mais dans le blkid ci-dessus, il n’y a pas le disque contenant la partition racine (le disque IDE) ?

Tu peux nous donner le contenu du nouveau fichier /etc/fstab ?

#3

Voila :slight_smile:

root@NAS:~# blkid /dev/sda1
/dev/sda1: UUID="2a12ca6d-7472-4c83-898d-c10d259a587c" TYPE="ext4"
root@NAS:~# blkid /dev/sda2
/dev/sda2: UUID="d570af73-abbf-4096-9e0e-2779b084d639" TYPE="swap"

Est t’il possible de forçais l’attribution des lettres de lecteurs ou non ?

#4

Bonjour,

Comme le dit @Sputnik93, l’ordre de “nommage” dépends de l’ordre de détection des disques, tu ne peux donc rien y faire, c’est pour cela que maintenant les fstab utilisent les uuid.
Je pense que tu as fait une erreur dans ton fstab à la colonne “type”, il faut spécifier le type du système de fichier (cf debian-facile.org).

D’après les informations que tu nous donnes, ton fstab devrait ressembler à ça:

# System
UUID=2a12ca6d-7472-4c83-898d-c10d259a587c   /           ext4    errors=remount-ro   0   1
UUID=9037b526-2a5d-4399-9726-4878fc62659d   none        swap    sw                                  0   0
# Others
UUID=9cd7d5e6-a1c4-4af7-982d-d9c1cccecdd2   /media/hdd1 ext4    defaults                            0   0
UUID=2ad55e9f-ff39-4c5c-a4c0-6d696526582e   /media/hdd2 ext4    defaults                            0   0
UUID=a274f7b1-13fe-4255-b81b-5b040688ab74   /media/hdd3 ext4    defaults                            0   0
UUID=020388ca-709f-4ece-a8b9-6b0717d83d9f   /media/hdd4 ext4    defaults                            0   0
#5

Je pensé a un hourra , mais non. :frowning:
Alors après avoir fait ton exemple "sk4hrr"tout fonctionner parfaitement bien. Le HDD IDE étais en sde, les 4 HDD étais bien monté correctement. J’ai rebooté quelques fois, cela marchais toujours.

root@NAS:/media/hdd1# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=2a12ca6d-7472-4c83-898d-c10d259a587c /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda2 during installation
UUID=d570af73-abbf-4096-9e0e-2779b084d639 none            swap    sw              0       0

UUID=020388ca-709f-4ece-a8b9-6b0717d83d9f       /media/hdd1     ext4    defaults        00
UUID=2ad55e9f-ff39-4c5c-a4c0-6d696526582e       /media/hdd2     ext4    defaults        00
UUID=9cd7d5e6-a1c4-4af7-982d-d9c1cccecdd2       /media/hdd3     ext4    defaults        00
UUID=a274f7b1-13fe-4255-b81b-5b040688ab74       /media/hdd4     ext4    defaults        00

Puis un reboot de trop, le HDD IDE à pris la place sda, et la plus rien ne marche, c’est vraiment bizarre, j’avais pas le souci avec l’ancienne carte mère.

Je donne plus d’info ici

root@NAS:~# lsblk -rnf
sda
sda1 ext4  /
sda2 swap  [SWAP]
sdb ext4
sdb1
sdc ext4
sdc1
sdd ext4
sdd1
sde ext4
sde1

Voici la config du BIOS


Au début j’avais cette carte mère là.

Aucun souci de montage, puis je suis passé sur cette carte mère là.

Il y a pas des “log” de montage pour savoir ce qu’il ce passe ?
Il n’y a pas une possibilité de définir un ordre de priorité du montage des HDD

#6

Qu’entends-tu par “plus rien ne marche” ? Le système ne démarre plus ? tes autres disques ne montent pas ?

Ça ne vient pas directement de la carte mère, mais sans doute de comment elles ont évoluées. A la grande époque de l’IDE, les périphériques étaient connectés et c’est tout. Avec le SATA, tu branches/débranches un périphérique comme tu peux le faire avec une clef USB (oui ok, on peut le faire avec l’IDE aussi, mais c’était pas fait pour).

Bref, pour les logs, j’imagine que /var/log/dmesgdonne des informations.

#7

Oui les HDD ne sont plus monter :), mais l’OS est bien là je rassure :smiley:

Mais ce que je trouve bizarre, je n’avais aucun souci avec l’ancienne carte mère.

Je vais consulté les logs, je reviens de suite.

voici les log
"http://sebsauvage.net/paste/?d90b601ef9908077#HRuXaMXc9CF+VKz8LnA0GHNrkdR6RbU5W5wW9qM5LfI="

#8

Si tu utilises la commande mount -a une fois que le système à démarrer, les disques ne montent pas ?

#9

Voila ce qu’il me dit

root@NAS:~# mount -a
mount : le périphérique spécial UUID=020388ca-709f-4ece-a8b9-6b0717d83d9f n'existe pas
mount : le périphérique spécial UUID=2ad55e9f-ff39-4c5c-a4c0-6d696526582e n'existe pas
mount : le périphérique spécial UUID=9cd7d5e6-a1c4-4af7-982d-d9c1cccecdd2 n'existe pas
mount : le périphérique spécial UUID=a274f7b1-13fe-4255-b81b-5b040688ab74 n'existe pas
root@NAS:~#

pourtant

root@NAS:~# blkid /dev/sda
/dev/sda: LABEL="hdd1" UUID="9cd7d5e6-a1c4-4af7-982d-d9c1cccecdd2" TYPE="ext4"
root@NAS:~# blkid /dev/sdb
/dev/sdb: LABEL="hdd2" UUID="2ad55e9f-ff39-4c5c-a4c0-6d696526582e" TYPE="ext4"
root@NAS:~# blkid /dev/sdc
/dev/sdc: LABEL="hdd3" UUID="a274f7b1-13fe-4255-b81b-5b040688ab74" TYPE="ext4"
root@NAS:~# blkid /dev/sdd
/dev/sdd: LABEL="hdd4" UUID="020388ca-709f-4ece-a8b9-6b0717d83d9f" TYPE="ext4"
#10

Le répertoire /dev/disk/by-uuid/ contient-il des liens symboliques pour chacun de ces UUID ?
Si oui, tu peux regarder à la fin des logs du noyau affichés par dmesg.

Utiliser les UUID dans le fichier fstab n’empêchera pas le disque IDE d’être nommé sda de temps en temps, ce n’est pas leur rôle. Leur rôle est simplement d’éviter que ce nommage variable ait des conséquences néfastes puisque les UUID, eux, ne changent pas.

Je vois un souci : tu utilises les disques entiers sd[b…e] comme systèmes de fichiers mais ceux-ci ont visiblement une table de partition définissant une partition sd[b…e]1. Cela pourrait perturber la bonne reconnaissance des UUID. A mon avis, ce n’est pas une bonne idée d’utiliser un disque de cette façon. Mais je suppose que c’est un peu tard pour réécrire le système de fichiers dans la partition. Il faudrait donc supprimer au moins la partition, au plus la table de partition elle-même (avec wipefs par exemple, attention à n’effacer que la signature de table de partition et pas la signature ext4).

#11

Connaître le retour de la commande blkid tout court est-il possible ?

–
AnonymousCoward

#12

voila

root@NAS:~# ls /dev/disk/by-uuid
020388ca-709f-4ece-a8b9-6b0717d83d9f  9cd7d5e6-a1c4-4af7-982d-d9c1cccecdd2
2a12ca6d-7472-4c83-898d-c10d259a587c  a274f7b1-13fe-4255-b81b-5b040688ab74
2ad55e9f-ff39-4c5c-a4c0-6d696526582e  d570af73-abbf-4096-9e0e-2779b084d639

Alors oui j’utilise les disques en entier
pourtant j’avais aucun souci avec l’ancienne carte mère, et je ne pense pas que le reformatage de l’OS changeras quelques chose ?

fdsik -l
Disque /dev/sdb : 1000.2 Go, 1000204886016 octets
81 têtes, 63 secteurs/piste, 382818 cylindres, total 1953525168 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x21baaccb

Périphérique Amorce  Début        Fin      Blocs     Id  Système
/dev/sdb1            2048  1953525167   976761560   83  Linux

Disque /dev/sda : 500.1 Go, 500106780160 octets
48 têtes, 29 secteurs/piste, 701703 cylindres, total 976771055 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0xb1c2e9c1

Périphérique Amorce  Début        Fin      Blocs     Id  Système
/dev/sda1            2048   976771054   488384503+  83  Linux

Disque /dev/sdc : 1500.3 Go, 1500301910016 octets
81 têtes, 63 secteurs/piste, 574226 cylindres, total 2930277168 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0xd342f53b

Périphérique Amorce  Début        Fin      Blocs     Id  Système
/dev/sdc1            2048  2930277167  1465137560   83  Linux

Disque /dev/sdd : 500.1 Go, 500107862016 octets
81 têtes, 63 secteurs/piste, 191411 cylindres, total 976773168 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x0553df3b

Périphérique Amorce  Début        Fin      Blocs     Id  Système
/dev/sdd1            2048   976773167   488385560   83  Linux

Disque /dev/sde : 82.0 Go, 81964302336 octets
255 têtes, 63 secteurs/piste, 9964 cylindres, total 160086528 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x0000228a

Périphérique Amorce  Début        Fin      Blocs     Id  Système
/dev/sde1   *        2048   158203903    79100928   83  Linux
/dev/sde2       158203904   160086015      941056   82  partition d'échange Linux / Solaris

voila voila, ça vient

root@NAS:~# blkid
/dev/sde1: UUID="2a12ca6d-7472-4c83-898d-c10d259a587c" TYPE="ext4"
/dev/sde2: UUID="d570af73-abbf-4096-9e0e-2779b084d639" TYPE="swap"
#13

Je n’ai pas parlé de reformater le système. Juste de supprimer les partitions bidon des 4 disques qui n’apportent que de la confusion. Pour la signature de table de partition, d’après le format de sortie de fdisk tu utilises une version de Debian antérieure à Jessie, donc la version de wipefs ne saura pas gérer convenablement la signature de table de partition DOS/MBR.

C’est curieux que blkid n’affiche que les UUID du disque système alors que les liens symboliques sont présents. Et si tu remplaces UUID=<uuid> par /dev/disk/by-uuid/<uuid> dans /etc/fstab ?

#14

faut dire que cette machine a un petit vécu :).
Dis moi tu auras partitionner les HDD de quel façon , d’après toi, c’est juste un avis :slight_smile:

Si j’ai bien compris ton explication, j’ai fais ceci

/dev/disk/by-uuid/020388ca-709f-4ece-a8b9-6b0717d83d9f  /media/hdd1     ext4    defaults        0       0
/dev/disk/by-uuid/2ad55e9f-ff39-4c5c-a4c0-6d696526582e  /media/hdd2     ext4    defaults        0       0
/dev/disk/by-uuid/9cd7d5e6-a1c4-4af7-982d-d9c1cccecdd2  /media/hdd3     ext4    defaults        0       0
/dev/disk/by-uuid/a274f7b1-13fe-4255-b81b-5b040688ab74  /media/hdd4     ext4    defaults        0       0

après un reboot, non toujours rien, pas de montage auto

#15

Bonjour

J’aimerai bien voir le retour de la commande ls avec l’option -l (L minuscule)
histoire de voir vers quoi pointent les liens (disque ou partition ?)
qui ont été créés.

Donc :

ls -l /dev/disk/by-{id,label,uuid}

Pour le retour de commande, ajoute , avant et après la zone de texte à formater,
une ligne ne contenant que trois “backtics” qu’on peut obtenir en appuyant sur AltGr+7

Je me suis permis de modifier l’apparence de certains blocs de texte dans tes messages.

#16

voila, si j’ai bien compris

root@NAS:~# ls -l /dev/disk/by-{id,label,uuid}
/dev/disk/by-id:
total 0
lrwxrwxrwx 1 root root  9 mars   6 10:43 ata-Maxtor_6Y080L0_Y2CT0W2C -> ../../sde
lrwxrwxrwx 1 root root 10 mars   6 10:43 ata-Maxtor_6Y080L0_Y2CT0W2C-part1 -> ../../sde1
lrwxrwxrwx 1 root root 10 mars   6 10:43 ata-Maxtor_6Y080L0_Y2CT0W2C-part2 -> ../../sde2
lrwxrwxrwx 1 root root  9 mars   6 10:43 ata-SAMSUNG_HD154UI_S1Y6J9DSA00050 -> ../../sdc
lrwxrwxrwx 1 root root 10 mars   6 10:43 ata-SAMSUNG_HD154UI_S1Y6J9DSA00050-part1 -> ../../sdc1
lrwxrwxrwx 1 root root  9 mars   6 10:43 ata-ST31000528AS_5VP382FQ -> ../../sdb
lrwxrwxrwx 1 root root 10 mars   6 10:43 ata-ST31000528AS_5VP382FQ-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  9 mars   6 10:43 ata-WDC_WD5000AAJS-22YFA0_WD-WCAS84382470 -> ../../sdd
lrwxrwxrwx 1 root root 10 mars   6 10:43 ata-WDC_WD5000AAJS-22YFA0_WD-WCAS84382470-part1 -> ../../sdd1
lrwxrwxrwx 1 root root  9 mars   6 10:43 ata-WDC_WD5000AAKS-00V1A0_WD-WCAWF0490472 -> ../../sda
lrwxrwxrwx 1 root root 10 mars   6 10:43 ata-WDC_WD5000AAKS-00V1A0_WD-WCAWF0490472-part1 -> ../../sda1
lrwxrwxrwx 1 root root  9 mars   6 10:43 scsi-SATA_Maxtor_6Y080L0_Y2CT0W2C -> ../../sde
lrwxrwxrwx 1 root root 10 mars   6 10:43 scsi-SATA_Maxtor_6Y080L0_Y2CT0W2C-part1 -> ../../sde1
lrwxrwxrwx 1 root root 10 mars   6 10:43 scsi-SATA_Maxtor_6Y080L0_Y2CT0W2C-part2 -> ../../sde2
lrwxrwxrwx 1 root root  9 mars   6 10:43 scsi-SATA_SAMSUNG_HD154UIS1Y6J9DSA00050 -> ../../sdc
lrwxrwxrwx 1 root root 10 mars   6 10:43 scsi-SATA_SAMSUNG_HD154UIS1Y6J9DSA00050-part1 -> ../../sdc1
lrwxrwxrwx 1 root root  9 mars   6 10:43 scsi-SATA_ST31000528AS_5VP382FQ -> ../../sdb
lrwxrwxrwx 1 root root 10 mars   6 10:43 scsi-SATA_ST31000528AS_5VP382FQ-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  9 mars   6 10:43 scsi-SATA_WDC_WD5000AAJS-_WD-WCAS84382470 -> ../../sdd
lrwxrwxrwx 1 root root 10 mars   6 10:43 scsi-SATA_WDC_WD5000AAJS-_WD-WCAS84382470-part1 -> ../../sdd1
lrwxrwxrwx 1 root root  9 mars   6 10:43 scsi-SATA_WDC_WD5000AAKS-_WD-WCAWF0490472 -> ../../sda
lrwxrwxrwx 1 root root 10 mars   6 10:43 scsi-SATA_WDC_WD5000AAKS-_WD-WCAWF0490472-part1 -> ../../sda1
lrwxrwxrwx 1 root root  9 mars   6 10:43 wwn-0x5000c5001e9ccd4f -> ../../sdb
lrwxrwxrwx 1 root root 10 mars   6 10:43 wwn-0x5000c5001e9ccd4f-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  9 mars   6 10:43 wwn-0x50014ee100ad1ba7 -> ../../sdd
lrwxrwxrwx 1 root root 10 mars   6 10:43 wwn-0x50014ee100ad1ba7-part1 -> ../../sdd1
lrwxrwxrwx 1 root root  9 mars   6 10:43 wwn-0x50014ee157a1fb84 -> ../../sda
lrwxrwxrwx 1 root root 10 mars   6 10:43 wwn-0x50014ee157a1fb84-part1 -> ../../sda1
lrwxrwxrwx 1 root root  9 mars   6 10:43 wwn-0x50024e92011eaab0 -> ../../sdc
lrwxrwxrwx 1 root root 10 mars   6 10:43 wwn-0x50024e92011eaab0-part1 -> ../../sdc1

/dev/disk/by-label:
total 0
lrwxrwxrwx 1 root root 10 mars   6 10:43 hdd1 -> ../../sda1
lrwxrwxrwx 1 root root 10 mars   6 10:43 hdd2 -> ../../sdb1
lrwxrwxrwx 1 root root 10 mars   6 10:43 hdd3 -> ../../sdc1
lrwxrwxrwx 1 root root 10 mars   6 10:43 hdd4 -> ../../sdd1

/dev/disk/by-uuid:
total 0
lrwxrwxrwx 1 root root 10 mars   6 10:43 020388ca-709f-4ece-a8b9-6b0717d83d9f -> ../../sdd1
lrwxrwxrwx 1 root root 10 mars   6 10:43 2a12ca6d-7472-4c83-898d-c10d259a587c -> ../../sde1
lrwxrwxrwx 1 root root 10 mars   6 10:43 2ad55e9f-ff39-4c5c-a4c0-6d696526582e -> ../../sdb1
lrwxrwxrwx 1 root root 10 mars   6 10:43 9cd7d5e6-a1c4-4af7-982d-d9c1cccecdd2 -> ../../sda1
lrwxrwxrwx 1 root root 10 mars   6 10:43 a274f7b1-13fe-4255-b81b-5b040688ab74 -> ../../sdc1
lrwxrwxrwx 1 root root 10 mars   6 10:43 d570af73-abbf-4096-9e0e-2779b084d639 -> ../../sde2
#17

C’est rassurant : on constate dans ton retour de commande
que ce sont bien les partitions des disques qui ont étées formatées.

…Mais ça contredit le retour de blkid (Message N°9) qui donnait ces UUIDs pour les disques plutôt que les partitions

Il y a peut-être un soucis avec les points de mountages.

Donnne le retour de la commande suivante :

ls -l /media

Merci.

Une idée, peut-être : Si tu le peux, dans le BIOS, essaye de mettre le disque IDE en fin de liste.

Normalement, qu’il soit en premier ou dernier ne doit rien changer puisque ce sont les UUID’s des systèmes de fichiers qui sont utilisés et que les 4 disques SATA ne sont (théoriquement) pas bootables.

Mais si par hasard ils l’étaient, il vaudrait mieux que ce soit avec le chargeur de boot du système installé sur le disque IDE.

#18

Soit tu as raison, mais c’est aussi en contradiction avec le contenu antérieur du fstab (message n° 1) qui mentionnait les disques entiers et non les partitions et était réputé fonctionner, soit libblkid débloque complètement et attribue aux partitions les UUID et labels des systèmes des fichiers créés sur les disques entiers. Je penche pour la seconde hypothèse. J’ai d’ailleurs déjà vu ce phénomène avec des clés USB qui avaient reçu une image ISO puis été repartitionnées/reformatées mais sans effacer l’en-tête ISO 9660 contenant le label (qui se trouve dans une zone située en dehors de la table de partition et des partitions), qui se retrouvait attribué à tort la partition.

Juge de paix pour nous départager : file -s /dev/sd*

Aucune chance. Primo c’est le disque système donc il doit être en premier, secundo l’ordre des disques dans le BIOS n’a aucune influence sur l’ordre d’énumération des disques par Linux.

1 J'aime
#19

c’est bizarre, je me souviens bien d’avoir formater le disque en entier , puis après avoir partitionner le disque entier

mkfs.ext4 /dev/sdxxx puis j’ai partionné le HDD avec fdisk

root@NAS:~# ls -l /media
total 16
drwxr-xr-x 2 root root 4096 mars 12 2017 hdd1
drwxr-xr-x 2 root root 4096 mars 12 2017 hdd2
drwxr-xr-x 2 root root 4096 mars 12 2017 hdd3
drwxr-xr-x 2 root root 4096 mars 12 2017 hdd4

root@NAS:~# file -s /dev/sd*
/dev/sda: sticky x86 boot sector; partition 1: ID=0x83, starthead 32, startsector 2048, 976769007 sectors, extended partition table (last)\011, code offset 0x0
/dev/sda1: sticky data
/dev/sdb: sticky x86 boot sector; partition 1: ID=0x83, starthead 32, startsector 2048, 1953523120 sectors, extended partition table (last)\011, code offset 0x0
/dev/sdb1: sticky data
/dev/sdc: sticky x86 boot sector; partition 1: ID=0x83, starthead 32, startsector 2048, 2930275120 sectors, extended partition table (last)\011, code offset 0x0
/dev/sdc1: sticky data
/dev/sdd: sticky x86 boot sector; partition 1: ID=0x83, starthead 32, startsector 2048, 976771120 sectors, extended partition table (last)\011, code offset 0x0
/dev/sdd1: sticky data
/dev/sde: sticky x86 boot sector; partition 1: ID=0x83, active, starthead 32, startsector 2048, 158201856 sectors; partition 2: ID=0x82, starthead 254, startsector 158203904, 1882112 sectors, code offset 0x63
/dev/sde1: sticky Linux rev 1.0 ext4 filesystem data, UUID=2a12ca6d-7472-4c83-898d-c10d259a587c (needs journal recovery) (extents) (large files) (huge files)
/dev/sde2: sticky Linux/i386 swap file (new style), version 1 (4K pages), size 235263 pages, no label, UUID=d570af73-abbf-4096-9e0e-2779b084d639

Voila désoler pour l’attente

#20

Pas de souci, on n’est pas pressé. Par contre file s’est arrêté au MBR, il faut donc ajouter l’option -k pour qu’il détecte toutes les méta-données.

Mais on peut déjà voir que les partitions ne contiennent pas de méta-données ext4. Elles sont donc bien sur les disques entiers.

En résumé, tu as tout fait à l’envers. Si tu avais partitionné les disques en GPT, tu aurais même détruit le formatage ext4. La table de partition MBR n’occupe qu’une partie du MBR, qui n’est pas utilisé par le format ext4 (réservé comme éventuel secteur d’amorçage). Par contre la table de partition GPT occupe les 14 premiers secteurs et aurait donc écrasé le début du système de fichiers ext4.

Le bon ordre c’est : on partitionne le disque et ensuite on formate les partitions. Même s’il n’y a qu’une seule partition qui occupe tout le disque.