perte de partition, suite à arrêt de redimensionnement de la partition

herodote k210 · Le 17/11/2018, à 02:57

Bonjour à tous,
J'ai un ordinateur sous ubuntu 16.04 et deux disques durs
j'ai voulu récupérer de la place sur un second Disque dur de 1 TO qui est récent
J'avais une partition data et une autre non utilisé pour pouvoir y installer une distribution au cas où.
J'ai voulu la supprimer avec gparted et ré-allouer l'espace à la partition data, j'ai lancé l'opération et en cours j'ai arrêté par inadvertance l'opération.
Maintenant gparted m'indique que j'ai 830go non alloués et que je dois les formater.
j'ai lu ici que l'on peut tenter de récupérer les informations et la partition avec testdisk.
Est ce la seule solution?

bluc · Le 17/11/2018, à 04:52

Bonjour
voila comme j'ai fait avec Testdisk

,ça fonctionne quand on a supprimé une partition par erreur

je n'ai pas bien compris,
Tu souhaitais supprimer cette partition data, donc vide certainement ,alors pourquoi vouloir la récupérer ?...
on récupère une partition qui contient des fichiers a cause des fichiers

Dernière modification par bluc (Le 17/11/2018, à 04:54)

herodote k210 · Le 17/11/2018, à 12:35

Bonjour Bluc,
en fait je voulais élargir une première partition data en supprimant une partition qui ne servait à rien .
Lors du processus j'ai malencontreusement interrompu celui-ci en me trompant de bouton et donc la partition data a disparu du tableau, des partitions dans Gparted.
En tout cas merci de ta solution, j'ai lu plusieurs sujets à propos de test disque je voulais savoir s'il n'y avait pas d'autre solution donc je vais lire ton sujet tenter de résoudre le problème avec TestDisk.
Jean Marc.

herodote k210 · Le 17/11/2018, à 22:45

J'ai regardé toute la documentation et les sujets concernant testdisk, certains conseil de le faire en live usb.
On a une partition qui apparaît après quicksearch et avant de taper write, là on peut accéder à la partition et faire une sauvegarde?

bluc · Le 18/11/2018, à 00:07

Oui il faut le faire en live
quand je l'ai utilisé , j'ai vraiment été surpris du résultat ,et c'est vraiment tres simple
je te souhaite la même chose

quand on choisis write,la partition réapparaît ou elle était

Dernière modification par bluc (Le 18/11/2018, à 00:08)

herodote k210 · Le 18/11/2018, à 00:34

La partition est réapparue mais je ne peux y accéder que partiellement, uniquement via l'icône du bureau et pas par le menu du gestionnaire fichier, et de plus certains fichiers ne sont pas accessibles ou n'apparaissent même pas.
Ubuntu me dit que la structure a besoin d'un nettoyage.

Dernière modification par herodote k210 (Le 18/11/2018, à 01:22)

bluc · Le 18/11/2018, à 01:46

Est ce qu'il t'es possible de sauvegarder sur un autre support dd-usb le maximum de données
et peut être de faire depuis gparted >> Périphérique >> Tenter une récupération des données , mais je ne te garanti rien , je n'ai jamais utilisé

herodote k210 · Le 18/11/2018, à 01:53

Je vais acheter un DD. Et voir ce que cela donne.

Mais l'affirmation du "nettoyage de la structure de la partition", est pas très claire, j'obtiens cela quand je veux accéder à la partition.
J'ai fait une recherche et je n'ai rien trouvé à ce sujet

moko138 · Le 18/11/2018, à 05:46

herodote k210,
Avant tout, désactive, dans les préférences de ton gestionnaire de fichiers, le montage automatique des périphériques amovibles !
Dans l'état où est la partition, il faut éviter à tout prix un fsck sur elle ! (le "nettoyage de la structure de la partition".) (S'il n'est pas trop tard).
Le plus sûr est encore de NE PAS brancher ton DDE.

Tu n'aurais rien dû valider dans testdisk (car si je comprends bien tu as fait un "write") avant d'avoir vu tes fichiers à l'étape "L" (Lister les éléments).
CORRECTION : "P: list files" (=lister les éléments).
FIN de correction

L'aide d'un expert t'est nécessaire pour agir efficacement et ne plus rien faire d'irrémédiable.
Donc contactes-en un.

Non, il n'y avait pas besoin de passer en live, puisque ça se passait sur un disque autre que celui du système.
Et au moins, on disposerait du fichier testdisk.log.
D'ailleurs, si tu as utilisé une live persistante, et que tu as laissé cochée l'option "Create a log", tu le trouveras dans le home de ta live. S'il existe, colle son contenu ici ou, s'il est trop gros, téléverse le fichier chez un hébergeur, comme cjoint.com ou pastebin.

Dernière modification par moko138 (Le 18/11/2018, à 16:01)

moko138 · Le 18/11/2018, à 09:16

Pour comprendre l'état du système de fichiers, il faut avoir bien présent à l'esprit le caractère multicouches d'un disque en fonction :

Couche 1 : c'est le disque (support matériel).

Couche 2 : ce sont les frontières de la partition ("s'étend du point A au point B"), en tant que récipient, sans idée de formatage.

Couche 3 : c'est le système de fichiers (FS) (ext4 ou autre).

Couche 4 : ce sont les données. Elles sont supportées par la couche 3.

- -

En général, les couches 2 et 3 font la même taille, mais
- ce n'est pas obligatoire : on peut très bien mettre un FS de 500 Go dans une partition de 1000 Go ;
- c'est toujours faux pendant un redimensionnement.
> si on a demandé un agrandissement, il faut agrandir d'abord le récipient (couche 2)
> si on a demandé une réduction, il faut rétrécir d'abord le contenu (couche 3).
> /!\ si on a demandé un déplacement, gparted procède en de nombreuses étapes, dont (je simplifie) les 4 temps suivants :
agrandir le récipient d'un côté (instantané) ;
agrandir le FS du même côté ;
rétrécir le FS du second côté ;
rétrécir le récipient du second côté (instantané).

La seule opération longue, c'est le déplacement du début du FS, car c'est tout le FS qui, morceau après morceau, est déplacé avec lui.
Avec un disque rotatif, prévoir environ une minute par Gio, soit une 15aine d'heures pour 1To !

Application :
Voici un compte-rendu, réel mais abrégé, de gparted
(en bleu et en romains : la couche "frontières",
en vert et en italiques : la couche FS).

Déplacer /dev/sdc4 vers la gauche et l'agrandir de 93.16 Gio à 118.85 Gio 03h16'38"
calibrer /dev/sdc4 00:00:01
calcule la nouvelle taille et position de /dev/sdc4 00:00:00

vérifier le système de fichiers sur /dev/sdc4 et corriger les problèmes (si possible) 00:00:34"
e2fsck -f -y -v /dev/sdc4

agrandit la partition de 93.16 Gio à 118.85 Gio 00:00:02

déplacer le système de fichiers vers la gauche 03:13:24
effectuer le test en lecture seule 01:01:11
effectue le déplacement réel 02:12:13

réduit la partition de 118.85 Gio à 93.16 Gio 00:00:02
calcule la nouvelle taille et position de /dev/sdc4 00:00:01

vérifier le système de fichiers sur /dev/sdc4 et corriger les problèmes (si possible) 00:00:48
e2fsck -f -y -v /dev/sdc4

agrandit la partition de 93.16 Gio à 118.85 Gio 00:00:02

vérifier le système de fichiers sur /dev/sdc4 et corriger les problèmes (si possible) 00:00:47
   e2fsck -f -y -v /dev/sdc4
agrandir le système de fichiers pour remplir la partition 00:00:57
   resize2fs /dev/sdc4
      En train de redimensionner le système de fichiers sur /dev/sdc4 à 31156059 (4k) blocs.
      Le système de fichiers /dev/sdc4 a maintenant une taille de 31156059 blocs.
==============

Concernant ton DDE, herodote k210, nous ignorons
- à quel stade les opérations ont été interrompues ;
- comment testdisk a procédé.
Voilà pourquoi je t'invite à ne rien faire sans le guidage par un expert.

herodote k210 · Le 18/11/2018, à 13:53

Bonjour Moko138,
donc pour te répondre voici ton message et mes réponses:

moko138 a écrit :

herodote k210,
Avant tout, désactive, dans les préférences de ton gestionnaire de fichiers, le montage automatique des périphériques amovibles !
Dans l'état où est la partition, il faut éviter à tout prix un fsck sur elle ! (le "nettoyage de la structure de la partition".) (S'il n'est pas trop tard).
Le plus sûr est encore de NE PAS brancher ton DDE.

J'ai débranché mon DDE comme tu me l'as indiqué.
Je me suis abstenu de lancer fsck, je ne savait qu'il y avait un lien entre le montage d'un périphérique amovible et la vérification par fsck.

moko138 a écrit :

Tu n'aurais rien dû valider dans testdisk (car si je comprends bien tu as fait un "write") avant d'avoir vu tes fichiers à l'étape "L" (Lister les éléments).

L'aide d'un expert t'est nécessaire pour agir efficacement et ne plus rien faire d'irrémédiable.
Donc contactes-en un.
.

Je n'avais pas vu la mention L pour liste, mais uniquement celle L pour logical, dans le choix du "format" de la partition. (D'ailleurs il se mêle des protocoles window et unix (fat, ntfs pour ext, boot...)

je vais faire appel à un expert.

Mais penses tu que au moins pour une fois je peux rebrancher mon DDE pour faire une sauvegarde sur un autre?

J'ai à peu près 85% de récupéré, dont une grande part de ce qui importe voire même la majeure partie.

moko138 a écrit :

Non, il n'y avait pas besoin de passer en live, puisque ça se passait sur un disque autre que celui du système.
Et au moins, on disposerait du fichier testdisk.log.
D'ailleurs, si tu as utilisé une live persistante, et que tu as laissé cochée l'option "Create a log", tu le trouveras dans le home de ta live. S'il existe, colle son contenu ici ou, s'il est trop gros, téléverse le fichier chez un hébergeur, comme cjoint.com ou pastebin.

Je ne l'ai pas fais en live et je suis passé par la mention "create log" donc je dois avoir un log quelque part, je vais le trouver et le mettre en lien.
Sur ma home je n'ai pas vu de fichier .testdisk

Et un grand merci pour ton second message, il a clarifié certains fait, je pensais que déplacer les cloisons d'une partition, déplaçait en même temps le système fichier.

Dernière modification par herodote k210 (Le 18/11/2018, à 14:02)

herodote k210 · Le 18/11/2018, à 14:04

J'ai trouvé avec la fonction recherche:

Sun Nov 18 01:08:47 2018
Command line: TestDisk
TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
OS: Linux, kernel 4.4.0-139-generic (#165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018) x86_64
Compiler: GCC 5.3
ext2fs lib: 1.42.13, ntfs lib: libntfs-3g, reiserfs lib: none, ewf lib: none, curses lib: ncurses 6.0
/dev/sda: LBA, HPA, LBA48, DCO support
/dev/sda: size 976773168 sectors
/dev/sda: user_max 976773168 sectors
/dev/sda: native_max 976773168 sectors
/dev/sda: dco 976773168 sectors
/dev/sdb: LBA, HPA, LBA48, DCO support
/dev/sdb: size 1953525168 sectors
/dev/sdb: user_max 1953525168 sectors
/dev/sdb: native_max 1953525168 sectors
/dev/sdb: dco 1953525168 sectors
Warning: can't get size for Disk /dev/mapper/control - 0 B - 0 sectors, sector size=512
Hard disk list
Disk /dev/sda - 500 GB / 465 GiB - CHS 60801 255 63, sector size=512 - ST3500312CS, S/N:9VV78L92, FW:SS16
Disk /dev/sdb - 1000 GB / 931 GiB - CHS 121601 255 63, sector size=512 - ST31000524NS, S/N:9WK42JP7, FW:AV22
Partition table type (auto): Intel
Disk /dev/sdb - 1000 GB / 931 GiB - ST31000524NS
Partition table type: Intel
Interface Advanced
Geometry from i386 MBR: head=255 sector=63
1 * Linux Swap 0 32 33 127 122 59 2045952
SWAP2 version 1, pagesize=4096, 1047 MB / 999 MiB
2 P Linux 127 122 60 117139 90 7 1879795712
ext4 blocksize=4096 Large_file Sparse_SB Recover, 962 GB / 896 GiB
New options :
Dump : No
Align partition: Yes
Expert mode : No
Interface Advanced
Geometry from i386 MBR: head=255 sector=63
1 * Linux Swap 0 32 33 127 122 59 2045952
SWAP2 version 1, pagesize=4096, 1047 MB / 999 MiB
2 P Linux 127 122 60 117139 90 7 1879795712
ext4 blocksize=4096 Large_file Sparse_SB Recover, 962 GB / 896 GiB
TestDisk exited normally.

moko138 · Le 18/11/2018, à 16:23

Ce n'était pas "L" mais "P: list files" (=lister les éléments), je viens de corriger mon erreur du #9.
Tu le verras dans l'indispensable tutoriel de l'auteur du logiciel, en
https://www.cgsecurity.org/wiki/TestDis … _par_Etape
- -

Bravo pour le log retrouvé !
Bizarrement, je n'y vois pas de "write".

- -

penses tu que au moins pour une fois je peux rebrancher mon DDE pour faire une sauvegarde sur un autre?
J'ai à peu près 85% de récupéré

Le fsck peut être automatique, mais il est quasi systématique quand le système, au moment de monter le système de fichiers, détecte un problème.
EDIT
Voir le 2ème message de jamesbad0000 ci-dessous.
FIN d'édit.

Donc non, ne fais pas de montage.

...Ou alors seulement en lecture seule. Ce qui implique :
- désactiver le montage auto (déjà dit)
- vérifier avec une banale clef usb, que c'est bien désactivé.
- s'exercer à monter (et démonter) la clef usb en lecture seule, genre

mkdir /tmp/test
sudo mount -v -t auto -o ro /dev/sdb1   /tmp/test

sudo umount -v /tmp/test

quand tu es prêt, clef démontée et débranchée,
brancher le DDE et, en remplaçant X par ce qui va bien, tenter

sudo mount -v -t auto -o ro /dev/sdX2   /tmp/test

sudo umount -v /tmp/test

mais si ça renâcle, n'insiste surtout pas !

Dernière modification par moko138 (Le 19/11/2018, à 07:20)

moko138 · Le 19/11/2018, à 00:48

Merci beaucoup, jamesbad000 !

jamesbad000 · Le 19/11/2018, à 00:52

Bonsoir.

Pourrais tu préciser si ton opération interrompue comportait un déplacement de la partition ou un agrandissement par la gauche. (Ce qui dans les 2 cas implique un changement de la position de début !)
Et un ordre de grandeur du temps écoulé avant l'interruption.

Dans tous les cas je te conseille de cesser toute manipulation intempestive.
Merci de préciser également l'importance que tu attache aux données à récupérer

Tu donnera aussi, en connectant le disque concerné par l'incident après démarrage complet de linux) le retour de :

sudo lsblk -o size,name,fstype,label,mountpoint
ls -l /dev/disk/by-id

moko138 a écrit :

Le fsck peut être automatique, mais il est quasi systématique quand le système, au moment de monter le système de fichiers, détecte un problème.

Jamais vu linux faire automatiquement un fsck en dehors du démarrage du système, et à condition que le disque soit répertorié dans fstab.

Dernière modification par jamesbad000 (Le 19/11/2018, à 01:13)

moko138 · Le 19/11/2018, à 07:14

Oups ! Merci de la précision ! Je raye, plus haut.

herodote k210 · Le 19/11/2018, à 19:14

Bonjour jamesbad000
donc pour te répondre et merci pour ta silicitude ainsi qu'à moko :

jamesbad000 a écrit :

Bonsoir.
Pourrais tu préciser si ton opération interrompue comportait un déplacement de la partition ou un agrandissement par la gauche. (Ce qui dans les 2 cas implique un changement de la position de début !)
Et un ordre de grandeur du temps écoulé avant l'interruption.

J' agrandissait vers la gauche ma partition, il y avait une partition vide de 37GO que voulais réserver à une distribution.

Le temps écoulé correspond à environ 50 mn et il ne restait que moins d'1h20.
Donc si je comprends bien et que je ne savais pas lors d'une extension de partition, les éléments sont déplacés bloc par bloc et quasi matériellement les éléments de fichiers qui sont en début, donc ce qui commencent par la lettre A sont déplacés en premier?

jamesbad000 a écrit :

Dans tous les cas je te conseille de cesser toute manipulation intempestive.
Merci de préciser également l'importance que tu attache aux données à récupérer

En fait ce qui m'importe le plus m'est accessible, en fait des heures de vidéos de grands magiciens cartes, pièces,... Et certaines sont rares. J'ai des livres récupérés par un peu tous les moyens.

J'ai récupéré par le write, qui n'apparaît pas environ 85%, il me manque un fichier "livre de magie" que j'ai en double et un fichier de 100 GO environ d'enregistrements de dwhelper des documentaire arte et france TV certains sont intéressants. Leur perte est tout de même secondaire.

jamesbad000 a écrit :

B
moko138 a écrit :
Le fsck peut être automatique, mais il est quasi systématique quand le système, au moment de monter le système de fichiers, détecte un problème.
Jamais vu linux faire automatiquement un fsck en dehors du démarrage du système, et à condition que le disque soit répertorié dans fstab.

Bizarrement dans l'écriture au début de ce DDE je n'ai pas obtenu un montage automatique, il est reconnu, mais il faut que je le monte à chaque fois.

jamesbad000 a écrit :

Bonsoir.
Tu donnera aussi, en connectant le disque concerné par l'incident après démarrage complet de linux) le retour de :
sudo lsblk -o size,name,fstype,label,mountpoint
ls -l /dev/disk/by-id

Le retour des commandes:

jean-marc@gargantua:~$ sudo lsblk -o size,name,fstype,label,mountpoint
  SIZE NAME   FSTYPE LABEL MOUNTPOINT
465,8G sda                 
  3,7G ├─sda1 swap         [SWAP]
 23,3G ├─sda2 ext4         /
 23,3G ├─sda3 ext4         
    1K ├─sda4              
415,5G └─sda5 ext4         /data
931,5G sdb                 
  999M ├─sdb1 swap         
896,4G └─sdb2 ext4         /media/jean-marc/a129a72a-2c70-4b0d-bade-4a6d122c621c
 1024M sr0                 
jean-marc@gargantua:~$

et

total 0
lrwxrwxrwx 1 root root  9 nov.  19 16:59 ata-Optiarc_DVD_RW_AD-7200S -> ../../sr0
lrwxrwxrwx 1 root root  9 nov.  19 16:59 ata-ST31000524NS_9WK42JP7 -> ../../sdb
lrwxrwxrwx 1 root root 10 nov.  19 16:59 ata-ST31000524NS_9WK42JP7-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 nov.  19 16:59 ata-ST31000524NS_9WK42JP7-part2 -> ../../sdb2
lrwxrwxrwx 1 root root  9 nov.  19 16:59 ata-ST3500312CS_9VV78L92 -> ../../sda
lrwxrwxrwx 1 root root 10 nov.  19 16:59 ata-ST3500312CS_9VV78L92-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 nov.  19 16:59 ata-ST3500312CS_9VV78L92-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 nov.  19 16:59 ata-ST3500312CS_9VV78L92-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 nov.  19 16:59 ata-ST3500312CS_9VV78L92-part4 -> ../../sda4
lrwxrwxrwx 1 root root 10 nov.  19 16:59 ata-ST3500312CS_9VV78L92-part5 -> ../../sda5
lrwxrwxrwx 1 root root  9 nov.  19 16:59 usb-Generic-_Compact_Flash_20021111153705700-0:0 -> ../../sdc
lrwxrwxrwx 1 root root  9 nov.  19 16:59 usb-Generic-_MS_MS-Pro_20021111153705700-0:3 -> ../../sdf
lrwxrwxrwx 1 root root  9 nov.  19 16:59 usb-Generic-_SD_MMC_20021111153705700-0:2 -> ../../sde
lrwxrwxrwx 1 root root  9 nov.  19 16:59 usb-Generic-_SM_xD-Picture_20021111153705700-0:1 -> ../../sdd
lrwxrwxrwx 1 root root  9 nov.  19 16:59 wwn-0x5000c5002e28ae51 -> ../../sdb
lrwxrwxrwx 1 root root 10 nov.  19 16:59 wwn-0x5000c5002e28ae51-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 nov.  19 16:59 wwn-0x5000c5002e28ae51-part2 -> ../../sdb2
lrwxrwxrwx 1 root root  9 nov.  19 16:59 wwn-0x5000c500363f4f2a -> ../../sda
lrwxrwxrwx 1 root root 10 nov.  19 16:59 wwn-0x5000c500363f4f2a-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 nov.  19 16:59 wwn-0x5000c500363f4f2a-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 nov.  19 16:59 wwn-0x5000c500363f4f2a-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 nov.  19 16:59 wwn-0x5000c500363f4f2a-part4 -> ../../sda4
lrwxrwxrwx 1 root root 10 nov.  19 16:59 wwn-0x5000c500363f4f2a-part5 -> ../../sda5

Dernière modification par herodote k210 (Le 19/11/2018, à 19:21)

jamesbad000 · Le 19/11/2018, à 19:50

Bonsoir.
Un déplacement ou tout mouvement de la position de début (agrandissement/rétrécissement par la gauche) est le cas le plus défavorable qui entraîne un déplacement de la totalité du système de fichier.

L'agrandissement par la droite lui n'implique pas de mouvement, et le rétrécissement par la droite n'impacte le déplacement que de ce qui est en dépassement.

Dans ton cas, le système de fichier se trouve coupé en 2. Il sera très compliqué de recoller les morceaux même si ce n'est pas impossible.

herodote k210 a écrit :

les éléments de fichiers qui sont en début, donc ce qui commencent par la lettre A sont déplacés en premier?

L'ordre alphabétique est sans objet pour ce qui est de l'emplacement des segments de fichiers. Et le début d'un fichier peut être à la fin de la partition, alors même que la fin du fichier se trouve au début.
Ce qui prévaut c'est l'ordre d'arrivé et la place disponible. Même si ext4 fait tout de même des efforts pour que les différents segments d'un même fichiers se trouvent dans des régions proches (facile quand c'est vide. Impossible quand ça a été bien remplie, et qu'on supprime en ne laissant que des petits trous un peu partout)

A noter que dans ta situation, il est hautement probable que certains fichiers récupérés soient totalement corrompus (un inode, déplacé qui référence un segment de fichier à +10Go du nouveau début de partition alors que celui-ci est encore à + 10Go de l'ancien début de partition par exemple)

Maintenant la question est : serais tu prêt à passer des heures sur plusieurs jours pour tenter de récupérer ce qui manque, sans être certain qu'on y arrivera ?

Dernière modification par jamesbad000 (Le 19/11/2018, à 20:03)

herodote k210 · Le 19/11/2018, à 20:24

Oui!
Déjà stabiliser et dé- corrompre puis sauvegarder ce que j'ai et aussi retrouver ce que j'ai perdu.

Dernière modification par herodote k210 (Le 19/11/2018, à 20:26)

jamesbad000 · Le 19/11/2018, à 20:59

Bah ca va être un tout.
La difficulté étant de trouver ou se trouvent la borne de fin du morceau de gauche, et la borne de début du morceau de droite. La suite n'est qu'une affaire de technique comme disent les grands maîtres aux échecs...

Si tu avais dans un coin un résultat de fdisk ou parted faisant apparaitre l'ancien partitionnement de ton disque ça pourrait aider (j'ai cherché dans tes post, et trouvé un rapport boot info, mais il n'y avait pas ton disque externe dedans)

Petite collecte d'info pour commencer

sudo lsb_release -a
sudo uname -a
mke2fs -V
sudo fdisk -l /dev/disk/by-id/wwn-0x5000c5002e28ae51
sudo dumpe2fs -h /dev/disk/by-id/wwn-0x5000c5002e28ae51-part2

Dernière modification par jamesbad000 (Le 19/11/2018, à 21:09)

herodote k210 · Le 19/11/2018, à 21:21

A l'achat et après partitionnement j'avais fait une analyse de données smart, en 2017, je ne sais pas si gparted enregistre ces logs .

En retour:

jean-marc@gargantua:~$ sudo lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.5 LTS
Release:	16.04
Codename:	xenial
jean-marc@gargantua:~$

puis:

jean-marc@gargantua:~$ sudo uname -a
Linux gargantua 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
jean-marc@gargantua:~$

ensuite:

jean-marc@gargantua:~$ mke2fs -V
mke2fs 1.42.13 (17-May-2015)
	Utilisation de EXT2FS Library version 1.42.13
jean-marc@gargantua:~$

Par suite: sudo fdisk -l /dev/disk/by-id/wwn-0x5000c5002e28ae51
prend du temps je laisse encore tourner

le retour:

jean-marc@gargantua:~$ sudo fdisk -l /dev/disk/by-id/wwn-0x5000c5002e28ae51
Disque /dev/disk/by-id/wwn-0x5000c5002e28ae51 : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x0006e8e9

Périphérique                                 Amorçage  Début        Fin   Secteurs Taille Id Type
/dev/disk/by-id/wwn-0x5000c5002e28ae51-part1 *           2048    2047999    2045952   999M 82 partiti
/dev/disk/by-id/wwn-0x5000c5002e28ae51-part2          2048000 1881843711 1879795712 896,4G 83 Linux
jean-marc@gargantua:~$

Dernière modification par herodote k210 (Le 19/11/2018, à 21:25)

jamesbad000 · Le 19/11/2018, à 21:24

Par suite: sudo fdisk -l /dev/disk/by-id/wwn-0x5000c5002e28ae51
prend du temps je laisse encore tourner

Hein ? pas normal. Tu as bien fais un copié coller de la commande que j'ai donné ?

Dernière modification par jamesbad000 (Le 19/11/2018, à 21:24)

herodote k210 · Le 19/11/2018, à 21:27

Oui d'ailleurs le résultat est tombé et je l'ai mis dans le message modifié.

Pour finir:

jean-marc@gargantua:~$ sudo dumpe2fs -h /dev/disk/by-id/wwn-0x5000c5002e28ae51-part2
dumpe2fs 1.42.13 (17-May-2015)
Filesystem volume name:   <none>
Last mounted on:          /media/jean-marc/a129a72a-2c70-4b0d-bade-4a6d122c621c
Filesystem UUID:          a129a72a-2c70-4b0d-bade-4a6d122c621c
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean with errors
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              58744832
Block count:              234974464
Reserved block count:     11748723
Free blocks:              12773902
Free inodes:              58716689
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      967
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sat Sep 30 17:50:54 2017
Last mount time:          Mon Nov 19 20:14:35 2018
Last write time:          Mon Nov 19 20:19:28 2018
Mount count:              5
Maximum mount count:      -1
Last checked:             Fri Nov 16 21:54:38 2018
Check interval:           0 (<none>)
Lifetime writes:          1431 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      bdf842be-fba9-4b24-a487-aa4559968572
Journal backup:           inode blocks
FS Error count:           317
First error time:         Sat Nov 17 23:14:47 2018
First error function:     ext4_iget
First error line #:       4761
First error inode #:      42336257
First error block #:      0
Last error time:          Mon Nov 19 20:19:28 2018
Last error function:      ext4_iget
Last error line #:        4252
Last error inode #:       55574529
Last error block #:       0
Fonctionalités du journal :  journal_incompat_revoke
Taille du journal :         128M
Longueur du journal :      32768
Séquence du journal :      0x00028d15
Début du journal :         1

jean-marc@gargantua:~$

jamesbad000 · Le 19/11/2018, à 21:54

Encore une question: cette partition a bien été crée initialement avec le ubuntu 16.04 actuellement installé sur cette machine ?

herodote k210 · Le 19/11/2018, à 21:57

A ce moment là, c'était la même machine, mais sous ubuntu 14.04 hwe (noyau de xenial)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 17/11/2018, à 02:57

perte de partition, suite à arrêt de redimensionnement de la partition

#2 Le 17/11/2018, à 04:52

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#3 Le 17/11/2018, à 12:35

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#4 Le 17/11/2018, à 22:45

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#5 Le 18/11/2018, à 00:07

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#6 Le 18/11/2018, à 00:34

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#7 Le 18/11/2018, à 01:46

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#8 Le 18/11/2018, à 01:53

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#9 Le 18/11/2018, à 05:46

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#10 Le 18/11/2018, à 09:16

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#11 Le 18/11/2018, à 13:53

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#12 Le 18/11/2018, à 14:04

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#13 Le 18/11/2018, à 16:23

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#14 Le 19/11/2018, à 00:48

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#15 Le 19/11/2018, à 00:52

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#16 Le 19/11/2018, à 07:14

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#17 Le 19/11/2018, à 19:14

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#18 Le 19/11/2018, à 19:50

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#19 Le 19/11/2018, à 20:24

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#20 Le 19/11/2018, à 20:59

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#21 Le 19/11/2018, à 21:21

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#22 Le 19/11/2018, à 21:24

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#23 Le 19/11/2018, à 21:27

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#24 Le 19/11/2018, à 21:54

Re : perte de partition, suite à arrêt de redimensionnement de la partition

#25 Le 19/11/2018, à 21:57

Re : perte de partition, suite à arrêt de redimensionnement de la partition

Pied de page des forums