Testdisk et partitions non reconnu

yayou · Le 26/08/2021, à 11:05

Hier soir, j'étais en train de te poster ce commentaire "Est ce que durant le processus, il se pourrait que les commandes demande ma validation pour poursuivre? Si cela arrive par exemple pendant que je dors, vont elles attendre ma validation pendant même 2h... ou vont elles opter pour un choix par défaut?" quand mon laptop s'est éteint net. J'ai tenté de rallumer, la LED d'alimentation s'allumait mais rien à l'écran. En pressant le bouton power, l'ordi ne s'éteignait plus. J'ai été obligé de retirer la batterie et de le déconnecter du secteur... La je me dis "punaise mais c'est quoi cette guigne?". Bref! J'ai passé une soirée stressante mais j'ai pu garder mon calme. Ce n'est que ce matin que j'ai pu régler le problème.
Eclaire juste ma lanterne concernant ma crainte d’interactivité des commandes.

geole · Le 26/08/2021, à 16:44

Lorsque tu frappes la commande:
Il peut y avoir une réponse immédiate disant qu'il y a une erreur de codification,
sinon un écran de suivi s'affiche. Il est raffraichi toutes les trentes secondes jusqu'à ce que cela se termine soit par fin de traitement au bout de pas mal d'heures soit par demande d'arrêt de ta part en frappant Ctrl Alt c
En clair, le processus se déroule parfaitement bien sans ta présence.

Un incident connu: Pendant le traitement, le disque peut exagérément chauffer lors des traitements des secteurs illisibles. Dans cas le bios le stoppe. Il n'est plus visible par la commande fdisk -l
Cela n'empêche pas ddrescue de continuer. Le suivi indique alors que la totalité des secteurs sont illisibles. Pas panique: Stopper ddrescue. Attendre quatre à cinq heures que le disque ait bien refroidi. Relancer ddrescue.

Dernière modification par geole (Le 26/08/2021, à 16:57)

yayou · Le 26/08/2021, à 17:09

Ah, merci geole. Je relance bien avec la dernière commande exécutée?

geole · Le 26/08/2021, à 17:26

Oui.

Elle se sert du fichier $HOME/suivi pour se repositionner et continuer.

yayou · Le 26/08/2021, à 19:10

Parfait! Je te reviens une fois que j'aurai du nouveau.

yayou · Le 28/08/2021, à 18:54

geole en tapant la première commande j'obtiens "Bad multiplier in numerical argument". De plus la première fois tu avais indiqué 049 comme taille de secteur mais pour la commande finale tu as mis 0496. Serait-ce une erreur?

Dernière modification par yayou (Le 28/08/2021, à 18:58)

yayou · Le 28/08/2021, à 19:21

Finalement j'ai pu lancer les hostilités en mettant -b4096. C'est en cours.

geole · Le 28/08/2021, à 20:22

Bonsoir
On ne se relit jamais suffisamment. Les deux autres commandes avaient bien 4096

yayou · Le 28/08/2021, à 21:02

Tu as tout à fait raison.

yayou · Le 29/08/2021, à 11:22

Hier soir j'ai du arrêter l'éxécution pendant 30mn à cause d'un coupure électrique. Voila où j'en étais:

Press Ctrl-C to interrupt 
    ipos:  187766 MB, non-trimmed:   524288 B,  current rate:       0 B/s 
    opos:  187766 MB, non-scraped:        0 B,  average rate:  15129 kB/s 
non-tried:    3815 GB,  bad-sector:     4096 B,    error rate:       0 B/s 
 rescued:  185083 MB,   bad areas:        1,        run time:  3h 23m 53s 
pct rescued:    4.62%, read errors:       10,  remaining time:  1d 12h 53m 
                             time since last successful read:     30m  9s 
Copying non-tried blocks... Pass 1 (forwards)^C^C 
 Interrupted by user

Juste en écrivant ce message, voila où ça en est:

Current status
     ipos:  763014 MB, non-trimmed:    3678 kB,  current rate:  10747 kB/s
     opos:  763014 MB, non-scraped:        0 B,  average rate:  22021 kB/s
non-tried:    3334 GB,  bad-sector:     4096 B,    error rate:       0 B/s
  rescued:  666147 MB,   bad areas:        1,        run time:  3h  8m 47s
pct rescued:   16.65%, read errors:       26,  remaining time:  3d 15h 51m
                              time since last successful read:          0s
Copying non-tried blocks... Pass 1 (forwards)

Après le retout du courant, voyant que la commande m'affichait 4 jours pour terminer, je me suis dit qu'il y avait peut être un moyen d'accélérer les choses.
Mon laptop a 3 ports USB 2.0 et 1 seul port USB 3.0 mais les 2 Hdd sont USB 3.0. Jusqu'ici j'ai branché le mauvais Hdd sur l'unique USB 3.0 et le bon sur un port 2.0. Donc pour accélerer, ce matin j'ai voulu intervertir histoire de bénéficier du meilleurs débit en écriture du USB 3.0. Sauf qu'en changeant de ports, ça change les ID des disques et le relancement de la commande n'est plus possible (j'ai donc du remettre le branchement initial). Du coup je me demande ce qui se passerait si au lieu des ID, je tentais de relancer la commande avec juste "sdb et sdc". Est ce que cela poursuivrais quand même avec l'actuel fichier de suivi ou est ce que ça créerai un nouveau, en recommançant l'éxécution à zéro? Y a t-il une quelconque limite au delà de laquelle la poursuite de l'exécution d'une commande après un CTRL+C échouera, alors qu'on utilise toujours le fichier de suivi? Et que ce passe t-il en cas de retrait accidentel (maladresse) d'un des Hdd?

Dernière modification par yayou (Le 29/08/2021, à 13:37)

geole · Le 29/08/2021, à 17:51

yayou a écrit :

Mon laptop a 3 ports USB 2.0 et 1 seul port USB 3.0 mais les 2 Hdd sont USB 3.0. Jusqu'ici j'ai branché le mauvais Hdd sur l'unique USB 3.0 et le bon sur un port 2.0. Donc pour accélerer, ce matin j'ai voulu intervertir histoire de bénéficier du meilleurs débit en écriture du USB 3.0. Sauf qu'en changeant de ports, ça change les ID des disques et le relancement de la commande n'est plus possible (j'ai donc du remettre le branchement initial). Du coup je me demande ce qui se passerait si au lieu des ID, je tentais de relancer la commande avec juste "sdb et sdc". Est ce que cela poursuivrais quand même avec l'actuel fichier de suivi ou est ce que ça créerai un nouveau, en recommançant l'éxécution à zéro? Y a t-il une quelconque limite au delà de laquelle la poursuite de l'exécution d'une commande après un CTRL+C échouera, alors qu'on utilise toujours le fichier de suivi? Et que ce passe t-il en cas de retrait accidentel (maladresse) d'un des Hdd?

Bonjour
Tu m'apprends que cela change les noms des id lorsqu'on branche différemment c'est probablement le path qu'il fallait mettre
Je ne suis pas certain que permuter va accélérer, Le mauvais disque qui a du mal à lire serait alors sur un port très lent
C'est le fichier de suivi qui fait référence
La vraie codification est
ddrescue options RéférenceDuSupportEntrée RéférenceDuSupportSortie FichierdeSuivi
La Référence est sous n'importe quelle forme y compris en relance. Ce n'est pas contrôlé.
Donc ne jamais confondre le support sortie avec le support entrée.
Si tu veux repartir à zéro, il faut supprimer le fichier de suivi

Dernière modification par geole (Le 29/08/2021, à 17:52)

yayou · Le 29/08/2021, à 18:09

Non, non, surtout pas. Je veux poursuivre avec le fichier suivi actuel (je suis déjà à 866 Gio récupérés). En même temps ce que tu dis sur le fait de brancher le mauvais sur un USB 2.0 me semble logique. Je vais donc poursuivre avec le branchement actuel jusqu'à la fin. Et pour éviter de me tromper, ce que je fais c'est de brancher le mauvais, m'assurer qu'il apparaît en sdb dans ls /dev et enfin je branche le bon. Là, pas de risques d'erreurs possible.
Par contre j'aimerai ton avis sur "Y a t-il une quelconque limite au delà de laquelle la poursuite de l'exécution d'une commande après un CTRL+C échouera, alors qu'on utilise toujours le fichier de suivi? Et que ce passe t-il en cas de retrait accidentel (maladresse) d'un des Hdd?"

geole · Le 29/08/2021, à 18:18

Je pense que la commande ctrl c fonctionne systématiquement bien sinon, il suffit de fermer la session

Si un disque est débranché, l'écriture n'est plus possible et sera marquée en erreur dans le fichier de suivi.
Lorsque tout revient dans l'ordre, au passage suivant qui récupère les blocs non traités, Ceux mis à tort en non traités seront récupérés.

yayou · Le 29/08/2021, à 21:57

Merci. Je tenais à être sûre que même en cas de déconnexion accidentelle la commande ne repartais pas à zéro.

yayou · Le 30/08/2021, à 22:26

Le mauvais Hdd à subitement disparu. Voila ce que ça dit:

Initial status (read from mapfile)
rescued: 970584 MB, tried: 4280 kB, bad-sector: 4096 B, bad areas: 1

Current status
     ipos:  186976 MB, non-trimmed:    1911 MB,  current rate:       0 B/s
     opos:  186976 MB, non-scraped:        0 B,  average rate:   8505 kB/s
non-tried:    2285 GB,  bad-sector:     8192 B,    error rate:  22675 kB/s
  rescued:    1713 GB,   bad areas:        2,        run time:  1d 14m 57s
pct rescued:   42.81%, read errors:    29160,  remaining time:         n/a
                              time since last successful read:          2s
Copying non-tried blocks... Pass 5 (forwards) 
ddrescue: Input file disappeared: No such file or directory

De plus j'ai monté le bon Hdd pour voir ce qui avait déjà pu être sauvegardé et il se trouve que j'ai retrouvé exactement son contenu initial. La commande n'a pas écrasé son contenu. Tu pourrais m'éclairer?

Dernière modification par yayou (Le 30/08/2021, à 22:33)

yayou · Le 30/08/2021, à 22:35

J'ai redémarré l'ordi et tenter de relander la commande. Le mauvais apparaissait toujours en sdb dans ls /dev mais voulant relancer la commande j'ai eu ceci:

ddrescue: Last block in mapfile begins past end of input file.
          Use '-C' if you are reading from a partial copy.
Try 'ddrescue --help' for more information.

Aucun des Hdd n'avaient chauffés et le mauvais fait des bruits un peu plus audibles.

geole · Le 31/08/2021, à 09:38

Bonjour

yayou a écrit :

Le mauvais Hdd à subitement disparu. Voila ce que ça dit:

Initial status (read from mapfile)
rescued: 970584 MB, tried: 4280 kB, bad-sector: 4096 B, bad areas: 1

Current status
     ipos:  186976 MB, non-trimmed:    1911 MB,  current rate:       0 B/s
     opos:  186976 MB, non-scraped:        0 B,  average rate:   8505 kB/s
non-tried:    2285 GB,  bad-sector:     8192 B,    error rate:  22675 kB/s
  rescued:    1713 GB,   bad areas:        2,        run time:  1d 14m 57s
pct rescued:   42.81%, read errors:    29160,  remaining time:         n/a
                              time since last successful read:          2s
Copying non-tried blocks... Pass 5 (forwards) 
ddrescue: Input file disappeared: No such file or directory

On voit qu'en 24 heures il y a eu 1,713 To d'espace dupliqué et qu'il reste 2,285 To à traiter. Soit donc presque 43% de faits pour ce premier passage
Mais il y a eu 29160 erreurs de lecture! A priori réparties dans 2 grosses zones.

yayou a écrit :

De plus j'ai monté le bon Hdd pour voir ce qui avait déjà pu être sauvegardé et il se trouve que j'ai retrouvé exactement son contenu initial. La commande n'a pas écrasé son contenu. Tu pourrais m'éclairer?

Sur ce point
- Soit tu as lu très rapidement les noms de fichiers présents et tu n'as pas vu qu'il en manquait quelques-uns et qu'il y avait aussi des noms de fichier du disque usé.
- Soit, cas le plus probable, ddrescue n'a pas encore traité la zone contenant les noms de fichiers car elle est dans une des deux grosses zones signalées comme ayant des erreurs et ne sera traitée que plus tard. Ce cas est probable car on sait que le début du disque est illisible.
Je pense qu'avec presque 50% de données copiées, si tu avais ouvert tous les fichiers, tu te serais aperçu que certains étaient devenus illisibles ou avaient un autre contenu que celui espéré.

Il faut attendre la fin de toutes les commandes de copie pour en tirer une conclusion.

geole · Le 31/08/2021, à 09:47

yayou a écrit :

J'ai redémarré l'ordi et tenter de relander la commande. Le mauvais apparaissait toujours en sdb dans ls /dev mais voulant relancer la commande j'ai eu ceci:
ddrescue: Last block in mapfile begins past end of input file.
          Use '-C' if you are reading from a partial copy.
Try 'ddrescue --help' for more information.
Aucun des Hdd n'avaient chauffés et le mauvais fait des bruits un peu plus audibles.

Fais un rapport smartctl pour voir l'état du disque

Soit le firmware du disque a complètement perdu la bonne taille du disque et c'est fichu pour moi car il faudra le remplacer et je ne sais pas réparer logicquement
Soit le firmware a diminué d'un peu la taille du disque en prenant en compte la présence des mauvais secteurs.
Dans ce cas, il a certainement diminué par la fin et c'est très rare qu'il y a des données utilisateurs à la fin du disque.
Tu pourrais alors reprendre en ajoutant l'option -C Attention c'est un grand C et pas un petit c
-c sectors
--cluster-size=sectors
Number of sectors to copy at a time. Defaults to 64 KiB / sector_size. Try smaller values for slow drives. The number of sectors per track (18 or 9) is a good value for floppies.
-C
--complete-only
Limit rescue domain to the blocks listed in the mapfile. Don't read new data beyond mapfile limits. This is useful when reading from devices of undefined size (like raw devices), when the drive returns an incorrect size, or when reading from a partial copy. It can only be used after a first rescue attempt, possibly limited with the option '--size', has produced a complete mapfile.
Donc la commande de relance ressemblera à

sudo ddrescue  -C  -f    -n  -b4096  /dev/disk/by-id/ata-ST4000LM016-1N2170_W801B8DY    /dev/disk/by-id/"usb-Seagate_BUP_BL_NA7PKKV2-0:0"   $HOME/suivi

Nota, Si tu as la chance de tout recopier, ne fais pas cette commande

ddrescue --fill-mode=- --force --synchronous /dev/zero /dev/sdc $HOME/suivi

Cela devrait éviter de lancer testdisk pour récupérer la structure de la partition ca je la pense identique a celle du disque de sortie car il a la même taille
Mais on n'en est pas encore là.

Dernière modification par geole (Le 31/08/2021, à 09:50)

yayou · Le 31/08/2021, à 10:49

J'ai en effet juste regardé les dossiers apparaissant à la racine du disque et c'était tout les dossiers que j'avais crée. Vue qu'il était précisé dans la doc que préciser non pas la partition mais tout un disque durant l'exécution de ddrescue écraserait tout le contenu du disque, je me suis dit que ça avait foiré. J'espérais voir l'arborescence du mauvais Hdd déjà récupéré par la commande. Du coup, je me suis dit que c'est peut parce que je n'avais pas au préalable suivi la recommandation de la page ubuntu qui disait qu'il était bon de d'abord exécuter:

sudo dd if=/dev/zero of=/dev/Le_support_de_sortie bs=64k status=progress

Je vais regarder de plus près le contenu mais cette opération avait du sens pour moi si au moins elle récupérait les noms exactes des fichiers lisibles du mauvais Hdd. Au moins j'aurais un aperçu de l'historique d'activités dont j'ai besoin. Manifestement mon souhait ne sera pas exhaussé.

Le vrai problème c'est que j'ai une occasion unique de renvoyer le Hdd en France (où il y a plusieurs options et compétences pour regagner l'accès aux données) par un de mes neveux qui voyage ce Samedi. Du coup, étant donné le temps qu'à pris juste la première commande, il est évident que je ne finirai jamais l'opération avant ce délai. Donc tout ce que je peux faire c'est refaire une tentative mais avec un jeu d'options permettant de copier rapidement juste ce qui est lisible. Si cela marche bien, je pourrai me passer de renvoyer le Hdd en France (ou le remettre à plus tard car je suis déjà en train de commander 2 Hdd externes 3,5" de 4 Tio chacun) mais si je ne peux même pas retrouver un accès à une partie de mes données, je ne vais pas avoir d'autre choix que de remettre le Hdd à mon neveu pour que des experts le regardent.

Autre possibilité qui peut m'aider si la commande rapide n'existe pas: y a t-il un moyen de récupérer juste le listing des fichiers d'un Hdd défectueux? Sur tout mes Hdd fonctionnels j'ai fait:
ls -alR > $HOME/HistoriqueFichiers
Puis-je faire un truc équivalent avec ce Hdd défectueux?

geole · Le 31/08/2021, à 11:24

Réponse rapide
1) Je pense que tu étais en train d'exécuter la commande

sudo ddrescue   -f    -n  -b4096  /dev/disk/by-id/ata-ST4000LM016-1N2170_W801B8DY    /dev/disk/by-id/"usb-Seagate_BUP_BL_NA7PKKV2-0:0"   $HOME/suivi

Cette commande est celle qui copie le plus rapidement possible ce qui est en bon état.
Ne pas oublier que tu as 1 milliard de secteurs physiques à copier et que l'un des ports est en USB2.

2)

sudo  dd  if=/dev/zero  of=/dev/Le_support_de_sortie bs=64k status=progress

A mon avis, cette commande n'est pas justifiée, Elle prendrait des jours.
Je préfère demander un rapport smartctl qui se fournit en quelque secondes. Cela me permet d'avoir une petite idée de la qualité du disque de sortie sans avoir besoin de l'écraser de A à Z
Mais, il faut alors, dans l'absolu, ne pas oublier de terminer par la remise à zéro des blocs non copiés qui est une opération très rapide ( rarement plus de 1000 blocs ).

3) Je ne peux pas préjuger des secteurs qui ne seront pas recopiés à l'issue de la dernière des trois commandes

sudo ddrescue  -d  -f  -R  -r5   -b4096  -c1     /dev/sdb    /dev/sdc   $HOME/suivi

Il est possible que tous les secteurs de descriptions des noms de fichiers ne soient pas recopiés.
Dans ce cas des noms de fichiers sont éliminés et d'autres pas.

4) D'ici samedi, Il y a des chances que l'opération 1 ne soit pas finie et dans l'ensemble l'opération 3 est plus longue que l'opération 1 sans parler de l'opération 2! C'est toi qui choisis d'arrêter ou pas.

5) Fais rapidement un rapport smartctl du disque avant que tu l'expédies

6) Pour obtenir la liste des fichiers, il faut être capable de monter la partition contenant les données. Hors ton disque ne sait plus lire les partitions

7) Nota. Les réparateurs officiels font certainement de cette façon
1) Duplication par ddrescue
2) Si OK, tu récupères tous tes fichiers.
3) Si pas OK, utilisation de photoREC et tu récupères des fichiers uniquement nommés avec des numéros
4) Si tu as la chance d'avoir un réparateur consciencieux, il fera
4-1) Duplication par ddrescue
4-2) Remise en état de la partition par fsck
4-3) Duplication sur un autre disque de tout ce qui sera remis en état avec les vrais nom de fichiers.
4-4) Remise à zéro de tout ce qui a été dupliqué.
4-5) Récupération de tout ce qui est encore lisible par photorec en mettant des noms numériques aux fichiers en séparant par catégorie.
L'intérêt d'un réparateur: Si une pièce matérielle lâche, il peut la changer en salle blanche... Ce que tu ne peux faire.

Remarque plus globale
A mon avis, vu le volume traité par un très gros disque, je ne suis certain que le formatage en EXT4 soit une bonne solution pour la sécurité des données car c'est impossible de récupérer la lecture d'un secteur défectueux.
Les formats RAID1? BTRFS? ZFS? sont plus adaptés

Dernière modification par geole (Le 01/09/2021, à 19:24)

geole · Le 01/09/2021, à 18:28

geole a écrit :

......
5) Fais rapidement un rapport smartctl du disque avant que tu l'expédies
.....

Bonjour
Ce n'est pas une bonne réponse!

yayou · Le 01/09/2021, à 21:10

Ok je vais envoyer le rapport SMART. Mais qu'est ce qui n'est pas une bonne réponse?

geole · Le 02/09/2021, à 09:23

Bonjour
Le rapport smartctl nous a déjà dit que la taille du secteur logique est de 512 octets

Sector Sizes:     512 bytes logical, 4096 bytes physical

1) Mais nous ne connaissons pas l'adresse LBA du début de la partition qui a disparu
Je prend l'hypothèse que le disque en bon état a la même valeur. Donc pour trouver

sudo fdisk  -l /dev/disk/by-id/"usb-Seagate_BUP_BL_NA7PKKV2-0:0"

On aura certainement 2048 mais d'autres valeurs sont possibles
2) Conversion du LBA de DEBUT en octets. Donc certainement

DEBUT=$((2048*512)); echo $DEBUT

3) Récupération d'un point de montage libre

losetup --find

exemple de réponse possible
/dev/loop11
4) Monter l'espace disque du disque H.S. sur ce point de montage

losetup --offset $DEBUT /dev/loop11  /dev/disk/by-id/ata-ST4000LM016-1N2170_W801B8DY

sudo mount /dev/loop11  /mnt

5) Le plus simple est alors de lister les fichiers en espérant le miracle

ls -Rls /mnt

Nota je vais continuer tranquillement avec e2image

sudo e2image /dev/loop11 image
e2image 1.45.5 (07-Jan-2020)

ls -als image
160060 -rw------- 1 root root 971292672 sept.  2 10:35 image

==> Le fichier fait donc presque 1 Go. Ce qui est énorme . L'original fait 22 Go! mais c'est le logiciel UBUNTU qui a donc plein de fichiers....

On arrive facilement à trouver à partir de quel moment aucun bloc n'est utilisé. Ce qui peut être utile pour mettre une borne fin à ddrescue

$ sudo dumpe2fs -i image | grep "Blocs libres" | tail -30
dumpe2fs 1.45.5 (07-Jan-2020)
  Blocs libres : 14165636-14188543
  Blocs libres : 
  Blocs libres : 
  Blocs libres : 14266368-14270463, 14274785-14286847
  Blocs libres : 14286848-14319615
  Blocs libres : 14319616-14352383
  Blocs libres : 14352384-14385151
  Blocs libres : 14385152-14417919
  Blocs libres : 14417920-14450687
  Blocs libres : 14450688-14483455
  Blocs libres : 14483456-14516223
  Blocs libres : 14516224-14548991
  Blocs libres : 14548992-14581759
  Blocs libres : 14581760-14614527
  Blocs libres : 14614528-14647295
  Blocs libres : 14647296-14680063

  Blocs libres : 14687260-14712831
  Blocs libres : 14712832-14745599
  Blocs libres : 14745600-14778367
  Blocs libres : 14778368-14811135
  Blocs libres : 14811136-14843903
  Blocs libres : 14843904-14876671
  Blocs libres : 14876672-14909439
  Blocs libres : 14909440-14942207
  Blocs libres : 14942208-14974975
  Blocs libres : 14974976-15007743
  Blocs libres : 15007744-15040511
  Blocs libres : 15040512-15073279
  Blocs libres : 15073280-15106047
  Blocs libres : 15106048-15117823

Dernière modification par geole (Le 02/09/2021, à 17:55)

yayou · Le 02/09/2021, à 12:31

Les choses ont empirées:

smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-81-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Laptop HDD
Device Model:     ST4000LM016-1N2170
Serial Number:    W801B8DY
LU WWN Device Id: 5 000c50 09bf5ded8
Firmware Version: 0003
User Capacity:    137438952960 bytes [137 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    7200 rpm
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 3.0, 6.0 Gb/s
Local Time is:    Thu Sep  2 12:17:06 2021 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Read SMART Data failed: scsi error aborted command

=== START OF READ SMART DATA SECTION ===
SMART Status command failed: scsi error aborted command
SMART overall-health self-assessment test result: UNKNOWN!
SMART Status, Attributes and Thresholds cannot be read.

Read SMART Log Directory failed: scsi error aborted command

Read SMART Error Log failed: scsi error aborted command

Read SMART Self-test Log failed: scsi error aborted command

Selective Self-tests/Logging not supported

Je pense que je vais juste le renvoyer. Un pro pourra au moins me transmettre le listing dont j'ai besoin.

Concernant les autres systèmes de fichier, j'avais travaillé un peu dessus et lu notamment sur BTRFS par le passé. Il a gagné en stabilité mais est il recommandé pour les supports amovibles?

Dernière modification par yayou (Le 02/09/2021, à 12:46)

geole · Le 02/09/2021, à 17:30

Un firmware assurément de mauvaise qualité
User Capacity: 137438952960 bytes [137 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 7200 rpm
alors qu'avant c'était 4To , lecture physique de 4096 et vitesse 5400rpm

Dernière modification par geole (Le 02/09/2021, à 18:05)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 26/08/2021, à 11:05

Re : Testdisk et partitions non reconnu

#27 Le 26/08/2021, à 16:44

Re : Testdisk et partitions non reconnu

#28 Le 26/08/2021, à 17:09

Re : Testdisk et partitions non reconnu

#29 Le 26/08/2021, à 17:26

Re : Testdisk et partitions non reconnu

#30 Le 26/08/2021, à 19:10

Re : Testdisk et partitions non reconnu

#31 Le 28/08/2021, à 18:54

Re : Testdisk et partitions non reconnu

#32 Le 28/08/2021, à 19:21

Re : Testdisk et partitions non reconnu

#33 Le 28/08/2021, à 20:22

Re : Testdisk et partitions non reconnu

#34 Le 28/08/2021, à 21:02

Re : Testdisk et partitions non reconnu

#35 Le 29/08/2021, à 11:22

Re : Testdisk et partitions non reconnu

#36 Le 29/08/2021, à 17:51

Re : Testdisk et partitions non reconnu

#37 Le 29/08/2021, à 18:09

Re : Testdisk et partitions non reconnu

#38 Le 29/08/2021, à 18:18

Re : Testdisk et partitions non reconnu

#39 Le 29/08/2021, à 21:57

Re : Testdisk et partitions non reconnu

#40 Le 30/08/2021, à 22:26

Re : Testdisk et partitions non reconnu

#41 Le 30/08/2021, à 22:35

Re : Testdisk et partitions non reconnu

#42 Le 31/08/2021, à 09:38

Re : Testdisk et partitions non reconnu

#43 Le 31/08/2021, à 09:47

Re : Testdisk et partitions non reconnu

#44 Le 31/08/2021, à 10:49

Re : Testdisk et partitions non reconnu

#45 Le 31/08/2021, à 11:24

Re : Testdisk et partitions non reconnu

#46 Le 01/09/2021, à 18:28

Re : Testdisk et partitions non reconnu

#47 Le 01/09/2021, à 21:10

Re : Testdisk et partitions non reconnu

#48 Le 02/09/2021, à 09:23

Re : Testdisk et partitions non reconnu

#49 Le 02/09/2021, à 12:31

Re : Testdisk et partitions non reconnu

#50 Le 02/09/2021, à 17:30

Re : Testdisk et partitions non reconnu

Pied de page des forums