Il n’est pas nécessaire de monter /home.
Et tant que Debian finit par booter, pas besoin de passer par chroot depuis un autre OS.
Grub n’est peut être pas le seul paquet endommagé ?
Et une réinstallation, tu y as pensé ?
Pour Grub, si tu boot sur ta Debian:
# dpkg -l | grep grub
# aptitude purge "les paquets précédents"
# aptitude purge ~c
# aptitude install "le grub qui est sur ta machine"
Du nouveau, qui a l’air de confirmer que le fautif était bien grub, enfin plutôt Ricardo qui a dû faire des cagades (ça veut dire des conneries dans le SO) en l’installant.
J’ai maintenant un boot aussi rapide qu’avant MAIS, je n’ai plus d’accès au second DD. fdisk -l ne voit que mon SSD.
J’ai commencé par vouloir démarrer sur Kubuntu (second DD) mais il m’envoie une erreur. Autre debian ancienne sur ce second DD = même résultat.
Je reboote sur ma Jessie, avec toujours la même longue attente, puis je fais un update-grub. Ce dernier ne découvre que le seul SSD, pas trace de second DD.
Gparted : même résultat.
Le second DD étant dans un logement à enclenchement rapide, je l’en déloge et je le replace, mais il est toujours absent.
Il me reste à rouvrir la boite et à vérifier de nouveau les connexions.
Je ne comprends pas. C’est à nouveau rapide ou il y a toujours le délai ?
Les aventures continuent. Reprise à minuit.
Je suis sur le portable(clavier mal adapté à mes gros doigts, erreurs de frappe possibles).
C’était bon au niveau du chargement, rapide comme avant mais second DD introuvable. J’ai rouvert la boite pour vérifier les connexions, l’alim du DD secong était légèrement sortie.
J’ai refermé, testé, chargé la Jessie (impec) vérifié fdisk -l, le second DD était maintenant visible.
Mais au niveau du Grub, j’étais sur le seul SSD.
J’ai donc voulu réinstaller le Grub et j’ai tout foiré.
Maintenant, je n’ai plus accès à rien.
Je vais donc passer à la phase ClefAgreg ou CD Knoppix pour essayer de réinstaller grub en chroot.
Réponse dans quelques temps ??? Demain, absent ==> famille.
Bon Noël à tous.
Après une journée de pause, je reviens vers vous pour essayer de comprendre.
Ce matin, j’ai allumé ma machine : rien, et toujours rien au bout de 5 mn.
J’ai tenté la patience, je n’ai rien touché et je suis allé faire des courses.
Retour au bout de 1h30, environ = machine allumée sur ma Jessie SSD.
Avant de faire quoi que ce soit, j’ai fait une sauvegarde sur un autre DDext, ça ne peut pas faire de mal.
Éteint la machine, rallumé et rebelote, 5 mn d’attente toujours rien, je vais ailleurs et retour env. 1H après = machine allumée sur Jessie SSD.
Ma déduction : le Bios cherche partout où il peut trouver un Grub et il finit par en trouver un planqué je ne sais où.
Je joins un ‘fdisk’ qui vous sera ptet causant.
Est-ce que l’ordre d’apparition des disques sur fdisk indique où est installé Grub 
Si c’est le cas, ce serait sur le second DD et non sur le SSD .
Et ça, malgré mes tentatives, soldées par un “réussi sans problème” d’installation de Grub sur le MBR de sda (le SSD)
[code]ricardo@jessie-ssd:~$ sudo fdisk -l
Disque /dev/sdb : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d’E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d’étiquette de disque : gpt
Identifiant de disque : FF18D671-B4A4-4AFB-BC2D-29BDB6E6E5B3
Device Start End Sectors Size Type
/dev/sdb1 2048 48828415 48826368 23,3G Linux filesystem
/dev/sdb2 48828416 48832511 4096 2M BIOS boot
/dev/sdb3 1061373952 1225211903 163837952 78,1G Linux filesystem
/dev/sdb4 1225211904 1274040028 48828125 23,3G Linux filesystem
/dev/sdb5 83986432 240234495 156248064 74,5G Linux filesystem
/dev/sdb8 447088640 549318655 102230016 48,8G Linux filesystem
/dev/sdb9 549320704 866062335 316741632 151G Linux filesystem
/dev/sdb10 866064384 905123839 39059456 18,6G Linux filesystem
/dev/sdb11 905125888 1061373951 156248064 74,5G Linux filesystem
Les entrées de la table de partitions ne sont pas dans l’ordre du disque.
Disque /dev/sda : 111,8 GiB, 120034123776 octets, 234441648 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 : gpt
Identifiant de disque : 9BA0D261-DA04-4274-8135-D5D2D09D2045
Device Start End Sectors Size Type
/dev/sda1 2048 48828415 48826368 23,3G Microsoft basic data
/dev/sda2 48828416 64452607 15624192 7,5G Linux swap
/dev/sda3 68360192 224610303 156250112 74,5G Microsoft basic data
/dev/sda4 64452608 64454655 2048 1M BIOS boot
Les entrées de la table de partitions ne sont pas dans l’ordre du disque.
[/code]
Non, aucun rapport. [mono]bootinfoscript[/mono] peut rechercher où GRUB est installé.
Non, aucun rapport. [mono]bootinfoscript[/mono] peut rechercher où GRUB est installé.[/quote]
Et ce ‘bootinfoscript’, on fait comment ?
On installe le paquet boot-info-script qui contient ce script.
https://fr.wikipedia.org/wiki/Basic_data_partition
Bizarre, tes types de partitions ricardo?
Mes types de partitions, créés avec le CD Debian, pour de la swap et de l’ext4 sont les suivants:
[ul]
Linux swap / Solaris
Linux[/ul]
L’identifiant de type “Microsoft basic data” est normal si les partitions ont été créées avec l’installateur de Wheezy.
OK, je n’ai pas approfondi, j’ai vérifié un acp avec un copié collé de ton texte, sans les traits d’union, y connait pas.
J’install et je vérifie ça, sitôt que la machine veut bien montrer un Grub.
J’ai rallumé à 16H17 et à l’instant même (17 H14) = pratiquement 1 heure 
,elle vient d’arriver directement sur ma Jessie, sans passer par la case Grub, donc possibilité de choix.
Là, je suis sur le portable.
Sinon, en dernier ressort, j’ai gravé un super-grub-disk 2.00s2 ce matin.
Je ne voulais pas en arriver là et j’aurais préféré trouver le dépannage en comprenant ce qui ne va pas, mais …
Complet, en effet ce bootinfoscript.
Il semblerait que Grub soit installer sur sda ET sur sdb.
D’où ptet une confusion, non ?
[code] Boot Info Script 0.61 [1 April 2012]
============================= Boot Info Summary: ===============================
=> Grub2 (v1.99) is installed in the MBR of /dev/sda and looks at sector
64452608 of the same hard drive for core.img. core.img is at this location
and looks in partition 135 for .
=> Grub2 (v1.99) is installed in the MBR of /dev/sdb and looks at sector
48828416 of the same hard drive for core.img. core.img is at this location
and looks in partition 135 for .
[/code]
Non, la machine boot sur le grub du disque qui est configuré dans le bios.
Si tu refaisais des tests matériels ?
- En “virant” ton second DD et en ne laissant que ton SSD.
- En virant" ton SSD et en ne laissant que ton second DD.
Non, la machine boot sur le grub du disque qui est configuré dans le bios.
Si tu refaisais des tests matériels ?
- En “virant” ton second DD et en ne laissant que ton SSD.
- En virant" ton SSD et en ne laissant que ton second DD.[/quote]
C’est l’étape que j’envisageais avant de passer à SuperGrubDisk.
Résultat sitôt que possible.
[quote=“ricardo”]Sinon, en dernier ressort, j’ai gravé un super-grub-disk 2.00s2 ce matin.
Je ne voulais pas en arriver là et j’aurais préféré trouver le dépannage en comprenant ce qui ne va pas, mais …[/quote]
Pas de honte a utiliser, super-grub-disk.
Super-grub-disk est un très bon outils, qui évite d’ avoir à manier le “grub shell” en cas de “grub error”.
Il permet de faire démarrer un système rapidement, et de corriger l’erreur via le système avec lequel on est un peu plus familiarisé.
Il me semble avoir déjà lu sur forum, que le cd d’installation de Debian permettait également de le faire.
Retour via le portable car aucune des deux manoeuvres ne donne de résultat.
Commencé par enlever le SSD et boot sur 2d DD = Niet au bout de 2 mn.
Remis le SSD et déconnecté le sd DD = même résultat négatif.
Maintenant, il est trop tard.
Je tente ce soir très tard avec SuperGribDisk.
Merci de l’aide.
Peux-tu détailler “Niet au bout de 2 mn” et “même résultat négatif” ?
Peut être un problème matériel ?
Teste en virant tout sur ta carte mère. Ne laisse que le minimum.
Ajoute un composant, fait quelques tests de bon fonctionnement.
Ajoute en un autre, fait quelques tests de bon fonctionnement.
…
Jusqu’à trouvé le coupable, si il y en a un ?
Tu peux aussi les tester seul.
Tu peux aussi les tester sur une autre carte mère si tu en as une.
Si j’ai bien compris c’est un rack pour disque dur.
Peut être la source du problème?
Les pannes matériels sont parfois difficile à trouver, je me rappelle avoir passé plusieurs jours pour diagnostiquer une barrette mémoire problématique.
Allumage machine
apparition page/logo de la CM
plus rien à l’écran.
arrêt machine au bout de 2 mn.
Pourquoi 2 mn ? Parce que il fut un temps où il fallait attendre environ 1.30 mn avant de voir la fenêtre Grub. Maintenant, il me faut attendre 1 H.
À Cédric :
J’ai dit plus haut avoir testé en débranchant les disques un par un, donc pas de problème de rack, puisque ce dernier était vide.
Je tente superGrubDisk.
EDIT :
Ou plutôt, je vais me coucher et demain, je rouvre la boite pour vérifier de nouveau.