Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Problème de montage d'un disque dur "ZFS"
112 views
Skip to first unread message
Nicolas FRANCOIS
Jul 6, 2021, 12:10:02 PM7/6/21
to
Bonjour.
J'ai un souci avec un disque dur dont je voudrais récupérer les
données. Celui-ci est identifié par gparted comme étant de type "zfs".
Ce qui est étrange, parce que, si je l'ai bien utilisé il y a quelques
temps pour essayer FreeNas, il servait depuis dans une bête station
Debian dans laquelle je suis sûr de l'avoir formaté en gpt. Je l'ai
installé dans ma nouvelle Debian Buster (avec backports), et je
voudrais en récupérer les données pour les transférer sur mon nouveau
NAS (un OpenMediaVault). J'y ai installé zfs-fuse, d'une part, et
zfsutils-linux d'autre part, depuis le dépôt backports.
Voici le résultat de la commande print de parted :
nico@fantasio:~$ sudo parted /dev/sda
[sudo] Mot de passe de nico :
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Error: The primary GPT table is corrupt, but the backup appears OK,
so that will be used.
OK/Cancel?
OK Model: ATA WDC WD20EZRX-00D (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 17,4kB 40,0GB 40,0GB Root msftdata
2 40,0GB 44,0GB 4000MB linux-swap(v1)
3 44,0GB 300GB 256GB ext4 SaveNico
4 300GB 690GB 390GB ext4 Music
5 690GB 1010GB 320GB ext4 Divers
6 1010GB 2000GB 990GB ext4 Partage msftdata
Et celui de la commande fdisk -l (ce qui concerne ce disque) :
La table de partitions GPT primaire est corrompue, mais la sauvegarde
semble fonctionnelle, elle sera donc utilisée.
Disque /dev/sda : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs
Modèle de disque : WDC WD20EZRX-00D
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : gpt
Identifiant de disque : A7528C40-AC86-11E2-822B-003005BB6B8B
Périphérique Début Fin Secteurs Taille Type
/dev/sda1 34 78125034 78125001 37,3G Données de base
Microsoft /dev/sda2 78125035 85937535 7812501 3,7G
Partition d'échange Linux /dev/sda3 85938176 585936895 499998720
238,4G Système de fichiers Linux /dev/sda4 585936896 1347655679
761718784 363,2G Système de fichiers Linux /dev/sda5 1347655680
1973372927 625717248 298,4G Système de fichiers Linux /dev/sda6
1973374336 3906948479 1933574144 922G Données de base Microsoft
La partition 1 ne commence pas sur une frontière de cylindre physique.
La partition 2 ne commence pas sur une frontière de cylindre physique.
Quand j'essaye de monter les partitions /dev/sdax, on me répond que le
périphérique en question n'existe pas. Mais quand j'essaye de monter le
disque en zfs, en utilisant zfs-fuse (méthode décrite à la page
https://frommelmak.com/how-to-mount-a-zfs-drive-in-linux.html), je n'ai
pas de réponse à la commande "zpool import".
Si j'essaye de suivre les instructions de la page
https://www.infotrucs.fr/monter-partition-zfs-sous-debian/, tout se
passe bien, mais que je crée un unique pool pour /dev/sda, ou un pool
par partition, les points de montage demeurent vides, alors que je sais
pertinemment qu'il y a plus de 1.5To de données sur ce disque.
Qu'est-ce que je fais de traviolle ? Quelqu'un peut m'aider ?
\bye
--
Nicolas FRANCOIS | /\
http://nicolas.francois.free.fr | |__|
X--/\\
We are the Micro$oft. _\_V
Resistance is futile.
You will be assimilated. darthvader penguin
J'ai un souci avec un disque dur dont je voudrais récupérer les
données. Celui-ci est identifié par gparted comme étant de type "zfs".
Ce qui est étrange, parce que, si je l'ai bien utilisé il y a quelques
temps pour essayer FreeNas, il servait depuis dans une bête station
Debian dans laquelle je suis sûr de l'avoir formaté en gpt. Je l'ai
installé dans ma nouvelle Debian Buster (avec backports), et je
voudrais en récupérer les données pour les transférer sur mon nouveau
NAS (un OpenMediaVault). J'y ai installé zfs-fuse, d'une part, et
zfsutils-linux d'autre part, depuis le dépôt backports.
Voici le résultat de la commande print de parted :
nico@fantasio:~$ sudo parted /dev/sda
[sudo] Mot de passe de nico :
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Error: The primary GPT table is corrupt, but the backup appears OK,
so that will be used.
OK/Cancel?
OK Model: ATA WDC WD20EZRX-00D (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 17,4kB 40,0GB 40,0GB Root msftdata
2 40,0GB 44,0GB 4000MB linux-swap(v1)
3 44,0GB 300GB 256GB ext4 SaveNico
4 300GB 690GB 390GB ext4 Music
5 690GB 1010GB 320GB ext4 Divers
6 1010GB 2000GB 990GB ext4 Partage msftdata
Et celui de la commande fdisk -l (ce qui concerne ce disque) :
La table de partitions GPT primaire est corrompue, mais la sauvegarde
semble fonctionnelle, elle sera donc utilisée.
Disque /dev/sda : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs
Modèle de disque : WDC WD20EZRX-00D
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : gpt
Identifiant de disque : A7528C40-AC86-11E2-822B-003005BB6B8B
Périphérique Début Fin Secteurs Taille Type
/dev/sda1 34 78125034 78125001 37,3G Données de base
Microsoft /dev/sda2 78125035 85937535 7812501 3,7G
Partition d'échange Linux /dev/sda3 85938176 585936895 499998720
238,4G Système de fichiers Linux /dev/sda4 585936896 1347655679
761718784 363,2G Système de fichiers Linux /dev/sda5 1347655680
1973372927 625717248 298,4G Système de fichiers Linux /dev/sda6
1973374336 3906948479 1933574144 922G Données de base Microsoft
La partition 1 ne commence pas sur une frontière de cylindre physique.
La partition 2 ne commence pas sur une frontière de cylindre physique.
Quand j'essaye de monter les partitions /dev/sdax, on me répond que le
périphérique en question n'existe pas. Mais quand j'essaye de monter le
disque en zfs, en utilisant zfs-fuse (méthode décrite à la page
https://frommelmak.com/how-to-mount-a-zfs-drive-in-linux.html), je n'ai
pas de réponse à la commande "zpool import".
Si j'essaye de suivre les instructions de la page
https://www.infotrucs.fr/monter-partition-zfs-sous-debian/, tout se
passe bien, mais que je crée un unique pool pour /dev/sda, ou un pool
par partition, les points de montage demeurent vides, alors que je sais
pertinemment qu'il y a plus de 1.5To de données sur ce disque.
Qu'est-ce que je fais de traviolle ? Quelqu'un peut m'aider ?
\bye
--
Nicolas FRANCOIS | /\
http://nicolas.francois.free.fr | |__|
X--/\\
We are the Micro$oft. _\_V
Resistance is futile.
You will be assimilated. darthvader penguin
Gaëtan Perrier
Jul 6, 2021, 5:20:03 PM7/6/21
to
J'avoue ne pas tout comprendre de ce que tu indiques.
GPT et ZFS ne sont pas antinomiques. GPT est un format de table de partitions
alors que ZFS est un système de fichier pour une partition.
Tu peux donc très bien avoir un disque avec une table GPT qui contient des
partitions ZFS.
Ensuite tu dis que gparted l'identifie comme étant ZFS mais dans la copie de
sortie de gparted je ne vois pas trace de quelque chose en ZFS ... Le disque
semble effectivement avoir une table de partitions en GPT et des partitions en
ext4, une de swap et la première qui ne semble pas formatée.
Donc normalement tu dois pourvoir monter sda 3 à 6 avec un simple mount.
Gaëtan
Hugues Larrive
Jul 6, 2021, 11:20:02 PM7/6/21
to
Bonjour,
Le mercredi 7 juillet 2021 à 00:50, Nicolas FRANCOIS <nicolas....@free.fr> a écrit :
> gparted l'identifie comme un bloc zfs, point, voir fichier joint.
> parted me donne d'autres résultats, et voit les partitions à
> l'intérieur, mais je ne peux pas les monter.
Vu qu'à la base tu dis avoir partitionné en gpt, je pense que gparted
dis n'importe quoi parce que la table principale est corrompue. C'est
aussi pour cette raison que linux ne crée pas les périphériques
correctement.
Comme tu veux juste récupérer les donnée, tu peux essayer de créer
les périphériques dont tu as besoin avec losetup en utilisant les
option --offset et --sizelimit (en octets donc il faut multiplier les
valeurs données par fdisk par la taille de secteur). Cette commande
n'est pas dangereuse en elle même, ça crée juste des nœuds de
périphérique de type block /dev/loop* utilisables comme des
/dev/sd*. Bien sûr tu ne pourras pas utiliser --partscan qui s'appuie
sur la détection des partitions par le noyau.
Autrement tu peux voir s'il est possible de restaurer le backup sur la
table principale avec parted ou fdisk (je pense qu'il suffit de
sauvegarder vu qu'ils ont l'air de la charger tout seuls) mais il y a
un risque si le disque a effectivement été "converti" en zfs, ce qui
me semble peu probable.
Maintenant que j'y pense, testdisk te permettrait peut-être de monter
tes partitions de manière assistée, c'est probablement l'outil le
plus adapté pour résoudre ton problème (mais moins "fun" que losetup).
Cordialement
Hugues
Le mercredi 7 juillet 2021 à 00:50, Nicolas FRANCOIS <nicolas....@free.fr> a écrit :
> gparted l'identifie comme un bloc zfs, point, voir fichier joint.
> parted me donne d'autres résultats, et voit les partitions à
> l'intérieur, mais je ne peux pas les monter.
Vu qu'à la base tu dis avoir partitionné en gpt, je pense que gparted
dis n'importe quoi parce que la table principale est corrompue. C'est
aussi pour cette raison que linux ne crée pas les périphériques
correctement.
Comme tu veux juste récupérer les donnée, tu peux essayer de créer
les périphériques dont tu as besoin avec losetup en utilisant les
option --offset et --sizelimit (en octets donc il faut multiplier les
valeurs données par fdisk par la taille de secteur). Cette commande
n'est pas dangereuse en elle même, ça crée juste des nœuds de
périphérique de type block /dev/loop* utilisables comme des
/dev/sd*. Bien sûr tu ne pourras pas utiliser --partscan qui s'appuie
sur la détection des partitions par le noyau.
Autrement tu peux voir s'il est possible de restaurer le backup sur la
table principale avec parted ou fdisk (je pense qu'il suffit de
sauvegarder vu qu'ils ont l'air de la charger tout seuls) mais il y a
un risque si le disque a effectivement été "converti" en zfs, ce qui
me semble peu probable.
Maintenant que j'y pense, testdisk te permettrait peut-être de monter
tes partitions de manière assistée, c'est probablement l'outil le
plus adapté pour résoudre ton problème (mais moins "fun" que losetup).
Cordialement
Hugues
didier gaumet
Jul 7, 2021, 3:40:03 AM7/7/21
to
Pour compléter ce qui a été dit et bien que je sois vraiment pas très
connaisseur de toutes ces choses (donc ne pas accepter mes
élucubrations comme parles d'évangile),
je me demanderais si la table GPT est véritablement corrompue ou si le
parted de Debian la désigne comme telle: Freenas/Truenas c'est du BSD,
je pense que le monde BSD s'est mis à GPT plus tard que le monde Linux
et qu'il traîne potentiellement avec lui des éléments anciens (slices,
couche de compatibilité MBR dans le GPT). De plus en termes de systèmes
de fichiers on évoque possiblement la récupération avec l'OpenZFS de
Debian de données crées avec le ZFS de Freenas (si j'ai bien compris,
au début mais ça a changé récemment, d'origine SunOS/Solaris,
différente de la branche OpenZFS), donc avec de possibles(?)
incohérences.
Dans un premier temps, j'essaierais d'utiliser un live*BSD récent
(NomadBSD? déjà que je n'étais pas très au courant de *BSD, ça fait des
années que j'ai décroché) pour voir si je peux voir mes données et les
sauvegarder sous une forme récupérable de manière fiable sous Debian.
Au cas où les données ne seraient pas visibles, j'essaierais un support
*BSD plus ancien si le Freenas qui a été utilisé pour créer les données
était ancien aussi.
Bon, ceci dit, compte-tenu de mon immense expertise du domaine, je
comprendrais que mes suggestions soient accueillies par un haussement
d'épaules ;-)
connaisseur de toutes ces choses (donc ne pas accepter mes
élucubrations comme parles d'évangile),
je me demanderais si la table GPT est véritablement corrompue ou si le
parted de Debian la désigne comme telle: Freenas/Truenas c'est du BSD,
je pense que le monde BSD s'est mis à GPT plus tard que le monde Linux
et qu'il traîne potentiellement avec lui des éléments anciens (slices,
couche de compatibilité MBR dans le GPT). De plus en termes de systèmes
de fichiers on évoque possiblement la récupération avec l'OpenZFS de
Debian de données crées avec le ZFS de Freenas (si j'ai bien compris,
au début mais ça a changé récemment, d'origine SunOS/Solaris,
différente de la branche OpenZFS), donc avec de possibles(?)
incohérences.
Dans un premier temps, j'essaierais d'utiliser un live*BSD récent
(NomadBSD? déjà que je n'étais pas très au courant de *BSD, ça fait des
années que j'ai décroché) pour voir si je peux voir mes données et les
sauvegarder sous une forme récupérable de manière fiable sous Debian.
Au cas où les données ne seraient pas visibles, j'essaierais un support
*BSD plus ancien si le Freenas qui a été utilisé pour créer les données
était ancien aussi.
Bon, ceci dit, compte-tenu de mon immense expertise du domaine, je
comprendrais que mes suggestions soient accueillies par un haussement
d'épaules ;-)
didier...@gmail.com
Jul 7, 2021, 11:00:03 AM7/7/21
to
et puis tout à coup je me rappelle avoir lu quelque part que Freenas
avait abandonné FreeBSD pour Debian il y a peu de temps. Donc si ton
Freenas était basé sur Debian, tout ce que j'ai raconté était hors
propos...
avait abandonné FreeBSD pour Debian il y a peu de temps. Donc si ton
Freenas était basé sur Debian, tout ce que j'ai raconté était hors
propos...
Hugues Larrive
Jul 7, 2021, 11:40:03 AM7/7/21
to
Le mercredi 7 juillet 2021 à 09:29, didier gaumet <didier...@gmail.com> a écrit :
> je me demanderais si la table GPT est véritablement corrompue ou si le
> parted de Debian la désigne comme telle: Freenas/Truenas c'est du BSD,
> je pense que le monde BSD s'est mis à GPT plus tard que le monde Linux
> et qu'il traîne potentiellement avec lui des éléments anciens (slices,
> couche de compatibilité MBR dans le GPT).
Je connais un peu GPT pour m'être battu avec il y a des années en
> je me demanderais si la table GPT est véritablement corrompue ou si le
> parted de Debian la désigne comme telle: Freenas/Truenas c'est du BSD,
> je pense que le monde BSD s'est mis à GPT plus tard que le monde Linux
> et qu'il traîne potentiellement avec lui des éléments anciens (slices,
> couche de compatibilité MBR dans le GPT).
installant des dual boot sur les premiers mac à processeurs intel.
Pour ce qui concerne la couche de compatibilité MBR le premier secteur
est sensé contenir une table de partition MBR factice avec une unique
partition de type GPT occupant tout le disque afin qu'un outil de
partitionnement n'implémentant pas GPT ne le considère pas comme vierge.
Cette table était "bidouillée" par bootcamp sur les mac pour permettre à
windows (qui n'implémentait pas GPT) de trouver ses partitions...
GPT est un système robuste avec checksum et backup et de mémoire il me
semble que la moindre modification "sauvage" du mbr faussait le
checksum et invalidait ainsi la table GPT principale. Il est possible
que linux n'en tienne pas compte quand il s'agit du disque de démarrage
et qu'il soit plus exigeant pour un disque secondaire...
Si j'ai bien compris ce disque a été repartitionné après son utilisation
avec freenas et tu cherches juste à pouvoir monter tes partition pour
récupérer tes données.
D'après ce que j'ai vu dans tes sorties de parted et fdisk, la table
"backup" semble correcte hormis le type de la dernière partition qui
est incohérent avec le système de fichier ext4 détecté par parted.
En reprenant la sortie de fdisk -l dans ton premier message :
Unités : secteur de 1 × 512 = 512 octets
...
Périphérique Début Fin Secteurs Taille Type
/dev/sda1 34 78125034 78125001 37,3G Données de base Microsoft
/dev/sda2 78125035 85937535 7812501 3,7G Partition d'échange Linux
/dev/sda3 85938176 585936895 499998720 238,4G Système de fichiers Linux
/dev/sda4 585936896 1347655679 761718784 363,2G Système de fichiers Linux
/dev/sda5 1347655680 1973372927 625717248 298,4G Système de fichiers Linux
/dev/sda6 1973374336 3906948479 1933574144 922G Données de base Microsoft
Pour sda1 parted n'a pas détecté de système de fichier donc "c'est mort".
/dev/sda1 34 78125034 78125001 37,3G Données de base Microsoft
/dev/sda2 78125035 85937535 7812501 3,7G Partition d'échange Linux
/dev/sda3 85938176 585936895 499998720 238,4G Système de fichiers Linux
/dev/sda4 585936896 1347655679 761718784 363,2G Système de fichiers Linux
/dev/sda5 1347655680 1973372927 625717248 298,4G Système de fichiers Linux
/dev/sda6 1973374336 3906948479 1933574144 922G Données de base Microsoft
sda2 je pense qu'on s'en moque...
Pour sda3 :
# losetup --offset $((85938176*512)) --sizelimit $((499998720*512)) /dev/loop0 /dev/sda
# e2fsck -nf /dev/loop0
devrait donner quelque chose du genre :
e2fsck 1.44.5 (15-Dec-2018)
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l'information du sommaire de groupe
SaveNico : xxx/xxxxxxxx fichiers (x.x% non contigus), xxx/xxxxxxxx blocs
Jusque-là il n'y a aucun risque, losetup ne touche pas à ton disque (il se
contente d'en "mapper" une portion dans /dev) et e2fsck non plus avec
l'option -n.
Si le volume est propre il n'y a plus qu'à le monter :
# mkdir /mnt/SaveNico
# mount /dev/loop0 /mnt/SaveNico
Une fois les fichiers récupérés :
# umount /dev/loop0
# rmdir /mnt/SaveNico
# losetup -d /dev/loop0
Pour sda4 utiliser :
--offset $((585936896*512)) --sizelimit $((761718784*512))
Et ainsi de suite en prenant à chaque fois le secteur de "Début" pour
offset et le nombre "Secteurs" pour sizelimit.
Tu peux en faire plusieurs en même temps en utilisant /dev/loop1 etc.
Cordialement
Hugues
Bernard Schoenacker
Jul 7, 2021, 1:20:03 PM7/7/21
to
----- Mail original -----
> De: "didier gaumet" <didier...@gmail.com>
> À: debian-us...@lists.debian.org
> Envoyé: Mercredi 7 Juillet 2021 16:38:25
> Objet: Re: Re: Problème de montage d'un disque dur "ZFS"
Je suis vraiment navré de devoir jouer le chieur de petits
points, mais ce que tu affirmes ne concerne n'est pas encore
en route complètement, pour mémoire voici la page de
Wikipedia sur TrueNas :
https://fr.wikipedia.org/wiki/TrueNas
En revanche, la prochaine version de TrueNas se basera sur une Debian
version 11 et je viens de vérifier la nouvelle via "ars technica"
https://arstechnica.com/gadgets/2020/06/truenas-isnt-abandoning-bsd-but-it-is-adopting-linux/
et l'annonce de la préversion téléchargeable :
https://www.cachem.fr/truenas-core-12-disponible-rc-scale/
Par conséquent, la version Debian nommée Scale ne sera opérationnelle
et stabilisée qu'à partir de la fin de l'été (c'est mon impression
personnelle) ...
Voici l'ensemble des versions pour TrueNas :
TrueNAS Core: FreeBSD
TrueNAS Enterprise: FreeBSD
TrueNAS SCALE: Linux
Merci pour ton aimable billet
Bien à toi
Bernard
didier gaumet
Jul 7, 2021, 2:40:03 PM7/7/21
to
Le mercredi 07 juillet 2021 à 19:13 +0200, Bernard Schoenacker a
écrit :
>
> Bonjour Didier,
>
> Je suis vraiment navré de devoir jouer le chieur de petits
> points
[...]
> Bonjour Didier,
>
> Je suis vraiment navré de devoir jouer le chieur de petits
> points
Ben , faut pas être navré: quand je raconte des conn... des fadaises,
j'aime bien qu'on rectifie gentiment, donc merci pour les précisions
:-)
Gaëtan Perrier
Jul 7, 2021, 3:30:02 PM7/7/21
to
Le mercredi 07 juillet 2021 à 00:50 +0200, Nicolas FRANCOIS a écrit :
> Le Tue, 06 Jul 2021 23:13:57 +0200,
> Gaëtan Perrier <gaetan....@neuf.fr> a écrit :
différentes alors qu'ils se basent tous les deux libparted2.
J'ai pensais, à tort, que ta copie de parted illustrait ton propos sur gparted.
Toutes mes confuses,
Gaëtan
> Le Tue, 06 Jul 2021 23:13:57 +0200,
> Gaëtan Perrier <gaetan....@neuf.fr> a écrit :
>
> > Bonjour,
> >
> > J'avoue ne pas tout comprendre de ce que tu indiques.
> > GPT et ZFS ne sont pas antinomiques. GPT est un format de table de
> > partitions alors que ZFS est un système de fichier pour une partition.
> > Tu peux donc très bien avoir un disque avec une table GPT qui
> > contient des partitions ZFS.
>
> Jusque là, je comprends.
> > Bonjour,
> >
> > J'avoue ne pas tout comprendre de ce que tu indiques.
> > GPT et ZFS ne sont pas antinomiques. GPT est un format de table de
> > partitions alors que ZFS est un système de fichier pour une partition.
> > Tu peux donc très bien avoir un disque avec une table GPT qui
> > contient des partitions ZFS.
>
>
> > Ensuite tu dis que gparted l'identifie comme étant ZFS mais dans la
> > copie de sortie de gparted je ne vois pas trace de quelque chose en
> > ZFS ... Le disque semble effectivement avoir une table de partitions
> > en GPT et des partitions en ext4, une de swap et la première qui ne
> > semble pas formatée.
>
> > Ensuite tu dis que gparted l'identifie comme étant ZFS mais dans la
> > copie de sortie de gparted je ne vois pas trace de quelque chose en
> > ZFS ... Le disque semble effectivement avoir une table de partitions
> > en GPT et des partitions en ext4, une de swap et la première qui ne
> > semble pas formatée.
>
> gparted l'identifie comme un bloc zfs, point, voir fichier joint.
>
> parted me donne d'autres résultats, et voit les partitions à
> l'intérieur, mais je ne peux pas les monter.
Ok je ne pensais pas que les sorties de parted et gparted puissent être
>
> parted me donne d'autres résultats, et voit les partitions à
> l'intérieur, mais je ne peux pas les monter.
différentes alors qu'ils se basent tous les deux libparted2.
J'ai pensais, à tort, que ta copie de parted illustrait ton propos sur gparted.
Toutes mes confuses,
Gaëtan
0 new messages