[résolu] partition /home sur SSD défectueux - irrécupérable ?

lhg-Emz0 · Le 13/10/2014, à 15:12

Bonjour.

Je me présente aujourd'hui devant vous - une fois n'est pas coutume - car je suis dans la merde.

J'ai fait il y a un peu plus d'un an l'acquisition d'un SSD Crucial M4, sur lequel j'ai installé Ubuntu.

Mal m'en a pris, car le disque est clairement défectueux.

Le premier symptôme fut le passage régulier de mon /home en lecture seule. Un redémarrage réglait le problème. Mais je n'ai pas trouvé la cause.

0r, ayant tenté de backuper mon disque avec clonezilla, celui-ci parvient à cloner les partitions / et /usr, mais bloque systématiquement sur le /home (forcément -_-)... aux alentours de 85%. Il indique que le disque est physiquement endommagé, et ne parvient pas à lire l'intégralité du FS.

Il faudrait donc que je change ce disque. C'est déjà un problème pour mon porte-monnaie, mais soit.

Par contre, je ne me sens pas le courage de refaire une installation d'un système que j'ai mis une bonne année à configurer pour qu'il convienne parfaitement à mes usages.

Je me tourne donc vers vous, en désespoir de cause - cela m'embête de venir vous ennuyer à chaque fois que j'ai un problème mais je ne sais que faire :

y a-t-il, à votre avis, la moindre chance de pouvoir récupérer mon /home en vue de le transférer sur mon nouveau disque ?

Je serai infiniment reconnaissant envers toute personne qui me viendrait en aide - qu'on y parvienne ou non, je suis preneur de toute idée, puisque de toute façon, à mon avis je suis cuit.

Dernière modification par lhg-Emz0 (Le 20/10/2014, à 14:33)

Rufus T. Firefly · Le 13/10/2014, à 15:56

Démarre en live (<=> essayer sans installer) sur un cd linux quelconque (ou une usb). Essaye de monter la partition de ton ssd qui contient /home. Et copie ce qu'il est possible de copier sur un disque externe. Avec un peu de chances tu pourras récupérer une partie de tes configurations...

A part ça, la durée de vie des SSD est ce qu'elle est, pas bien longue. Quand on veut gagner 5 secondes au démarrage, c'est peut-être le prix à payer...

lhg-Emz0 · Le 13/10/2014, à 16:35

Merci. 0ui, c'est ce que j'ai fait, j'ai pu récupérer pas mal de trucs mais je ne suis pas sûr de pouvoir reconstruire un /home avec ça, après la réinstallation qui, du coup, me paraît inéluctable.
A vrai dire, je ne saurais même pas comment faire : entre le nouveau /home et ce que je peux récupérer de l'ancien, quoi remplacer sans tout casser ?

Pour la durée de vie du SSD, je suis surpris, car j'ai un V4, également crucial, depuis bien plus longtemps, qui me sert de "labo", donc je travaille intensivement dessus et il ne donne aucun signe de fatigue. Par ailleurs, je vois beaucoup de gens qui disent avoir le même modèle que moi depuis au moins aussi longtemps, et pas de signe d’essoufflement non plus... Je suppose que, fidèle à ma loose, je suis encore tombé sur un matériel défectueux.
Il me semblait que les nouvelles générations étaient plus fiables et avaient une durée de vie dorénavant correcte. Là, un an je trouve ça court quand même !

L'idée n'était d’ailleurs pas de gagner quelques secondes au démarrage - je n’éteins quasiment jamais mon pc puisque je travaille dessus quasiment 24/24 et, même quand je n'y suis pas, il tourne puisque il héberge mon serveur sur une VM - sur un autre SSD qui, lui, plus ancien, fonctionne toujours sans le moindre problème. Je suis passé sur SSD, d'abord parce que j'en avais marre des pannes physiques régulières des dd ; ensuite et surtout pour conserver un système réactif malgré l'utilisation très intensive que j'en fais - sur un dd classique, même à vitesse de rotation rapide, ça devenait fastidieux. Par ailleurs, pour ce qui est de mon "labo" et du serveur, je peux les transporter sans risque de les casser au moindre choc, ce qui est un avantage non négligeable.

Il n'y a donc aucun moyen de récupérer la partition de telle sorte que je puisse éviter une réinstallation ?

Dernière modification par lhg-Emz0 (Le 13/10/2014, à 16:42)

Rufus T. Firefly · Le 13/10/2014, à 16:42

Je m'imagine que tu as cherché sur le net comment ça peut se tester, un ssd. Un équivalent smarmontools qui permettrait au moins de savoir ce qu'il en est, au juste... Ce n'est peut-être pas le disque !
Si tu as récupéré ce qu'il est possible de récupérer, tu peux peut-être aussi tenter un fsck. On ne sait jamais...

Bougron · Le 13/10/2014, à 16:58

Bonjour.

Tu peux essayer aussi d'utilliser testdisk qui est installable par la logithèque http://www.cgsecurity.org/wiki/TestDisk_Etape_par_Etape

Tu peux aussi tenter une duplication physique par la commande "dd" http://forum.ubuntu-fr.org/viewtopic.php?id=1679631&p=1

PS: Avec clonezilla, Je ne réussis pas à sauver un disque dur, Il me dit qu'il y a des erreurs et que je dois corriger pas la commande fsdsk
qui évidemment ne trouve rien d'anormal, Je relance . C'est identique.
J'ai finalement dupliqué tous les répertoires. Je n'ai encore compris pourquoi clonezilla refuse de sauver. Peut-être parce qu'il y a un secteur défectueux et que clonezilla sauve tout ce qui se présente. Même s'il n'y a pas de données dessus.

Dernière modification par Bougron (Le 13/10/2014, à 17:09)

lhg-Emz0 · Le 17/10/2014, à 15:37

Bonjour, et merci pour votre aide !

J'ai en effet testé le SSD, notamment avec smartmontools qui m'a sorti une floppée d'erreur.

Fsck me permet à tous les coups de récupérer le système, mais seulement pour un court laps de temps. Je dois le refaire à chaque redémarrage. Pour l'instant, je ne monte plus ce disque qu'en lecture seule.

DD, je n'y avais pas pensé ! La solution la plus simple étant souvent la meilleure, j'ai tenté ceci :

dd if=/dev/sda of=/dev/sdb bs=4096 conv=notrunc,noerror

(tenté aussi avec bs=16065b et 32130b) à partir d'un livecd et en écrivant sur un ssd de même volume (quasi le même modèle).

Je parviens bien ainsi à copier ma partition sda1 (boot).

Mais la partition étendue sda2 - contenant / (sda5), /usr (sda6), /home (sda7), /temp (sda8) et le volume de swap - arrive vide en sortie, et j'ai de nombreuses erreurs i/o durant la copie.

Les partitions sur le disque d'origine sont pourtant tout à fait lisibles, avec testdisk mais aussi par Ubuntu, Nemo ; Gparted ne voit non plus rien d'anormal... Simplement, il m'est impossible d'extraire l'ensemble du système de fichiers. Je peux copier des données, mais pas le tout, donc actuellement je ne vois toujours pas comment éviter la réinstallation.

Ca m'ennuie vraiment, ma 13.04 a passé deux mises à niveau, j'ai passé un temps fou à la configurer aux petits oignons... Je ne pensais vraiment pas déjà avoir à le refaire !

Et évidemment, je n'ai pas de backup ( ce serait trop simple -_- ), puisque celui que j'avais a été écrasé par celui qui a échoué.

Dernière modification par lhg-Emz0 (Le 17/10/2014, à 15:44)

Rufus T. Firefly · Le 17/10/2014, à 15:55

Essaye de faire la copie juste après un fsck, et de plus, ne copie que /home (/dev/sda7 au lieu de /dev/sda)

Dernière modification par Rufus T. Firefly (Le 17/10/2014, à 15:56)

lhg-Emz0 · Le 18/10/2014, à 02:56

Bien vu !

De cette manière, je récupère du contenu, mais illisible - c'est déjà un progrès

J'ai commencé par tester avec sda5 et sda6 - fsck puis dd (if=/dev/sdaX of=/dev/sdbX ; ayant préalablement créé des partitions vides de formats, volumes... strictement identiques à celles d'origine sur le nouveau disque)...
Puis re-fsck sur les partitions clonées (il trouvait encore des erreurs) : ça a bien fonctionné, je récupère des partitions qui me semblent intègres.

Par contre, /home une fois copié contient un nombre d'erreurs assez hallucinant ! Après un repassage de fsck, je peux le monter... mais mon répertoire utilisateur n'est plus vu comme tel : il s'affiche comme un fichier illisible.

Je retente le coup, là je fatigue donc je lance la copie et demain je verrai ce que je peux faire avec.

Encore merci pour le coup de main, quoi qu'il en soit.

Edit :

Non, définitivement, dd sda 7 (home) -> sdb7 me donne un filesystem corrompu, qui après un fsck trouvant plein d'erreurs me permet certes d'obtenir du contenu mais lisible seulement en binaire, et réduit à 10% du volume de données d'origine...

et ce, alors que le /home d'origine est toujours lisible et montable ! oO

Gparted ne voit toujours rien d'anormal. Je tente une copie de sda7 sur sdb7 en passant par là. Pour l'instant : 15% de fait, 3 erreurs 50% de fait, 4 erreurs non fatales trouvées. "retry" ne fonctionnant pas, j'ai fait "ignore"... en espérant que ces petits trous sur la partition d'arrivée ne soient pas trop importants.

Sinon, en désespoir de cause, je ne vois qu'un cp -R -p, mais il me semble que ce n'est pas le meilleur moyen de récupérer de façon certaine un sf vraiment à l'identique. Enfin, au point où j'en suis, ça permettra au moins de récupérer les données.

Dernière modification par lhg-Emz0 (Le 18/10/2014, à 14:54)

lhg-Emz0 · Le 18/10/2014, à 18:13

Bon, avec Gparted j'ai pu copier mon /home.

dd a copié les autres partitions sans faire d'histoire, à part deux erreurs i/o en cours de copie de la partition contenant /usr.

Les partitions sur les deux disques semblent à présent à peu près identiques, et je peux naviguer sans problème - tout à l'air là (même si, dans les faits il doit manquer deux ou trois choses, que j'espère pas trop importantes...).

J'ai bien mis le flag "boot" à la partition contenant Grub...

... mais impossible de booter sur le nouveau disque ! Ca ne s'amorce pas.

J'ai donc copié le MBR de l'ancien disque... Mais ça ne change rien.

Bougron · Le 18/10/2014, à 18:26

Bonsoire
C'est assez logique que tu ne puisses pas booter
Les disques ont une authentification (comme une adresse MAC en beaucoup plus long) qui est utilisée comme référence pour booter

Un coup de boot-repair cela devrait se rectifier.
Si tu n'as pas boot-repair sur ta clé USB, il s'installe de la façon suivante ( https://doc.ubuntu-fr.org/boot-repair )
sudo add-apt-repository ppa:kranich/cubuntu
sudo apt-get update
sudo apt-get install -y boot-repair
boot-repair

Dernière modification par Bougron (Le 18/10/2014, à 18:27)

sinbad83 · Le 18/10/2014, à 18:29

Si tu as un problème de démarrage, essaye en réparant Grub. Doc sur https://doc.ubuntu-fr.org/tutoriel/comm … aurer_grub

lhg-Emz0 · Le 18/10/2014, à 20:15

Merci. Avant de tenter une réparation manelle de Grub, j'aurais bien essayé boot-repair, mais impossible de l'installer.

Le seul livecd que j'ai à ma disposition est une 13.04. Sur Kranich, il n'est pas trouvé. D'après la doc, pour les versions antérieures, il faut le récupérer sur yannubuntu, mais là encore "impossible de localiser boot-repair".

J'imagine qu'il me faut télécharger une version plus récente d'Ubuntu. Mais évidemment, n'ayant pas d'OS utilisable installé en dur sous la main, je ne pourrai pas graver le cd (le graveur étant utilisé pour faire tourner la 13.04 en question à partir de laquelle je téléchargerai la 14.04), et je n'ai pas non plus à disposition de clé que je pourrais utiliser pour ça. Va falloir que je fasse ça ailleurs demain.

Dernière modification par lhg-Emz0 (Le 18/10/2014, à 23:46)

sinbad83 · Le 19/10/2014, à 00:15

Si tu as un LiveCD 13.04, il n'y a aucun problème pour réparer Grub. Aucun besoin de passer par Boot-Repair.

lhg-Emz0 · Le 19/10/2014, à 19:05

Merci ! 0n progresse !

A présent je peux booter... mais durant le chargement d'Ubuntu, ça bloque et le PC redémarre avant que j'ai accès à GDM. Serait-ce dû à une erreur dans la partition dédiée à la racine ? Pourtant, celle-ci s'est copiée sans m'afficher d'erreur et semble identique à la précédente. Et si je ne m'abuse, la copie via dd a dû copier l'uuid, donc ça ne viendrait pas de ça ? Je sèche.

Edit : En mode récupération, lorsque je tente un fsck all, j'obtiens une série d'erreurs en boucle :

filesystem coud not be mounted : /run/shm
mount: error while loading shared libraries : /lib/x86_64-linux-gnu/libblkid.so.1:invalid ELF header

...

... et donc fsck ne peut s'exécuter.

Pourtant, à partir du livecd, fsck me dit que tout est clean, et je ne relève moi-même rien d'anormal - mais je suis loin d'être un expert.

Je ne comprends vraiment pas, ces deux disques étant identiques (notamment, les répertoires /run sont strictement identiques), pourquoi Ubuntu ne veut pas se charger sur le nouveau alors qu'il se lance sur le défectueux !

Moi qui pensait en voir enfin le bout, il semblerait qu'en fin de compte mon fs, pourtant copié à l'identique, soit complètement cassé...

Il n'est pas question pour moi de réinstaller, d'abord parce que la seule fois où j'ai tenté une réinstallation en conservant /home, rien ne marchait - j'ai finalement dû le sacrifier lui aussi - ensuite parce que j'ai modifié un certain nombre de fichiers, notamment dans /etc qui n'est pas sur une partition dédiée, et que je n'ai pas pensé à noter chacune d'entre elles.

J'hésite à tout recommencer. -_- Ca m'embêterait vraiment, à présent qu'avec votre aide je suis parvenu à récupérer mon /home ; cloner mon /usr ; réparer Grub, /boot ; et réaliser une copie parfaite de / ... Alors, qu'est-ce qui cloche ?

Si je peux exécuter Ubuntu sur le disque défectueux, et le copier sur le nouveau ; une fois Grub reconfiguré... Ca devrait marcher - non ?

Edit 2 : Refait un dd if=/dev/sda5 of=/dev/sda6 ... A présent au démarrage j'arrive sur intiramfs / busybox... Jamais rien compris à ce machin... C'est un progrès ou une régression ?

Il me dit "impossible de monter /root" sous l'uuid xxxxx (pas noté le numéro)... Donc j'imagine qu'il cherche la partition dont l'uuid est celle de l'ancien disque. Faudrait que je trouve un moyen de changer celle de la nouvelle partition ?

Je vais tenter de modifier les uuid des partoches dans /etc/fstab ... on verra ce que ça donnera.

Si vous êtes toujours là... croisez-les doigts !

Dernière modification par lhg-Emz0 (Le 20/10/2014, à 02:04)

lhg-Emz0 · Le 20/10/2014, à 02:19

Bon, après vérification, les uuid des anciennes partitions et les nouvelles sont les mêmes, donc ça ne vient pas de là...

Du coup, je ne vois vraiment pas.

Maintenant ça bloque sur la recherche de systèmes de fichiers btrfs ; et en recovery mode sur "unable to getpwuid : ressource temprarily unavailable / bad file descriptor". Je ne trouve rien à ce sujet.

Dernière modification par lhg-Emz0 (Le 20/10/2014, à 02:33)

navtex · Le 20/10/2014, à 03:13

Ce n'est plus tres loin. Il faut laisser les iuid changer . et adapter dans le nouveau systeme donc pour connaitre les nouvelles iuid

sudo blkid

et puis les transcrire dans le fichier /etc/fstab .

lhg-Emz0 · Le 20/10/2014, à 03:26

Mais justement les uuid des anciennes partitions ont été conservées (sauf le swap que j'ai recréé - edit : j'ai entré dans fstab sa nouvelle uuid mais cela ne fait aucune différence) : les nouvelles ont les mêmes. Il faudrait que je commence par les changer ?

Je pense aussi qu'on touche au but. C'est encourageant !

Dernière modification par lhg-Emz0 (Le 20/10/2014, à 03:39)

navtex · Le 20/10/2014, à 03:38

le meme c'est entre blkid et fstab qu'il faut le trouver . les anciennes : les oublier !

lhg-Emz0 · Le 20/10/2014, à 03:47

D'accord, mais un sudo blkid me retourne les mêmes uuid que celles des anciennes partitions... et donc correspondant déjà bien à ce qu'il y a dans fstab. Seule la partition de swap avait une uuid différente, ayant été recréée et non clonée. Je l'ai corrigée dans fstab. J'ai donc à présent exactement les mêmes id dans fstab que celles donées par blkid, mais j'obtiens toujours le même "bad file descriptor" au démarrage, et ça bloque.

Faut-il donc que je génère de nouvelles id, que je mettrai ensuite dans fstab ?

Dernière modification par lhg-Emz0 (Le 20/10/2014, à 03:57)

navtex · Le 20/10/2014, à 04:09

Bizarre est ce que tu fais blkid depuis le live ? ou depuis la recup (qui donne un invalid blkid)
apres en live tu peux : faire ce que fait boot_repair

1) chrooter / :
sudo fdisk -l cela permettra de bien repérer les partitions concernées ainsi que les disques.
2) tu montes ta partition ubuntu / et tu y lies les répertoires /dev et /proc :
sudo mount /dev/sdxy /mnt remplacer bien sûr xy par les bonnes valeurs
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
3) tu "bascules" la partition root LiveCD sur celle de ton install.
sudo chroot /mnt
3) tu mets grub à jour (pour prendre en compte tout ce qui est présent) :
update-grub
5) tu (ré)installes Grub sur le MBR
grub-install /dev/sda
o

Dernière modification par navtex (Le 20/10/2014, à 04:11)

lhg-Emz0 · Le 20/10/2014, à 05:11

0ui, je travaille à partir du livecd ; de toute façon mon système ne démarre pas.

J'ai commencé à entrer tes commandes, mais je bloquais au point n°2... jusqu'à ce que je percute que /boot ; /usr ; /home ; /tmp étant installés dans des partitions distinctes, il me fallait les monter également.

Du coup j'ai remonté toute l'arborescence du système à récupérer dans le /mnt du live d'Ubuntu.

Cela a-t-il une incidence sur la suite des commandes que tu m'as données ? Je ne pense pas, mais je préfère être sûr - tu t'y connais plus que moi.

Edit (1) :

- update grub retourne :

/usr/sbin/grub-mkconfig_lib : This: not found

- grub-install /sda :

/usr/share/lupin-support/grub-mkimage: 22: exec: /usr/lib/lupin-support/newns: not found
grub-install.real: error: /usr/lib/grub/i386-pc/modinfo.sh doesn't exist. Please specify --target or --directory.

Maintenant, quand j'essaie de booter sur ce disque, Grub me dit ne pas reconnaître le système de fichiers et m'ouvre une invite de commande.

Edit (2) :

J'ai réparé Grub, je peux de nouveau amorcer Ubuntu, mais ça bloque encore, en démarrage normal sur la détection de btrfs ; en mode rescue juste après "running /scripts/init-bottom ... done", avec le message

failed to spawn friendly-recovery pre-start process: unnable to getpwuid : ressource temprarily unavailable

puis

failed to spawn friendly-recovery pre-start process: unable to getpwuid: bad file descriptor

. (répété deux fois)

Même chose en démarrant sur le noyau précédent.

Le système de fichiers est endommagé, c'est clair, vu le mal que j'ai eu à l'extraire de mon disque abimé, mais fsck ne trouve rien à faire.
J'ai comparé le fichier /etc/passwd à l'original - y compris les permissions : il est identique. Alors d'où vient le problème ?

C'est rageant ! Après tout ce qu'a encaissé mon système en près de deux ans - jusque à un changement de carte-mère - ce ne sont pas trois clusters défectueux sur son ancien support qui vont avoir sa peau, maintenant qu'il est replacé sur un disque sain ! Si au moins j'avais accès à un terminal...

Pas question d'avoir bossé pour rien !

Il y a forcément un moyen de récupérer le fs... C'est pour moi incompréhensible : je peux toujours utiliser le disque corrompu, mais impossible de faire fonctionner le fs dupliqué sur le disque sain ! Devrais-je tenter un cp de tout ce qui se trouve à la racine du vieux dd ?

C'est d'autant plus étrange que cette partition était la seule à ne pas présenter de défaillance...

Dernière modification par lhg-Emz0 (Le 20/10/2014, à 09:14)

Bougron · Le 20/10/2014, à 09:29

lhg-Emz0 a écrit :

Mais justement les uuid des anciennes partitions ont été conservées (sauf le swap que j'ai recréé - edit : j'ai entré dans fstab sa nouvelle uuid mais cela ne fait aucune différence) : les nouvelles ont les mêmes. Il faudrait que je commence par les changer ?
Je pense aussi qu'on touche au but. C'est encourageant !

Bonjour
Si par blkid tu vois deux fois les même valeurs, c'est normal si tu as dupliqué (du moins me semble-t-il) mais c'est quasiment anormal pour un bon fonction. Comment répondre a la question: Sur quel disque se trouve UUID N° X l'ancien ou le nouveau?
=> il serai normal que tu changes les UUID des anciennes partitions qui ne sont plus lisibles plutôt que les UUID du nouveau disque qui est sain...

Dernière modification par Bougron (Le 20/10/2014, à 09:31)

lhg-Emz0 · Le 20/10/2014, à 09:40

Bonjour.

En effet, ayant copié les partitions et débranché le disque corrompu et cloné (partition par partition), j'ai conservé les uuid, mis à part la swap qui a été recréée - j'ai mis à jour fstab en conséquence.

Il me semble que, puisque le vieux dd n'est pas utilisé, il ne devrait pas y avoir de conflit d'uuid - mais peut-être que je me trompe. L'idée était d'obtenir, autant que faire se peut, un disque identique à l'ancien (auquel, par mesure de sécurité, je préfère ne plus toucher).

A présent, je peux booter, l'identification des partitions ne semble pas poser problème.

Mais le chargement d'Ubuntu bloque avec ce "unable to getpwuid", qui d'après ce que j'ai trouvé ici et là - et qui n'est guère encourageant - serait plus symptomatique d'un filesystem corrompu que d'un problème d'identification de disque. pwuid faisant, me semble-t-il, référence non à l'id des partitions mais des utilisateurs. Et ce fichier (/etc/passwd) est identique, en poids, contenu et permissions à celui que j'avais sur le vieux disque. D'ailleurs, dans le doute, en fin de compte je l'ai re-copié individuellement.

Du coup, je me retrouve avec d'une part un disque (plus utilisé) corrompu, mais sur lequel le système peut démarrer... et d'autre part un disque sain... sur lequel Ubuntu ne s'exécute pas !

Quel casse-tête.

Dernière modification par lhg-Emz0 (Le 20/10/2014, à 10:23)

Bougron · Le 20/10/2014, à 10:27

lhg-Emz0 a écrit :

Bonjour.
Mais le chargement d'Ubuntu bloque avec ce "unable to getpwuid", qui d'après ce que j'ai trouvé ici et là - et qui n'est guère encourageant - serait plus symptomatique d'un filesystem corrompu que d'un problème d'identification de disque. pwuid faisant, me semble-t-il, référence non à l'id des partitions mais des utilisateurs. Et ce fichier (/etc/passwd) est identique, en poids, contenu et permissions à celui que j'avais sur le vieux disque. D'ailleurs, dans le doute, en fin de compte je l'ai re-copié individuellement
Quel casse-tête.

Peut-être une autre piste à suivre http://www.linuxcertif.com/doc/keyword//etc/passwd/

À l'origine, le fichier /etc/passwd contenait aussi les mots de passe cryptés des utilisateurs. Le fichier étant accessible en lecture, tout le monde avait accès à ceux-ci.
La disponibilité des mots de passe n'était pas un problème pour deux raisons: les utilisateurs n'avaient pas d'intention néfaste entre eux, et la puissance de calcul ne permettait pas de retrouver un mot de passe a partir de la version crypté. Ces deux arguments n'ont plus aucun sens aujourd'hui, et les mots de passes ne sont généralement plus stockés dans /etc/passwd.
Les mots de passes ont donc été déplacé vers un second fichier, qui n'est accessible que par le root. Ce fichier est le fichier /etc/shadow. Le champ qui contenait autrefois un mot de passe dans /etc/passwd contient désormais le caractère "x"

Dernière modification par Bougron (Le 20/10/2014, à 10:28)

lhg-Emz0 · Le 20/10/2014, à 13:26

YAY ! J'y suis !

Je poste présentement de ma vieille install... sur mon nouveau disque.

Merci beaucoup pour la piste, Bougron. En fin de compte, ce n'était pas ça mais j'aurai appris quelque chose.

J'ai vérifié depuis le livecd la structure du système de fichiers et il y avait de grosses anomalies : plusieurs répertoires illisibles comme... /lib ! Pas étonnant que ça ne se lance pas. ^^"

J'ai reconstruit l'arborescence petit bout par petit bout à coups de cp -R -p... Et j'ai fini par y arriver.

Un grand merci à vous tous pour votre aide. Grâce à la communauté, mon 0S a survécu à près de deux années d'utilisation intensive, un changement de carte-mère, un crash de disque dur et son transfert sur un autre. C'est sûr que sous windows ça aurait été plus simple : format C:/

Bon, maintenant j'imagine qu'il doit y avoir un paquet de trucs à checker. Si vous avez des idées...

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 13/10/2014, à 15:12

[résolu] partition /home sur SSD défectueux - irrécupérable ?

#2 Le 13/10/2014, à 15:56

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#3 Le 13/10/2014, à 16:35

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#4 Le 13/10/2014, à 16:42

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#5 Le 13/10/2014, à 16:58

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#6 Le 17/10/2014, à 15:37

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#7 Le 17/10/2014, à 15:55

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#8 Le 18/10/2014, à 02:56

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#9 Le 18/10/2014, à 18:13

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#10 Le 18/10/2014, à 18:26

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#11 Le 18/10/2014, à 18:29

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#12 Le 18/10/2014, à 20:15

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#13 Le 19/10/2014, à 00:15

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#14 Le 19/10/2014, à 19:05

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#15 Le 20/10/2014, à 02:19

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#16 Le 20/10/2014, à 03:13

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#17 Le 20/10/2014, à 03:26

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#18 Le 20/10/2014, à 03:38

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#19 Le 20/10/2014, à 03:47

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#20 Le 20/10/2014, à 04:09

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#21 Le 20/10/2014, à 05:11

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#22 Le 20/10/2014, à 09:29

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#23 Le 20/10/2014, à 09:40

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#24 Le 20/10/2014, à 10:27

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

#25 Le 20/10/2014, à 13:26

Re : [résolu] partition /home sur SSD défectueux - irrécupérable ?

Pied de page des forums