[2/3 RÉSOLU] grosse bourde faisant perdre une partition.

geole · Le 13/04/2023, à 12:56

Non, c'est qu'il n'y a pas eu d'erreur liée à gparted dans ce créneau et on voit la séquence de redémarrage de l ordinateur qui constate que....
On va regarder les 1000 dernières lignes d'avant le démarrage.

journalctl --no-pager  --since "2023-04-11 22:30" --until "2023-04-12 07:50" | tail -1000

Dernière modification par geole (Le 13/04/2023, à 12:56)

Maminette · Le 13/04/2023, à 15:47

Désolée du retard, mais j'étais à la récupération des fichiers valides que je viens tout juste de terminer.
cette dernière commande ne nous apporte rien :

 journalctl --no-pager  --since "2023-04-11 22:30" --until "2023-04-12 07:50" | tail -1000
-- Logs begin at Sun 2023-01-08 14:19:55 CET, end at Thu 2023-04-13 15:32:11 CEST. --
-- No entries --

Maminette · Le 13/04/2023, à 16:11

en relançant Gparted pour vérifier tous les disques, le sdb est bien reconnu, la partition est bien en ext4 avec son nom "Photos" et le redimensionnement a été effectué vers la gauche. J'aurais peut-être du attendre encore que ce redimensionnement soit terminé alors que, voyant que rien ne bougeait, je pensai à un plantage, pourtant, même la souris ne bougeait plus...?

Maminette · Le 13/04/2023, à 16:18

je viens de constater un autre souci : le disque /mnt/cruci2t (un nvme de 2 To) était monté sur /mnt et, avec les commandes du #10, le sdb semble s'être confondu avec lui dans le point de montage : je ne peux plus lire ce nvme (il contenait des fichiers musicaux), ni le démonter et dans /mnt, je ne vois que le contenu de sdb :mad:

geole · Le 13/04/2023, à 16:31

Pas grave. Il est caché par ce montage de dépannage. On va en faire un montage standard

sudo umount /dev/sdb2

udisksctl mount -b /dev/sdb2

Le disque sera alors monté sous /media/$USER ( /media/sdf/Photos ? )

 journalctl --no-pager  --since "2023-04-11 18:30" --until "2023-04-12 07:50" | tail -500

Peut-être que ton ordinateur s'était tout simplement mis en sommeil sans avoir fini son travail et que tu l'a mal réveillé. Car autrement la partition serait restée en bon état.

Dernière modification par geole (Le 13/04/2023, à 16:39)

Maminette · Le 13/04/2023, à 16:38

Alors là, je suis de plus en plus perdue : après ce post #29, j'ai fait un reset espérant retrouver le cruci2t; effectivement le reset a eu un effet particulier : je retrouve le cruci2t intégral, monté sur /mnt et Photos (sdb) est revenu sur /media/sdf alors que j'ai travaillé toute la journée sur /mnt. De plus, les fichiers invalides ont récupéré leurs icônes, mais les fichiers sont toujours illisibles si je tente de les ouvrir

("Impossible de charger l'image « 146.jpg ». Erreur d’interprétation du fichier d’image JPEG (Not a JPEG file: starts with 0x00 0x00)

geole · Le 13/04/2023, à 16:43

Tu faisais bien la copie après avoir visualisé le fichier pour voir qu'il était correct?
ou tu disais que l'icône est bonne donc le fichier est correct?
L' incident est-il sur le fichier copié? As-tu supprimé le fichier original?

Dernière modification par geole (Le 13/04/2023, à 16:46)

Maminette · Le 13/04/2023, à 17:31

Cela devient pathétique ! je vais pleurer ...
en voulant te répondre au #32, le système a crashé en ouvrant la fenêtre de Caja (je suis en Mate) pour lire "Photos".
Je venais de faire une session Photorec en récupérant sur un disque vide "exos2" mais elle a avorté ("core dumped") en ne récupérant que 300 jpg contre 4670 corrompus, je voulais copier le terminal, mais ce la a crashé avant.
maintenant, exos2 où il y a des recup-dir ne s'ouvre plus : "structure needs cleaning" je vais tenter de poster la photo d'écran. C'est exos21 qui se monte, et vide...

pour te répondre : l'incident n'est pas sur les fichiers copiés, j'ai supprimé les fichiers récupérés de la source en laissant les fichiers corrompus. Photos est-il toujours corrompu par sa partition ? En root, exos2 est absent et exos21 le remplace en s'étant créé automatiquement et reste vide. Les recup-dir que je voyais avant le crash ont disparu, mais ils étaient incomplets.

Je crains de refaire un Photorec qui risque encore d'avorter, mais cela n'a pas affecté la source /sdb ("Photos ")

Maminette · Le 13/04/2023, à 17:44

[img=cpature d'écran]<a href='https://www.casimages.com/i/Erreur 1.html' title='Mon image'>Lien vers mon image</a>[/img]

J'essaie Casimage, pix.cybernux ... et je n'arrive pas à publier l'image. Ces hébergeurs sont nuls ou leurs liens sont corrompus ou l'insertion dans le forum n'est pas compatible avec leurs URL

geole · Le 13/04/2023, à 17:51

Le plantage est certainement lié à une autre cause que photorec
Lorsqu'il y a plantage, les partitions en écritures ont un état incohérent , il faut obligatoirement réparer.
La partition système est en mode auto-réparation mais pas les autres.
donc

sudo fsck /dev/sdXN

Je te laisse trouver la valeur de XN

Lorsqu'il y a un mauvais démontage, le montage suivant se fait avec plus 1.
pour remettre, il faut supprimer les répertoires vides.
exemple

sudo rmdir -v /media/sdf/exos2

Si le répertoire est occupé par des fichiers, la suppression est refusée, sinon le répertoire est supprimé et il pourra de nouveau être recréé automatiquement au prochain branchement du disque.

Le photorec est uniquement en lecture. Tu peux le faire autant de fois que tu veux à part la durée....

"'j ai supprimé les fichiers récupérés de la source en laissant les fichiers corrompus"
Il ne te reste donc plus que des fichiers corrompus à récupérer par photorec.

Dernière modification par geole (Le 13/04/2023, à 17:54)

Maminette · Le 14/04/2023, à 10:04

Bonjour Geole,
c'est la cata... Après ce crash d'hier, tous les disques sont faussés. J'ai du arrêter la machine et mis le disque malade sur un dock d'une autre machine Linux qui n'a pas ce problème de plantages malheureusement fréquents, probablement lié à un souci de configuration. Il faudra que je trouve une solution pour ces plantages (mais je ferai cela sur un autre fil)
.
J'avais donc récupéré hier sur la machine défaillante les fichiers valides du disque "Photo", sur le disque "exos2" qui faisait 6 To, puis fait une tentative de Photorec sur un gros disque de 16 To ("Gold2) dans un répertoire "recup photo", après quelques temps de récupération survient ce crash et au redémarrage : tous les disques montés ont leur partition sautée.

Sur l'autre machine, j'ai tenté testdisk qui a retrouvé les partitions EFI et EXT4 mais n'a pas pu recréer correctement ces partitions avec leur contenu. J'ai fait un Photorec qui a récupéré plutôt les fichiers que j'avais pourtant effacés et les corrompus apparaissent plutôt en "jp2" illisibles. Mais le pire est que le disque de 16To s'est transformé en "exos2" de 6To avec disparition des autres dossiers qui existaient dessus. Passant par Gnome disk et "réparer le système de fichiers" (qui utilise fsck, je crois) ne répare pas les 16 To mais laisse le disque en 6To avec l'ancien contenu du vrai exos2, c'est à dire les quelques fichiers recup-dir et le vrai exos2 est vide.....

J'utilise un dock périphérique en mettant les disques à problème l'un après enlever l'autre pour ne pas faire d'interférence. Comment rétablir la situation?? Que l'exos2 de 6To reprenne son contenu et que le Gold2 redevienne un 16To avec son contenu précédent d'avant le crash de la première machine

Dernière modification par Maminette (Le 14/04/2023, à 12:39)

geole · Le 14/04/2023, à 14:53

Bonjour
Il faudrait que tu ouvres une nouvelle discussion pour ton ordinateur qui plante à répétition.
Lorsqu'on déplace par gparted, on n'a pas le droit d'interrompre le déplacement même par un plantage. Il a un message qui ne le dit pas clairement mais qui alerte sur le risque.

Comme dit, la commande fsck est disponible pour remettre en état les partitions utilisées au moment du plantage sauf la partition racine dont la réparation est automatiquement lancée pendant le redémarrage.

Je n'ai pas du tout compris comment tu as pu transformer le disque de 16 To avec label Gold2 en disque de 6 To avec Label exos2
Je connais les commandes dd et ddrecue qui peuvent le faire mais je ne te les ai pas proposées
A mon avis, gnome utitily doit avoir des clics qui pourraient faire la même chose par duplication . Mais tu n'as parlé que de "réparer le système de fichier"

Si tu as des données à récupérer sur ce disque de 16 To, c'est le moment de regarder avec testdisk.
Puis il ne restera que la solution gparted avec suppression de la table de partition via l'onglet périphériques (Donc des partitions) et création d'une nouvelle table de partitions GPT et d'une ou plusieurs partitions.

Pour les fichiers jp2 illisibles, donne ce retour pour quelques fichiers afin de vérifier les dire de photorec.

file  NomDeFichier.jp2

Je ne suis pas surpris que testdisk ait du mal à récupérer quelque chose lorsque une partition est déplacée.
Le contenu de l'ex partition EFI contient certainement plus de fichiers .jpeg que de fichiers .iso.

Il est possible que je n'ai pas mis la bonne option pour effacer les fichiers supprimés. Finalement en disposer encore va peut-être être une chance.
et pourtant non

dd if=Trace.txt bs=24 count=1 |hexdump
1+0 enregistrements lus
1+0 enregistrements écrits
0000000 636f 2e74 3120 2031 3631 313a 3a31 3730
0000010 6220 7320 7379 6574                    
0000018
24 octets copiés, 0,000261453 s, 91,8 kB/s

shred -z Trace.txt

dd if=Trace.txt bs=24 count=1 |hexdump
1+0 enregistrements lus
1+0 enregistrements écrits
24 octets copiés, 0,00109042 s, 22,0 kB/s
0000000 0000 0000 0000 0000 0000 0000 0000 0000
0000010 0000 0000 0000 0000                    
0000018

Dernière modification par geole (Le 14/04/2023, à 15:08)

Maminette · Le 14/04/2023, à 16:41

Je viens de faire un résumé de la situation, mais en le validant, j'ai perdu ma session Forum. J'aurais due copier le texte pour le coller sur une nouvelle fenêtre de réponse après la reconnexion au forum.

Donc je disais que le crash pendant Photorec a provoqué très curieusement, le transfert et remplacement de la partition 6To exos2 vers le 16To Gold2 en changeant de nom et de capacité, alors que Photorec travaillait sur le 4To Photos. Le 16 To était en train de récupérer les fichiers du 4To Photos sur un dossier "récupphotos", et le 6 To était en attente, monté, avec les fichiers valides récupérés hier. Ces derniers ont disparu du 6To.

Je suis consternée et je ne comprends pas du tout comment un crash peut faire autant de dégâts. Je crains que Testdisks ne retrouve pas le contenu de l'ancienne partition du 16To, comme la partition actuelle, vide, est fonctionnelle. Faut-il refaire Photorec pour les 3 disques ? La première tentative sur 4To Photos a récupéré des choses (dont les JP2) mais s'est arrêtée au milieu du nombre des secteurs examinés.

Pour le jp2:

file f19809824.jp2
f19809824.jp2: JPEG 2000 Part 1 (JP2)

çà annonce un jpg, mais il n'est pas valide, même en le renommant. mais avec un suffixe 2000 part 1. Les Jp2 sont peut-être des parties de fichiers jpg mais pas complètement récupérés

geole · Le 14/04/2023, à 16:54

Il y a malheureusement une autre possibilité.. La carte mère de ton ordinateur déconne complètement et confond les disques.
Tu as dis que photorec récupérait dans un dossier que tu avais créé.
Tant que testdisk n'a pas prononcé son verdict, il faut l'utiliser. Il récupère nom de fichier et contenu correct de fichier.
Photorec ne récupère que des morceaux de fichiers.
Je vais creuser la piste de la lecture d'un morceau de fichier jpeg

Pourras-tu donner ce retour?

dd if=f19809824.jp2 bs=24 count=1 | hexdump -C

Dernière modification par geole (Le 14/04/2023, à 17:12)

Maminette · Le 14/04/2023, à 16:57

Merci Geole.
Je vais essayer de tester la machine capricieuse, avec CPU-X et une session Live avec memtest.

Maminette · Le 14/04/2023, à 17:56

retour de dd

/mnt/Gold1/recupphoto/recup_dir.9$ dd if=f19809824.jp2 bs=24 count=1 | hexdump -C
1+0 enregistrements lus
1+0 enregistrements écrits
24 octets copiés, 4,5396e-05 s, 529 kB/s
00000000  00 00 00 0c 6a 50 20 20  0d 0a 87 0a 00 00 00 14  |....jP  ........|
00000010  66 74 79 70 6a 70 32 20                           |ftypjp2 |
00000018

le fichier est sensé faire 113 Ko

geole · Le 14/04/2023, à 18:29

installe la version linux deb ou appimage https://www.xnview.com/fr/xnviewmp/ et regarde si ouvrable

Maminette · Le 14/04/2023, à 18:45

Bravo Geole : les JP2 s'ouvrent avec ce viewer !

Je crois avoir trouvé la cause de mes multiples plantages même antérieurs au problème de ce fil de forum : une barrette RAM sur les 2 de 32Go. J'avais essayé une session Live-USB sur la première machine en lançant testdisk et rapidement "core dumped" pour testdisk, l'ordi n'a pas planté complètement. En redémarrant normalement avec la barrette en moins (32 Go suffisent amplement pour mon usage), Testdisk ne plante pas et j'ai retrouvé la poubelle du 16To qui n'apparaissait pas avant (??), elle comporte les 4 recup_dir de Photorec avant le crash, mais aucun fichier antérieur n'est visible sur ce disque.

J'espère que Testdisk remettra les choses en place, sinon Photorec ... la barrette avait du garder en mémoire la partition exos2 et l'a implanté dans le 16To lors du crash. :rolleyes:

geole · Le 14/04/2023, à 19:19

C'est vicieux une ram qui fait n'importe quoi........ Pourvu qu'elle n'ait pas trop vomi un peu partout depuis quelque temps.

Je n'étais pas très sur pour le logiciel. L'image est-elle entière et parfaite? Si oui, il est probable que tu n'avais jamais ouvert ce type de fichier et que tu n'avais pas le bon logiciel. Pas pensé à te dire de mettre l'extension jpeg

Bon courage pour la suite.

Maminette · Le 14/04/2023, à 20:25

Merci Geole.
Les images jp2 s'ouvre très bien avec ce viewer.
La machine à la mauvaise RAM continue d'analyser le 16 To (8% au bout de 2 h, donc Testdisk travaille correctement et n'est plus gêné par le "core dumped" de la RAM.
Je suis un peu rassurée mais il va falloir avoir de la patience, en espérant que les softs pourront récupérer beaucoup de choses.

Je te tiens au courant, à la fin de Testdisk (demain dans la journée, vu le temps que cela met).

Bonne soirée

Maminette · Le 19/04/2023, à 07:46

Bonjour,
Résultats des courses :
le 16To "Gold2" : récupération d'une partition Linux , mais vide, photorec, 3 passes : récupération de fichiers mélangés venant des autres disques, mais partielle, ne correspondant pas aux fichiers antérieurs au crash contenus sur ce disque (donc perte de données irrémédiable).

le 4 To "Photos" : récupération d'une partition Linux, vide aussi, photorec : pas de fichiers. MAIS : apparition d'un fichier "lost&found" QUI CONTIENT TOUTES LES IMAGES PERDUES AU DÉPART de la grosse bourde (redimensionnement sans sauvegarde), avec un simple #12xx comme nom. Après attribution d'un suffixe, les images sont toutes là et lisibles (??? ) sur le disque d'origine.

Le 6 To "exos2" ; testdisk récupérait une partition Linux, mais au reboot : rien, partition non allouée, à formater, photorec : rien de récupéré

Donc un mal (grand) pour un bien (petit) : le problème a permis de détecter une RAM défectueuse, qui provoquait très souvent des crashs et des dégâts extraordinaires sur des disques en train de travailler (partitionnement, tests et récupération) comme échange, greffe et perte de partition, échange et pertes de données.... Mais, malgré les outils puissants de Christophe Grenier, j'ai perdu des documents, contenus essentiellement sur le 16 To, mais je crois me souvenir qu'une bonne partie provenait de sauvegarde de mon Mac.

Moralité, faire des sauvegardes régulières et surtout si on travaille sur les partitions et penser que le hardware peut expliquer des pannes tout autant que les softwares.

Je mets résolu au 2/3 devant la perte de données, heureusement pas trop grave, j'en retrouverai dans des sauvegardes de mon Mac

Dernière modification par Maminette (Le 20/04/2023, à 17:23)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 13/04/2023, à 12:56

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#27 Le 13/04/2023, à 15:47

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#28 Le 13/04/2023, à 16:11

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#29 Le 13/04/2023, à 16:18

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#30 Le 13/04/2023, à 16:31

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#31 Le 13/04/2023, à 16:38

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#32 Le 13/04/2023, à 16:43

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#33 Le 13/04/2023, à 17:31

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#34 Le 13/04/2023, à 17:44

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#35 Le 13/04/2023, à 17:51

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#36 Le 14/04/2023, à 10:04

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#37 Le 14/04/2023, à 14:53

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#38 Le 14/04/2023, à 16:41

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#39 Le 14/04/2023, à 16:54

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#40 Le 14/04/2023, à 16:57

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#41 Le 14/04/2023, à 17:56

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#42 Le 14/04/2023, à 18:29

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#43 Le 14/04/2023, à 18:45

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#44 Le 14/04/2023, à 19:19

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#45 Le 14/04/2023, à 20:25

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

#46 Le 19/04/2023, à 07:46

Re : [2/3 RÉSOLU] grosse bourde faisant perdre une partition.

Pied de page des forums