Astucien ![]() | Bonjour, Résumé : Sur mon PC, j'ai plusieurs OS : W7 Sp1 - Linux Mint 17.3 - Archlinux - Debian Stretch 9.04. Par facilité, j'ai choisi Mint comme fournisseur de Grub (en installant les autres W7, Archlinux et Debian 9.04 dans /etc/grub.d/40-custom). Tout allait bien jusqu'au jour au mon BIOS m'a alerté (avec smart) en disant que l'un de mes disques (/dev/sdb) était sur le point de rendre l'âme, me suggérant un rapide sauvetage des données avant qu'il soit trop tard. Sur ce disque, il y avait une grande partition NTFS (/dev/sdb1) contenant des centaines de fichiers (MP3, AVI, etc...) tombés du ciel Donc, j'ai installé un disque supplémentaire (1 teraoctet - /dev/sdc) que je me suis empressé de partitionner pour créer une grande partition de 750 Go dans laquelle j'ai transféré le contenu de /dev/sdb1, le surplus restant non alloué. Après moultes tentatives et malgré les précieux conseils de Logicien, il m'a fallu me résoudre à installer une nouvelle Debian 9.04 (avec le même disque d'installation) dans deux partitions logiques (/dev/sdc5 et 6) prélevées sur l'espace non alloué.
Mon problème est le suivant : Quand j'ai installé ma nouvelle Debian, le panneau grub (affreux) affichait tous les OS (y compris la Debian menacée). J'ai fait quelques essais et tout semblait bien marcher. Puis, comme d'habitude, je suis passé sous Mint et j'ai exécuté grub-install /dev/sda suivi de update-grub et j'ai retrouvé mon menu grub habituel. Ce matin, j'allume mon PC et je choisi de démarrer ma nouvelle Debian : plantage avec quelques lignes disant en gros qu'il ne trouve pas hd2... (5a899E59-4349-4811-9b1a-1c2ea0648a61). Blkid ne trouve rien de comparable. Bon, je me dis qu'il y a incompatibilité d'humeur entre le grub de Mint et Debian en conséquence de quoi, depuis Arch, je chroote dans /dev/sdc5 et je re-crée le grub de Debian. Sortie de chroot, redémarrage et affichage de l'affreux menu grub de Debian. Je lance Arch et là, enfer et damnation, plantage direct avec un message de kernel panic (moi aussi, je panique). Je repasse sous Mint et je re-crée un grub qui m'affiche mon écran habituel. Je choisis de démarrer Arch qui, ouf, démarre normalement. En revanche, ma nouvelle Debian plante misérablement (trouve pas hd2) alors que l'autre (celle qui est menacée) démarre sans problème. Je dois dire que je n'y comprends plus rien. Au pire, je me passerai de la nouvelle Debian jusqu'à ce que le disque menacé rende l'âme. Voilà.
| |||||||
Publicité | ||||||||
Astucien | Salut,
Peux-tu faire un rapport boot-info depuis ta Mint installée, avec ta debian qui plante ? Il donnera peut-être des infos utiles. Modifié par Ikewdu_ le 21/05/2018 15:47 | |||||||
![]() ![]() | Merci pour ton intérêt à mon problème. Mais, la question se résume à ceci : SI je crée un grub depuis Debian, Archlinux plante : kernels panics. Si je crée un grub avec mint, Debian plante : hd2 introuvable. Conclusion : je crois que je vais virer Debian vu que je suis satisfait avec Mint et Arch (sans parler de W7 SP1 qui ne m'a quasiment jamais posé problème). Entrre nous : qu'est-que j'en ai faire de Debian : j'ai bien mieux avec Arch. | |||||||
Astucien | A toi de voir... Je n'avais de toute manière pas de solution toute faite... | |||||||
Astucien ![]() |
Aviez-vous essayé cette commande-ci sur votre nouvelle install de Debian :
sudo apt-get install --reinstall grub-pc grub-common
Rien a perdre a essayer .. | |||||||
Astucien ![]() |
Mais au faite .. la commande que je viens de vous suggèré doit-etre faite sur la distro que vous voulez avoir le boot-loader ( Grub ) ..
| |||||||
Petit astucien ![]() | Bonjour Mimile.
Je suis également en multiboot (dual en fait). J'installe le Grub choisi à partir du média d'installation (dont je veux le Grub - Manjaro dans mon cas) sur lequel je boote et entre la commande en su ou sudo: (sudo) grub-install --root-directory=/media/Pt_de_montage /dev/sda (sda en principe pour le hdd interne) ou (sudo) grub-install --root-directory=/run/media/Pt_de_montage /dev/sda (selon distribs)
Sinon, j'avais essayé d'installer, il y a a peu, une Debian 9 qui m'avait posé problème. Abandonnée... Donc.
@+ | |||||||
Astucien |
Mimile et Sil33, Quel bureau utilisez vous sur votre Debian?
| |||||||
![]() ![]() | Je pense qu'il serait temps que tu enlèves le disque défectueux sdb et que tu connectes ton nouveau disque sur les connecteurs de ton disque défectueux. Cela ferait que ton nouveau disque deviendrait sdb et ça te ferait un disque de moins à intégrer au menu de Grub. Tu aurais sda pour Linux et hd0 pour Grub et sdb pour Linux et hd1 pour Grub. Il se peut que update-grub commette des erreurs dans la fabrication des entrées du menu de Grub mais je pense aussi que tu dois avoir des erreurs dans les entrées que tu as créées dans /etc/grub.d/40_custom de Mint. Il faut penser à dire à Grub où chercher (hd0, hd1, etc) et quelle partition ( (hd0,1) , (hd1,2) , etc) et dire au noyau Linux où est la partition racine (root=/dev/sdb5 par exemple). De plus, il faut que les lignes dans /etc/fstab de chaque système correspondent à l'endroit ou la partition à monter est. Utiliser le UUID d'un disque ou d'une partition est supposé contourner les problèmes liés à l'endroit où est le disque et/ou la partition mais, on peut toujours utiliser hd0, hd1 (Grub) et sda, sdb (Linux) si on sait ce que l'on fait. Comme tu as déjà Linux Mint d'installée, je concois que tu n'as pas besoin de Debian. Ma politique étant de n'installer qu'une Debian ou une dérivée pour ne pas avoir de systèmes plus ou moins identiques. Modifié par Logicien le 26/05/2018 13:44 | |||||||
Publicité | ||||||||
![]() ![]() | Salut à tous et merci de l'intérêt que vous portez à mon cas. Je constate diverses choses :
J'ai évidemment modifié tous les fstab vu que chaque fois que je change de grub, une partition (particulièrement SWAP) change d'UUID. Pour le moment, je dors mieux : Mint, W7 et Arch fonctionnent bien en conséquence de quoi, Debian devient la 5ème roue du char (celle qui ne sert à rien). Je n'ai qu'un souci : j'ai souvent tripoté des PC dont les connexions disques étaient des IDE, sans problème. Mon PC actuel (enfin, plus vraiment actuel) travaille avec des des disques SATA et je dois avuer que je ne sais pas comment :
Un Conseil ?
Modifié par Mimile le 22/05/2018 18:00 | |||||||
![]() ![]() | Sacré Mimile, il y a le connecteur pour le courant de la carte-mère vers le disque dur qui diffère du connecteur Sata de la carte-mère vers le disque dur. Tous les deux doivent être branchés, le premier pour l'énergie et le second pour les données. Le connecteur en L du câble Sata est celui pour le disque Sata et l'autre évidemment pour la carte -mère. https://www.materiel.net/live/211320.png Modifié par Logicien le 22/05/2018 19:14 | |||||||
Astucien | Re,
Sur beaucoup de PC, et donc de Bios, le dernier disque SATA connecté passe en tête de liste, et le PC boote dessus si un secteur de boot est trouvé. Dans ton cas, si ton disque SATA contient un grub dans le mbr ou la partition efi, c'est lui qui sera exécuté, Je reste en attente d'un rapport boot-info afin de voir si une explication serait décelable... Même si tu n'utilises pas ta debian, comprendre le pourquoi du comment est toujours préférable. | |||||||
Petit astucien | Salut https://doc.ubuntu-fr.org/tutoriel/boot-info Dès fois que... Paquet dispo dans les dépôts Debian (boot-info-script) et sous Arch dans AUR (bootinfoscript)
Modifié par R136a1 le 23/05/2018 15:46 | |||||||
Astucien ![]() | Bonjour, Ou encore (Comment céer un rapport Boot-Info) : https://doc.ubuntu-fr.org/tutoriel/boot-info Des fois que ... On ne sait jamais ...
Modifié par Slyvester le 23/05/2018 17:07 | |||||||
![]() ![]() | @ Ikewdu_ -r136a1 Slyvester : Le boot-info (bootinfoscript sous Arch) se trouve ici : boot-info (trop long pour un affichage direct) A noter qu'il est indiqué en sda7 que l'OS est Ubuntu. C'est inexact vu que je n'ai jamais installé Ubuntu sur ce PC. En fait, en sda7, il y a la racine de Linux Mint 17.3 (mais évidemment, on sait que Mint est directement dérivée d'Ubuntu, ceci expliquant probablement cela. Cordialement Modifié par Mimile le 26/05/2018 07:00 | |||||||
Astucien | Re, Désolé du retard, mais j'avais quitté le sujet. - La mention Ubuntu 14-04 est normale, car Mint 17 est basée sur cette version d'Ubuntu. Pour ton souci, on va procéder par élimination (pour l'instant, on se limite à ce que font tes grub). Tu as 4 fichiers grub.cfg qui correspondent à tes 4 Linux : un sur - sda5 ( Arch ). Ce grub n'est paramétré que pour lancer Arch (et ses différents noyaux) et rien d'autre. - sda7 (Mint 17). Celui-ci est visiblement apte à lancer Mint (et ses différents noyaux) Tu as paramétré 40-custom pour lancer Windows et Arch, mais je ne vois aucune trace de debian (quel que soit le disque dans ce fichier grub. Je m'étonne aussi du contenu de 41_custom qui recopie une partie du début du fichier 10_linux (pourquoi as-tu fait cela ?) - sdb5 et sdc5 (ta debian installée sur ce que je suppose être tes disques clonés). Le grub de sdb5 est supposé lancer debian, puis via le fichier 30_os-prober (donc automatiquement, via un sudo update-grub je suppose), une W7, une Arch et une Mint (dans cet ordre). Mais, tu y as aussi ajouté des entrées dans 40_custom qui pointent vers une Windows et une Arch (donc, tu dois avoir dans ce cas des entrées redondantes). Le grub de sdc5 est supposé lancer une debian, puis via le fichier 30_os-prober, une W7, une Arch, une Mint + une autre debian. Mais là, cette fois, tu n'as pas de paramétrage de 40_custom Donc, si je résume, ni Arch ni Mint ne lancent actuellement ta (ou tes) debian. L'un des disques clonés lance une debian seulement (mais plusieurs fois W7 et Arch), alors que l'autre lance théoriquement deux Debian (sans vérif des UUID. Bref, c'est un beau foutoir.
J'ai cru comprendre que tu veux booter sur le grub de Mint. Confirme-le. Si tu as déjà ce grub qui se lance au démarrage, tu ne devrais donc pas voir tes Debian. Si ce n'est pas le cas, fais une photo de ce qu'affiche ton Grub au démarrage.
Tant que j'y suis, ceci est également étrange : => Windows 7/8/2012 is installed in the MBR of /dev/sdb. => libparted MBR boot code is installed in the MBR of /dev/sdc. On peut comprendre que le mbr de sdb contienne des informations windows (même si on s'attendrait à trouver un grub de l'installation debian), mais c'est déjà plus étrange de trouver un "libparted mbr" dans sdc (serait-ce le disque HS ?) Il semblerait que libparted mbr boot soit une trace d'une installation d'une Lubuntu buguée.... A confirmer. Modifié par Ikewdu_ le 26/05/2018 13:45 | |||||||
![]() ![]() | Salut, Le fait qu'aucune Debian ne soit lancée résulte du fait que, lassé des erreurs et problèmes rencontrés par Debian, j'ai supprimé leurs menuentry de 40-custom de Mint (je confirme que c'est avec Mint que je crée mon grub). Je présume que c'est lors de l'installation de Debian9 (la première) que Windows s'est retrouvé dans le MBR de/dev/sdb. Pourtant, j'avais bien précisé que je voulais installer grub sur le MBR de /dev/sda. Idem pour libparted (sur /dev/sdc (le nouveau disque). Une fois ces installations terminées, je suis repassé sous Mint, j'ai ajouté le menuentry de Debian dans 40-custom puis j'ai exécuté grub-install /dev/sda suivi de update-grub pour retrouver mon menu grub plus élégant que celui de Debian. Ce menu n'affiche donc que :
Ce qui m'agaçait, c'est que la première Debian que j'ai installée (/dev/sdb) continue de fonctionner impeccablement, tandis que la nouvelle installation (/dev/sdc) se plaint de ne pas trouver hd2 ! et freeze le PC. Comme /dev/sdb est régulièrement l'objet d'alerte SMART du BIOS, j'ai décidé de m'en passer. L'autre Debian (/dev/sdc), n'en parlons pas. Voilà. Merci pour ton analyse. | |||||||
Publicité | ||||||||
Astucien | J'anticipe sur la suite... Depuis ta version de Mint, il faudra vérifier que le fichier 30_os-prober est activé : ikewdu@ikewdu-fixe ~ cd /etc/grub.d 00_header 10_linux 20_linux_xen 30_uefi-firmware README ikewdu@ikewdu-fixe /etc/grub.d $ Apparaîtront en vert les fichiers qui sont exécutables (memtest86+ est inactif chez moi... ). Selon moi, chez toi, 30_os-prober ne le sera pas. Il faudra alors l'activer, et on en profitera pour désactiver provisoirement 40_custom et 41_custom. Donc (commande chmod +x ou -x), ikewdu@ikewdu-fixe /etc/grub.d sudo chmod +x 30_os-prober La commande ls devrait renvoyer : ikewdu@ikewdu-fixe /etc/grub.d ls 00_header 10_linux 20_linux_xen 30_uefi-firmware README ikewdu@ikewdu-fixe /etc/grub.d A ce stade, tu pourras relancer le processus d'installation de Grub : ikewdu@ikewdu-fixe /etc/grub.d sudo grub-install (la cible /dev/sda est en principe inutile) Là, on met grub à jour : la liste de ce qui est bootable apparaîtra : ikewdu@ikewdu-fixe /etc/grub.d sudo update-grub Création du fichier de configuration GRUB… Là, il faudra essayer ce qui fonctionne et ce qui ne fonctionne pas... Si tu veux ensuite réutiliser le fichier 40_custom, il n'y aura qu'à le réactiver, copier les lignes adéquates de 30_os-prober à l'intérieur ; activer l'un et désactiver l'autre. Et pour finir, un sudo update-grub. Si la debian ne fonctionne toujours pas, il faudra inspecter les UUID, mais aussi se pencher sur cette histoire de mbr douteux.
Modifié par Ikewdu_ le 28/05/2018 07:39 | |||||||
![]() ![]() | Bravo pour ton obstination. Par curiosité, je viens de remettre le menu_entry de ma première débien (celle qui marchait bien avant que l'alerte SMART BIOS ne résonne). Ben, il faut dire que je ne rencontre aucun problème : ma (première) debian (sur /dev/sdb) fonctionne nickel. La preuve : je suis en train d'écrire sous cette première debian. Par contre, quand j'ajoute le menu_entry de ma debian de secours (sur /dev/sdc) : rien ne va plus. Qu'est-ce-que c'est ce bignz ?
Modifié par Mimile le 27/05/2018 14:43 | |||||||
Astucien | Ce que je ne comprends pas, c'est pourquoi tu passes absolument par une manipulation manuelle pour tes tests. Tu devrais réactiver (au moins provisoirement) le fichier 30_os-prober, afin de voir si cette seconde Debian est détectée. En fonction du résultat, on saura où chercher. Si elle se lance, c'est que ta procédure manuelle (qu'on n'a pas vue puisque tu l'as supprimée pour le boot-info) n'est pas bonne, et si elle ne se lance pas, c'est qu'il y a quelque chose qui cloche sur le disque sdc, et il faudra s''intéresser de près à ce mbr étrange.
Modifié par Ikewdu_ le 28/05/2018 07:42 | |||||||
![]() ![]() | Cher Ikewidu Merci pour tes efforts, mais celui de nous deux qui ne comprend pas, c'est moi. Toutes ces manips me fatiguent et je n'en comprends pas la moitié. Par exemple :
Les lignes adéquates ??????????????? Merci pour ton aide. Mais, désolé, avec moi, il faut être TRES explicite. Cela dit, Ma 2ème Debian marche en TTY2. De toute façon, je vais virer les 2 Debian qui ne me font que du temps perdu. Encore merci. Amicalement
| |||||||
Astucien ![]() |
(( De toute façon, je vais virer les 2 Debian qui ne me font que du temps perdu.)) ..
Je trouve cela domage , car personnellement --> je trouve Debian solide comme un Rock et plus fiable que Arch .. | |||||||
Astucien | Re,
En fait, c'est toi qui laisses croire que tu maîtrises le paramétrage de Grub. Ceux qui manipulent 40_custom pour personnaliser le démarrage ne sont pas si nombreux. Il suffit de savoir (quand on ne veut faire les choses simplement) qu'on écrit dans ce fichier les mêmes lignes que ce 30_os-prober va générer dans grub.cfg. Voilà ce que j'appelle les lignes adéquates. Il est clair que si tu recopies dans 40_custom des lignes qui viennent de je ne sais quelle source, et qu'un seul paramètre est erroné, ça peut ne pas démarrer. C'est pourquoi j'aurais déjà réactivé 30_os-prober pour voir comment il aurait, lui, géré tes différentes versions de Linux. Après, on aurait avisé. Et d'accord avec m_n... ta solution n'est pas très bonne, car elle ne résout rien. Modifié par Ikewdu_ le 29/05/2018 19:13 | |||||||
![]() ![]() | Je pense qu'il faut surtout être à la hauteur de ce qu'on fait afin d'arriver à quelque chose. Ikewdu, si on utilise 40_custom ce n'est pas pour copier ce que os-prober écrit dans /boot/grub/grub.cfg. Ce n'est que dupliquer. 40_custom c'est pour les entrées spéciales ou pour gérer soi-même le menu de Grub sans les scripts dans /etc/grub.d qui créent des entrées comme os-prober. Si on ne sait pas créer une entrée dans 40_custom c'est vrai qu'on est mieux de laisser les scripts de /etc/grub.d faire le travail dont os-prober. Mimile, je pense que Ikewdu a raison. Si tu n'es pas certain de ce que tu fais dans 40_custom, laisse os-prober de Mint faire le travail et met en remarque ce que tu as écrit dans 40_custom de Mint. Ce n'est pas normal de passer d'une distribution à l'autre pour démarrer un système. Je suis certain que Grub de Mint peut faire tout le travail de démarrer tous tes systèmes. Mais si tu as trop de systèmes d'installés pour te comprendre je suis d'accord avec toi pour supprimer ceux que tu n'utilises pas. Un système est un logiciel comme un autre malgré tout. On peut l'installer, l'ouvrir, le fermer et le supprimer. Modifié par Logicien le 29/05/2018 19:33 | |||||||
Astucien | Salut, On est bien d'accord... On ne devrait pas utiliser 40_custom sauf dans des cas très particuliers (pour éviter de lancer une console Winre, ou une image d'usine, un passage par le bios, par exemple). Mais dans le cas présent (en comparant l'automatique, et le manuel), ça aurait servi à éliminer des pistes, compte tenu que le boot-info proposé ne montrait pas le contenu de ce fichier (supprimé préalablement). Une fois le problème identifié, le script peut bien sûr être modifié (voir mon exemple plus bas). Pour le reste, le fonctionnement de grub étant différent d'un système à un autre (et on ne peut pas tout connaître), un passage par la détection automatique de chaque système permet parfois de résoudre des problèmes qu'on ne peut expliquer directement. Par exemple, dans le sujet qui suit (un dual boot Mint / Fedora en uefi), je n'aurais pas pu trouver l'origine des problèmes de démarrage ou de graphisme sans passer par la comparaison avec la procédure automatique (qui m'a montré que certaines instructions diffèrent d'une distribution à l'autre) : http://ikewdu.free.fr/dual-boot-mintubuntu-avec-fedora-en-uefi/ Bref, j'aurais peut-être pu trouver les réponses sur un forum, mais le faire ainsi m'a permis de comprendre le souci par moi-même. | |||||||
![]() ![]() | Cher Paul Je te cite: je pense que Ikewdu a raison. Si tu n'es pas certain de ce que tu fais dans 40_custom, laisse os-prober de Mint faire le travail et mets en remarque ce que tu as écrit dans 40_custom de Mint Désolé, mais je n'y comprends rien. Dois-je neutraliser quelques "menuentries" dans 40_custom pour les insérer dans 30-os_prober ? Tout ça me semble bizarre ... Modifié par Mimile le 30/05/2018 18:36 | |||||||
Publicité | ||||||||