Mauvais type système de fichiers ... (sauvegarde - avec GPT)

Support Debian
#1

Un script de sauvegarde identique, qui fonctionne sur toutes mes machines. Sur la dernière installée (nativement avec système de table de partition GPT), j’ai un refus :
Le bât blesse au montage de la cible et l’erreur est clairement annoncée “mauvais type de montage de fichiers”.

PtMontage=’/mnt’
cibleR=’/dev/disk/by-partlabel/sauve-miniR’

if …
…
…
sudo mount -t ext4 $cibleR $PtMontage

D’après ce que j’en déduis, il ne reconnait pas ‘ext4’.
Avec le système de table de partition (?) GPT, fdisk -l annonce, comme type de système de fichiers “Linux filesystem” (8300).
Selon ‘gdisk’ suivi de ‘l’, rien ne ressemble à ‘ext4’.

Question : Par quel code dois-je remplacer le système de fichiers ?
J’ai bien pensé à ‘Microsogft basic data’ (0700) mais avant de faire une bêtise, j’aimerais l’avis de ceux-ce qui savent.

#2

8300 n’est que l’identifiant du type de partition enregistré dans la table de partition, il ne reflète pas forcément le type du contenu de la partition (système de fichiers ou autre) et est ignoré par la plupart des outils Linux. Utilise plutôt
blkid dev/disk/by-partlabel/sauve-miniR
pour identifier le type de contenu de la partition.

Edit : vérifie aussi dans les logs du noyau avec dmesg, parfois le message d’erreur y est plus explicite.

Vieillard mémoire morte cherche fil sur Partlabel, etc
#3

/dev/disk/by-partlabel/sauve-miniR: PARTLABEL=“sauve-miniR” PARTUUID=“a59cffa2-0XXXXXXXXXXXXXXXXXXXXXX”

Pour les logs, je regarde ce soir.

#4

blkid ne détecte aucun des formats de données qu’il connaît dans cette partition. Tu es sûr qu’elle est formatée ?

Tu peux aussi l’analyser avec
file -sL /dev/disk/by-partlabel/sauve-miniR

1 J'aime
#5

file -sL /dev/disk/by-partlabel/sauve-miniR
/dev/disk/by-partlabel/sauve-miniR: data

C’est pauvre !

#6

Bingo ! ce n’était pas formaté.
Quant à savoir où l’oubli a été fait …
J’ai formaté en ext4 et :

file -sL /dev/disk/by-partlabel/sauve-miniR
/dev/disk/by-partlabel/sauve-miniR: Linux rev 1.0 ext4 filesystem data, UUID=f15a0d94-XXXXXXXXXXXXXXXX (extents) (large files) (huge files)

Je refais une sauvegarde et je confirme.

#7

Tout bon :
sauvegarde complète et démontage effectué

#8

“data” signifie que file n’a pas réussi à identifier le contenu. Ce sont des donnée de type inconnu.
Cela se produit notamment avec une partition BIOS boot, ou une partition chiffrée sans LUKS. Parfois, mais pas toujours, on peut obtenir des informations sur le contenu en recherchant les chaînes de caractères contenues dans le “fichier” (au sens large, cela peut être un disque ou une partition) avec la commande strings du paquet binutils.

#9

Oui, c’est bien ainsi que j’avais interprété cette réponse ‘data’ : “ce n’est pas vide”.

Pour le problème présent, tu avais raison, comme toujours, les partitions ont été créées avec gdisk mais je ne les avais pas formatées. Ensuite, je suis passé à autre chose de plus urgent et je n’ai plus pensé à le faire.

#10

En informatique, la notion de “vide” est relative. Un disque, une partition ou un fichier de taille non nulle n’est jamais vraiment vide puisqu’il contient un certain nombre d’octets.