Boot impossible sur fraîche installation Jessie

Support Debian
#1

Bien le bonjour à tous !

Une fâcheuse mésaventure vient de m’arriver après l’installation toute neuve de jessie sur un SSD presque tout neuf: Installation passée sans soucis, mais impossible de boot dessus (J’ai réussi une fois sur un coup de chance quand je cherchais à résoudre un problème avec mon BIOS).

Début de ma story : J’ai récupéré un SDD avec précédente installation de Jessie sur une architecture embarquée. Je l’ai installé dans ma tour pour accueillir une petite Jessie toute neuve. Jusque là rien de fort méchant. J’ai déconnecté tous les autres disques de ma tour (J’ai malheureusement déjà eu quelques mauvaises surprises en installant linux avec plusieurs disques connectés… Grub a cette fâcheuse habitude de s’infiltrer partout et de vouloir tout contrôler…) .

L’installation s’est passée sans encombre. Je choisis de prendre le disque entier pour le setup, je demande le /home sur une partition séparée. Installation terminée, le système veut redémarrer, j’acquiesce en éteignant le tout et je rebranche les autres disques. À partir de là c’est la fiesta des octets…
Au redémarrage dans le BIOS j’ai le choix entre boot sur “debian” ou mon nouveau SSD (la ligne P3)…

http://image.noelshack.com/fichiers/2015/47/1448191553-img-20151122-122126.jpg

Pour info, mes disques sont branchés comme suit dans la tour:

  • Samsung 830 : SATA3-0
  • WD5001 : SATA3-1
  • WD2003 : SATA3-2
  • TS64 : SATA3-3

Le TS64 était branché sur le SATA3-3 lors de l’installation de Jessie et c’était le seul disque branché lors de l’opération.

Si je choisis la P3 j’ai un message comme quoi il n’y a rien de mangeable… (peut être la partition /home qui apparaît ici ?)
Si je choisis Debian je tombe sur Grub (victoire ! … ou pas)
Je choisis donc la première ligne:
http://image.noelshack.com/fichiers/2015/47/1448191569-img-20151122-122142.jpg

Je tombe sur ce beau poème :

http://image.noelshack.com/fichiers/2015/47/1448191573-img-20151122-122148.jpg

Je suis les instructions à l’écran et je me retrouve là dessus :
http://image.noelshack.com/fichiers/2015/47/1448191578-img-20151122-122157.jpg

Seul solution : bouton reset de la tour.

J’ai essayé tout un tas de chose pour m’en sortir.
Ceci par exemple : plop.at/en/bootmanager/index.html Ca m’a sauvé plus d’une fois :smiley: Mais impossible de booter sur quoi que ce soit de linux
Ce truc là au cas où… cvad-mac.narod.ru/index/0-5 Mais sans grand succès

J’ai pensé que le fait d’avoir installé linux sans les autres disques a pu perturber la conf de grub. J’ai donc sorti la console de grub avec la touche C et à coup de LS j’ai pu déterminer qu’il fallait boot sur (hd9-gpt2). J’ai fait les modifications avec la touche E. Mais rien à faire faire je n’arrive pas à accéder à mon installation.

J’ai essayé grub repair, il n’arrive pas à réparer quoi que ce soit, j’ai donc sorti le fichier d’information :
http://paste.ubuntu.com/13443006/

Je pense avoir décrit exhaustivement les faits, s’il vous manque des informations dites le :wink:

Merci d’avance à tous ceux qui pourront me sortir de là ^^

Passez un bon dimanche !

#2

3200x2386 ? Tu n’avais pas plus gros ? Qu’est-ce que c’est que cette manie de poster sans les retailler des images en ultra-haute résolution qui pèsent des tonnes alors que 1024x768 suffirait ? Tout le monde n’a pas la fibre !

Pour info, ta machine a un firmware UEFI et non un BIOS. Debian s’est visiblement installé en mode UEFI. L’UEFI est censé faciliter le multi-boot, mais en pratique cela peut réserver des surprises, notamment quand on installe plusieurs fois la même distribution.

Cependant le message d’erreur lors du chargement du “disque mémoire initial” (initramfs) semble plutôt causé par une erreur de lecture, donc une défaillance du disque. Il faudrait le tester, par exemple avec smartctl et badblocks.

#3

Merci pour ta réponse rapide !

J’ai laissé la résolution de base pour être certain que tout reste lisible sans ambiguïté. Néanmoins je te l’accorde je n’ai pas prêté attention au poids de l’image en question. La prochaine je ferai ça mieux promis !

J’ai passé crystaldiskinfo : Tout est bon partout
Sur live deb 8.0 j’ai passé smartctl : test passed
Sur live dev 8.0 j’ai passé badblocks : aucun block cassé.

Je ne pense pas que le problème vienne d’une malfaçon physique. (Ce SSD n’a été utilisé que dans le cadre de test sur une architecture panel pc, il y a juste une installation deux trois test, un peu de Qt et c’est tout. par contre il a été allumé 24/24 pendant environ 2 mois.

#4

En dehors d’une défaillance matérielle ou d’un bug du firmware UEFI, je ne vois pas ce qui peut causer cette erreur que je n’ai jamais rencontrée lors du chargement de l’initramfs. Mes recherches avec le message en français

et en anglais

n’ont rien donné de concluant.

L’adresse de secteur 0xb0b688 (notation hexadécimale pour 11581064) correspond à une position d’environ 6 Go après le début du disque (en considérant des secteurs de 512 octets), soit bien en deça de sa taille. Même une incohérence du système de fichiers ne devrait pas provoquer ce type d’erreur. GRUB a réussi à chargé ses modules situés sur la même partition dans /boot/grub et le noyau situé dans /boot, alors je ne vois pas pourquoi il coince sur le chargement de l’initramfs qui est dans le même répertoire que le noyau.

Juste, je suis étonné que le disque s’appelle hd7. Si j’ai bien lu il n’y a que 4 disques, à moins que tu aies branché au moins 4 clés ou disques USB en plus ?

#5

Ton raisonnement dépasse de loin mes compétences : D

J’ai un lecteur de carte mémoire dans cette tour, sur windows j’ai quatre lecteurs supplémentaires, je suppose que c’est ça. Si besoin je peux le déconnecter si tu veux.

#6

Ah, cela expliquerait les 8 disques vus par GRUB (hd0 à hd7). Je doute que débrancher le lecteur de cartes change quelque chose.

En tout cas l’initramfs (“disque mémoire initial”) est indispensable au démarrage car le noyau seul n’est plus capable de monter la racine finale, d’où le “kernel panic” qui s’ensuit.

#7

Je suppose qu’après ton diagnostic, le remède s’appelle “setup that again” ?

#8

Je n’ai pas de diagnostic puisque tu as infirmé ma seule hypothèse (défaut du disque), et je ne peux même pas garantir qu’une réinstallation résoudra le problème.

#9

Dans l’optique où j’entreprendrais de réinstaller le système, comment devrais-je m’y prendre pour pas que Grub prenne le pas sur tout le monde ? (Si je souhaite démarrer sur Jessie je le demanderai au démarrage par UEFI) Et surtout pour éviter au maximum de me retrouver dans la situation actuelle avec un beau système tout neuf inutilisable :smiley:

#10

Qu’entends-tu par “Grub prenne le pas sur tout le monde” ?

#11

J’ai pu remarquer au fil du temps qu’à chaque installation de linux que j’ai pu entreprendre, Grub se débrouillait pour être le premier à boot et donner le choix ensuite à l’utilisateur de booter à tel ou tel endroit. Cependant, un jour j’ai fait la malheureuse expérience de casser un disque dur mécanique dans un pc portable qui avait les OS sur SSD (dual boot debian windows). Depuis il m’a été impossible de booter sur un quelconque OS de ce SSD… J’ai supposé qu’il manquait des morceaux à quelqu’un pour permettre le démarrage.

Mon hypothèse est peut être erronée. Néanmoins je ne voulais pas prendre le risque de créer un lien entre tous mes disques (4 à ce jour dans la tour) par l’installation de Jessie (d’où la déconnexion des disques avant l’installation).

Donc ce que je souhaite : que grub et tout son attirail ainsi que Jessie reste sur le SSD de 64GO qui leur est dédié.
Je gèrerai le multiboot par UEFI.

#12

Ce n’est pas spécifique à GRUB ni à Linux. Windows fait pareil, à la différence qu’il ne propose pas le choix de booter Linux.

[quote=“Reynosa”]Donc ce que je souhaite : que grub et tout son attirail ainsi que Jessie reste sur le SSD de 64GO qui leur est dédié.
Je gèrerai le multiboot par UEFI.[/quote]
Dans ce cas il faut créer une partition système EFI sur chaque disque contenant un système, et utiliser spécifiquement cette partition système EFI pour les chargeurs d’amorçage présents sur ce disque. Pour Debian, cela implique de marquer explicitement la partition qu’on veut utiliser comme partition système EFI qui sera montée implicitement ou explicitement sur /boot/efi, ou bien de débrancher tous les autres disques lors de l’installation (mais je soupçonne certains firmwares UEFI de supprimer les entrées d’amorçage correspondant à des disques qui ne sont plus présents). Néanmoins cela ne règlera pas le problème avec deux instances de Debian : par défaut la seconde remplacera l’entrée d’amorçage EFI de la première avec le même nom “debian”. Le seul moyen de l’éviter est de ne pas installer GRUB lors de l’installation, puis de l’installer manuellement ensuite avec un autre nom.

Cependant il y a quelque chose qui sera difficile à empêcher : que le dernier OS installé mette son chargeur d’amorçage en premier dans l’ordre de priorité du boot UEFI.

#13

Cela ne pose pas de problème, il suffit que je remette le bon disque en première position au premier démarrage.

Tu parles une langue qui m’est totalement inconnue :confused:

Ca c’est ce que j’avais effectué, il m’a fallu juste remettre en place la priorité de boot comme je la souhaitais après.

J’en aurais qu’une seule moi dans tous le cas :wink:

Est-il possible de simplement ne pas installer Grub ? Et quand même pouvoir booter par UEFI sur la partition ?

#14

Ne pas installer GRUB, c’est possible au moins en mode expert.
Mais il ne sera pas possible de booter directement sur ce système (en fait l’UEFI pourrait booter directement sur le noyau mais il faudrait configurer des choses et c’est moins souple que de passer par un chargeur d’amorçage comme GRUB). Il faudra passer par un autre chargeur d’amorçage (et donc le configurer aussi pour ajouter l’entrée de menu, soit manuellement soit automatiquement avec update-grub+os-prober mais le résultat peut ne pas être parfait, les paramètres à passer au noyau ne seront pas forcément bien récupérées.

#15

Bonsoir tout le petit monde !

J’ai entrepris des investigations légèrement plus poussée en réinstallant le système entièrement.
Résultat identique.

1448657966-img-20151127-210418.jpg700×196

Troisième installation avec des paramètres différents: Démarrage de la clef usb en “USB” et non “UEFI”
Résultat : le partitionnement proposé par l’installateur est différent, j’ai une partoche en moins dans la liste.
Les étapes de l’installation se suivent et se ressemblent. Étape finale, on me demande si Grub doit être installé sur le disque principal ou ailleurs (Cette étape ne m’était pas proposée quand la clef était démarrée en UEFI).

1448657967-img-20151127-212843.jpg700×421

Je choisis donc d’installer Grub sur le même disque que Linux (le ssd 64GO).
Fin de l’installation, je reboot, ca boot sur windows (Excellent =) c’est ce que je souhaitais) reboot, je choisis le bon disque pour boot : un curseur clignote continuellement. ctrl alt suppr, ça reboot et je repars sur windows sans aucun linux opérationel…

Est-il possible d’avoir des informations complémentaires me permettant de comprendre ce qui se passe dans mon foutu PC ?

Merci bien et sur ce, je vous souhaite une excellente soirée :wink:

#16

Bien mieux, les copies d’écran, merci.

[quote=“Reynosa”]J’ai entrepris des investigations légèrement plus poussée en réinstallant le système entièrement.
Résultat identique.[/quote]
C’est même pire : cette fois il y a aussi eu une erreur lors du chargement du noyau par GRUB, ce qui n’était pas le cas précédemment.

[quote=“Reynosa”]Troisième installation avec des paramètres différents: Démarrage de la clef usb en “USB” et non "UEFI"
Résultat : le partitionnement proposé par l’installateur est différent, j’ai une partoche en moins dans la liste.
Les étapes de l’installation se suivent et se ressemblent. Étape finale, on me demande si Grub doit être installé sur le disque principal ou ailleurs (Cette étape ne m’était pas proposée quand la clef était démarrée en UEFI).[/quote]
Ces différences s’expliquent par le mode d’amorçage différent.
En mode BIOS/legacy (non UEFI), une partition système EFI n’est pas nécessaire. En mode UEFI, GRUB est installé implicitement dans cette partition système EFI, c’est pourquoi l’installateur ne demande rien.

Note : Si Windows est détecté lors de l’installation en mode legacy, cela signifie que Windows doit démarrer dans ce même mode et non en UEFI et que Debian aussi pour que le multiboot soit possible dans GRUB (si jamais tu parviens à le faire démarrer).

Je ne vois pas pourquoi GRUB ne démarre pas en mode legacy. Tu es sûr d’avoir installé GRUB dans le MBR du bon disque ?
Tu peux relancer l’installateur en mode rescue, lancer un shell et vérifier la table de partition du disque. Regarde notamment le format de table de partition (GPT ou MBR/MSDOS) et si une partition est marquée comme bootable (inutile pour GRUB mais nécessaire pour certains BIOS).

#17

Je ne sais pas comment vérifier l’emplacement de l’installation de Grub. Une idée ?
Cependant quand la question m’a été demandée, j’ai choisi SCSI4 (étant donné que le ssd en question est sur le quatrième port de la carte mère et que depuis le début on parle de la lettre D pour le disque).

La première partition du SSD n’était effectivement pas équipé du flag de boot. cfdisk a fièrement résolu le problème.
Un redémarrage échoué m’a démontré que le problème ne venait pas de là ^^

Quand j’ai navigué les pages de partitions, j’ai vu quelque chose que je ne comprend pas. mon SSD fait 64GB, comment est-il possible d’avoir des partitions dont la somme des capacités dépassent la capacité nominale du support ?

1448705944-img-20151128-1043222.jpg700×430

#18 
┌─── 125045424 secteurs de 512 octets => 64023257088 octets ───┐  
▼                                                              ▼  
┌───┬──────────────────────────────────────────────────────────┐  
│   │  ┌───────────┐┌─────────────────────────────────────────┐│  
│   │  │           ││                 sdd2 50.3G              ││  
│   │  │           ││┌──────┐┌────────────────────────────────┤│  
│MBR│  │ sdd1 9.3G │││ sdd5 ││             sdd6               ││  
│   │  │           │││ 2.1G ││             48.3G              ││  
│   │  │           ││└──────┘└────────────────────────────────┤│  
│   │  └───────────┘└─────────────────────────────────────────┘│  
└───┴──────────────────────────────────────────────────────────┘  
  Secteur   ▴   ▴  ▴           ▴▴▴      ▴▴                                ▴▴  
0 ──┘   │  │           │││      ││                                ││  
1 ──────┘  │           │││      ││                                ││  
 2048 ─────────┘           │││      ││                                ││  
 19531775 ─────────────────────┘││      ││                                ││  
 19533822 ──────────────────────┘│      ││                                ││  
 19533824 ───────────────────────┘      ││                                ││  
 23865343 ──────────────────────────────┘│                                ││  
 23867392 ───────────────────────────────┘                                ││  
125044735 ────────────────────────────────────────────────────────────────┘│  
125045424 ─────────────────────────────────────────────────────────────────┘

NOTE : Je n’ai pas représenté les EBR contenus dans les partitions logiques.

[mono]sdd1[/mono] est une partition primaire
[mono]sdd2[/mono] est une partition étendue => conteneur pour des partitions logiques.
[mono]sdd5[/mono] et [mono]sdd6[/mono] sont les partitions logiques qui sont contenues dans la partition étendue [mono]sdd2[/mono]

#19

Depuis un système live ou un shell lancé depuis l’installateur en mode rescue sur la partition racine
le script [mono]boot-info-script[/mono] (paquet bootinfoscript) va rechercher toutes les informations de boot sur tous les disques présents.
Plus basique, la commande suivante

va afficher les chaînes de caractères présentes dans le MBR de /dev/sdX. Si l’amorce de GRUB y est installée, la chaîne GRUB devrait être affichée. Si la commande [mono]strings[/mono] n’est pas disponible, installer le paquet binutils.
Enfin, depuis un shell lancé depuis l’installateur en mode rescue sur la partition racine, la commande suivante affiche l’emplacement où est censé avoir été installé GRUB :

sous la forme d’un lien symbolique à nommage persistant /dev/disk/by-id/xxx qu’il faut suivre avec [mono]readlink -f[/mono] ou afficher avec [mono]ls -l[/mono] pour voir le nom de périphérique /dev/sdX.

La numérotation des ports SATA n’a rien à voir avec celle des périphériques SCSI ou assimilés et encore moins avec le nommage des périphériques disques /dev/sdX. Il faut noter les éléments d’identification affichés lors de la phase de partitionnement. Ou bien à n’importe quel moment, ouvrir un shell avec Ctrl+Alt+F2 et exécuter n’importe quelle commande permettant d’identifier les disques.

Quant à la lettre D, elle n’a strictement aucune signification pour un système GNU/Linux, et même pour DOS/Windows elle ne représente pas un disque mais un volume ou système de fichiers quelconque (partition, lecteur optique, partage réseau…).

La seconde partition est une partition étendue, un artifice qui sert de conteneur pour les partitions logiques dont la numérotation commence à 5. La somme des tailles des partitions logiques est égale à la taille de la partition étendue. Cet artifice est propre au format de table de partition MSDOS et n’existe pas en GPT.

#20

Bonjour à tous !

Ca fait un petit moment que je ne suis pas venu faire un tour par chez vous ^^ Sur-occupation professionnelle oblige :confused:

Hier soir j’ai décidé de me remettre dans mon problème après tout ce temps.
J’ai totalement oublié que j’avais des tests à mener sur l’installation défectueuse :blush:
Par conséquent après une rapide réinstallation à partir d’une netinstall de Jessie je suis dans l’incapacité de trouver une solution au problème posé initialement.
En effet, il m’est maintenant possible de boot sur Jessie :041

Désolé à ceux qui lisent ce message dans l’espoir d’avoir une solution au problème :confused: il vient de disparaître comme par magie chez moi…

J’ai bien encore un problème sur le boot mais ce n’est plus celui ci et cela fera partie d’un autre sujet ^^

Dans mon cas ici présent, je ne marquerai pas le sujet comme résolu, sachant que le problème initial n’a pas trouvé de solution… Je déteste lire tout un topic écrit comme résolu alors qu’à la fin le problème a disparu sans solution…

En tout cas, MERCI à vous tous pour l’aide apportée :wink: