Problème démarrage grub

Support Debian
#21

Machine :
Debian 6
Atom D525 1.80 GHz
4 Go de ram
2 x 500 Go SATA2 (RAID 0/1 - Soft)

pitcat :

root@sysresccd /root % blkid -g
root@sysresccd /root % blkid 
/dev/loop0: TYPE="squashfs"
/dev/sdb: UUID="9eb16001-4273-694c-cb20-1669f728008a" TYPE="linux_raid_member"

lol :

Alors pour l’ancien post, je n’est rien fait, je n’est rien touché de ce qu’il me disait, je me suis dit pour rien risqué, je vais utilisé /var et puis voila …
Si je ne répond pas, ces que je ne suis pas la, je ne peux pas me connecter tout le temps.
Je regarde ton lien et j’édit suivant ce que sa a fait.

Edit 1:
Sur ton lien, à la commande “ddrescue -B -n /dev/old_disk /dev/new_disk rescued.log”, je pense que le old est /dev/sda, mais /dev/new_disk, je met quoi ???
Merci.

#22

Re,
Alors, ça se corse… Je ne vois plus sda dans la sortie de blkid.

Que donne fdisk -l maintenant ?
Tu es chez quel hébergeur ? Les as-tu contactés pour obtenir de l’aide et des conseils ? Il faut souvent insister (parfois fort) pour qu’ils réagissent… :075

C’est à dire ? Tu as copié l’intégralité de la racine dans /var, c’est ça ?
As-tu gardé la racine intacte ?
As-tu touché au fstab ?

Aucun soucis.

L’idéal serait de demander à ton hébergeur de te mettre provisoirement un troisième disque sur lequel tu mettrais le backup de testdisk (un disque usb ferait l’affaire - Je sais que chez OVH ils le font)

Même si ça te semble inutile, essaye de répondre à toutes les questions…

#23

lol :

root@sysresccd /root % fdisk -l

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x62bc736e

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      206847      102400   fd  Linux raid autodetect
/dev/sda2          206848    21178367    10485760   fd  Linux raid autodetect
/dev/sda3        21178368    29566975     4194304   82  Linux swap / Solaris
/dev/sda4        29566976   976773167   473603096   fd  Linux raid autodetect

Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/sdb doesn't contain a valid partition table

https://www.firstheberg.com/dedies/

Non, je n’est rien fait, il m’on enlevé le rescue, j’ai reboot, et la grub ne boot plus il me dise, donc il m’on reboot en rescue, sinon je n’est rien fait (a par je crois, faire passer la partition en ext2 sans toucher au fstab, mais je crois que c’était en ext4, alors que j’ai fait ext3 vers ext2, peut-être que …)

je leur demande qu’il me mette un disque provisoire juste pour backup dessus pour testdisk ?

Cordialement.

#24

Re,

  1. L’idéal serait effectivement d’avoir un disque de 500Go en plus
    En admettant que le troisième disque soit sdc (vérifie avec fdisk -l)
  1. Si ton hébergeur refuse: Tu peux reformater le disque 2 (sdb) et faire ton backup de sda dessus

2 bis) Tu peux ne pas faire de backup du disque. Ce n’est pas prudent…

  1. Lance enfin testdisk pour essayer de récupérer tes partitions (n’oublie pas “write” à la fin), quitte et tente de monter sda1, sda2, sda4 (ou seulement sda4 si c’est cette partition qui contient les données importantes):

mkdir /mnt/sda4 mount /dev/sda4 /mnt/sda4

Encore une fois, il serait judicieux d’expliquer le problème au support de firstheberg.com; Ils devraient pourvoir te proposer une tentative de récupération par leurs techniciens…
S’ils ne veulent rien savoir (te prêter ou te louer un disque, t’aider à récupérer tes données) tires-en les conséquences…

#25

Bonjour,

Alors je viens de faire une demande d’un disque dur provisoire juste pour le backup, j’attend la réponse …
Une question : si je fait un backup de sda sur le disque dur provisoire, si je demande une réinstallation complète de debian en spécifiant comment je veux les partitions, quand ma machine serat fonctionnel, je pourrais transférer mes données du backup vers ma nouvelle debian ???

Merci pour le mal que tu te donne pour moi.

#26

lol que penses-tu d’un :

Pour recréer les partition à l’identique ?
et ensuite un :

mdadm --detail --scan
pour finir avec un :

#27

[quote=“dbzquent”]Bonjour,

Alors je viens de faire une demande d’un disque dur provisoire juste pour le backup, j’attend la réponse …
Une question : si je fait un backup de sda sur le disque dur provisoire, si je demande une réinstallation complète de debian en spécifiant comment je veux les partitions, quand ma machine serat fonctionnel, je pourrais transférer mes données du backup vers ma nouvelle debian ???

Merci pour le mal que tu te donne pour moi.[/quote]

Tu pourras transférer tes données si les partitions de l’ancien sda sont montables et lisibles.
En l’état actuel, j’ai l’impression que ce n’est pas possible ? Tu as réessayé de monter sda1 sda2 ou sda4 ?

[quote=“pitcat”]lol que penses-tu d’un :

Pour recréer les partition à l’identique ?
et ensuite un :

mdadm --detail --scan
pour finir avec un :

Oui, pourquoi pas. Mais ça condamne tout espoir de récupération des données de sdb si sda n’est pas récupérable.
Ce qui me chagrine c’est que blkid ne sorte presque rien.
Je pense que testdisk va remettre de l’ordre dans sda, du coup les partitions devraient être de nouveau accessibles;
C’est pourquoi je crois qu’avant de faire le sfdisk (qui est une bonne idée pour commencer à reconstruire le raid) il faudrait lancer testdisk.

#28

Bonjour,

Juste pour dire que l’hébergeur est ok pour add un DD provisoire pour le backup, mais je dois attendre qu’il me l’install, je vous recontact quand j’ai le DD et que j’aurais testdisk, juste une question, comment je connaitrais le /dev/? du DD ? Merci.

#29

Salut,

Bien, ils sont coopératifs, c’est cool.

[quote=“lol”]1) L’idéal serait effectivement d’avoir un disque de 500Go en plus
En admettant que le troisième disque soit sdc (vérifie avec fdisk -l)[/quote]
Etant donné que tu as déjà /dev/sda et dev/sdb, ça devrait logiquement être /dev/sdc
Compare les “disk identifier” pour être sur[quote=“dbzquent”][code]
root@sysresccd /root % fdisk -l

Disk /dev/sda: 500.1 GB, 500107862016 bytes
…
Disk identifier: 0x62bc736e

Disk /dev/sdb: 500.1 GB, 500107862016 bytes
…
Disk identifier: 0x00000000
[/code][/quote]

#30

Bonjour,

Message du support :

Arf, tu crois sa peut le faire, et on peut pas le faire avec 2 clé en même temps ?
Merci.

#31

[quote=“dbzquent”]Arf, tu crois sa peut le faire, et on peut pas le faire avec 2 clé en même temps ?
Merci.[/quote]

Salut,
J’ai peu de temps, je part plonger…

Dit leur de se carrer leur clef usb au derch… :005
Tu leur a bien expliqué ton problème de partition perdue ?

Bon, je ne vois pas d’autre solution que de faire avec sdb.
Tente un testdisk sur sdb pour voir si tu peux récupérer les partitions.
Si ça ne donne rien, sfdisk de sda vers sdb suivi de testdisk sur sda.

Courage!

#32

Bonjour,

Alors quand je suis ton lien pour testdisk, j’ai bien fait le backup de sda sur sdb (j’ai rajouté --force), puis maintenant quand je lance testdisk, je suis ce qu’il dise, mais à un moment j’ai donc une liste des partitions, moi je veux réparer sda en entier (enfin je pense faut faire sa), alors je dois faire toute les partitions 1 par 1 ? Ou il y a une option pour toute les faire ? Ou je me goure complètement et il ne faut pas le faire sur toute les partitions ? Si oui, je lance sur les qu’elles ?

Désolé si je pose beaucoup de question, mais je veux être sur de ce que je fais et pas tout foutre en l’air.

Merci et cordialement.

#33

Salut,
je n’ai pas de courant ce matin (maison solaire + temps couvert depuis 2 jours…)
Je suis sur un smartphone (qui à osé nommer ça smart :mrgreen:)
Bref… Je n’ai plus en tête précisément la procédure. Dans mes souvenirs, c’est partition par partition.
Testdisk repère les partitions, te propose une liste. Tu vérifie que ça correspond à ce que tu avais avant le crash, tu choisis les partitions, tu valides, puis tu lui dis d’écrire avant de quitter.

Je ne peux maheureusement pas faire mieux pour l’instant… désolé.
Quelqu’un peut vérifier, je n’ai pas la possibilité de vérifier ?

Tu pourrais peut-être nous mettre une capture d’écran ?

#34

Salut,
Personne pour testdisk ? :confused:

#35

Je m’y colle avec pessimisme, pas loin de penser que c’est foutu d’avance vu comment l’affaire est embarquée …

Le seul repère que tu aies est celui du retour de #fdisk -l portant sur /dev/sda tel qu’affiché sur ce forum.
Était-ce le “bon” partitionnement ? supposons que oui.

Ce que tu devrais donc faire est de confronter ce que testdisk détecte pour /dev/sda avec l’ancien retour de # fdisk -l.
Si ce qui est détecté ne colle pas, insister : plus profond (“deeper search”) . Si ça colle : écrire (“write”).

Ce que tu fais pour /dev/sda n’est qu’une partie du chemin.
L’autre partie, celle de /dev/sdb sera encore plus incertaine. Tu te sers du support supplémentaire pour copier /dev/sdb (et dès lors prendre le risque d’effacer la sauvegarde de /dev/sda ).
Nous n’avons aucun repère pour savoir quel ancien partitionnement était le “bon” sur /dev/sdb. Nous ne savons pas à quoi ressemblait l’ancien partitionnement. Que /dev/sda et /dev/sdb soient partitionnés identiquement n’est qu’une hypothèse qui ne repose que sur des pratiques des uns et des autres. Rien ne nous dit que ce soit vrai dans le cas présent.

Ça suppose de tester ce que testdisk détecte de /dev/sdb en écrivant et en réassamblant le RAID qu’il constitue avec /dev/sda.
En étant très optimiste, ça passe à la première tentative.
Sinon tu insistes jusqu’à atteindre le point BERZERK où il faudra se résoudre à perdre ce RAID maltraité.

#36

Bonjour,

Je ne comprend vraiment rien à TestDisk, j’aimerai savoir si je pouvais sauvegarder sur mon pc les fichiers que je veux garder, et demander une réinstallation, et remettre sur le serveur.

Merci.

#37

Tu peux faire une copie brute par dd de tous tes disques vers des fichiers.

dd if=/dev/sda of=copie-brute-de-sda

Tu stockes ces copies sur des supports hors de ce système.
Muni de ces copies, tu pourras disposer des disques pour y installer debian à neuf.
Il te faudra deux fois le volume des disques pour stocker ces copies brutes.
Une copie de travail (celle qu’on peut charcuter) et une copie à garder intacte pour “décharcuter le charcutage”.

Est-ce que cette copie te permettrait de récupérer des fichiers ? Aucune assurance.
Ce que tu n’arrives pas à faire directement sur les disques devra être mené sur des fichiers ( testdisk, fsck, RAID, mount …)
Au lieu d’appeler testdisk sur un périphérique, tu devras le lancer sur le fichier.

cgsecurity.org/wiki/TestDisk_Etape_par_Etape

“deeper search” en une image :
cgsecurity.org/mw/images/Search_menu.gif

#38

[quote=“etxeberrizahar”]Tu peux faire une copie brute par dd de tous tes disques vers des fichiers.

dd if=/dev/sda of=copie-brute-de-sda

Tu stockes ces copies sur des supports hors de ce système…[/quote]

C’est justement là ou est le problème. Son hébergeur, et je suppose la plupart dans ce genre de situation, n’est pas coopératif…
Pour ce qui est de testdisk, c’est simple:
Il repère de partitions, si elles correspondent bien à ton système avant le problème, c’est bon, tu lui demande d’écrire avant de quitter, et ça devrait être bon.
Si les partitions ne correspondent pas à ce que tu avais avant (dans tes premiers messages la sortie de fdisk),corrige, sauvegarde et quitte le programme.

Aucune garantie, mais testdisk est normalement très efficace.

La morale, c’est que sans sauvegarde il n’y a pas beaucoup d’espoir (même en raid…).

Tu nous donnes des nouvelles ?

#39

[quote=“lol”]…Tu nous donnes des nouvelles ?[/quote] :question:

#40

Impose d’employer un support Live 32 bits pour un grub 32 bits à réparer et d’un CD d’une version 64 bits pour réparer une installation 64 bits… (petit rappel :smiley: )
Je conseille un live ubuntu ou debian ,mais vous faites comme vous le sentez
Demarez sur un live cd et go:

Si /boot est sur une partition à part (/dev/sda1 par exemple) et /dev/sda2 est normalement montée sur /.

sudo mkdir /media/sda2 sudo mount -t ext2 /dev/sda2 /media/sda2 #adapter le systeme de fichier ici ext2 #Verifier dans /media/sda2 si ca a bien fonctioné cd /media/sda2 sudo mount --bind /dev dev sudo mount --bind /sys sys sudo mount --bind /proc proc sudo chroot . sudo mount -t ext2 /dev/sda1 /boot #adapter le systeme de fichier ici ext2 #Verifier dans /media/sda2/boot si ca a bien fonctioné

A partir de là vous êtes positionnés quasiment comme si vous aviez démarré sur sda2 qui est devenu votre racine, et vous êtes en root, donc pas besoin de sudo devant les commandes. Ensuite vous pouvez faire votre update-grub normalement :

Pour ré-installer GRUB sur le MBR:

pour sortir du chroot, demontez /dev/sdb2

tapez exit, puis démontez les bind.

exit sudo umount proc sudo umount dev sudo umount sys cd .. sudo umount /dev/sdb1

redemarez le pc et faite booté le bios sur sda