Grub et choix au démarrage : le système par défaut ne se modifie pas malgré le GRUB_DEFAULT=2

Support Debian
,
Tags: #<Tag:0x00007f63e4a0ed40> #<Tag:0x00007f63e4a0eac0>
#1

Bonjour,

J’avais sur mon système Debian GNU/Linux 9.13 (stretch).

A cause d’un plantage (bad superblock), j’ai dû réinstaller Debian. Je l’ai fait sur un autre disque (SSD) en utilisant le même CD d’installation, la même image, 4.9.0-14-amd64.

En choix de démarrage, j’ai bien les deux versions, mais quoi que je fasse, l’ancien système est toujours en choix par défaut. Comment y supprimer l’ancienne version ou mettre en choix par défaut le nouveau système ?

Actuellement, l’ancien système est sur /dev/sda9 (non monté) et le nouveau sur /dev/sdc2 .

Ce que j’ai fait et regardé :

Quand je met le nouveau disque SSD en priorité de démarrage dans le bios, l’ordi reste bloqué sur le curseur clignotant.

Quand je recherche les OS installés, le résultat ne me donne que l’ancien système :

os-prober
/dev/sda9:Debian GNU/Linux 9 (stretch):Debian:linux

J’ai modifié le grub_default :

cat /etc/default/grub
…
GRUB_DEFAULT=2

(ancien système position 0, nouveau système position 2)

J’ai aussi ce GRUB_DEFAULT=2 dans l’ancien système.

Je n’ai pas oublié le :

update-grub

La commande :

dpkg -l | grep -Ei « linux-(g|h|i|lo|si|t) »

donne :
Les deux systèmes montés :

ii linux-headers-4.9.0-14-amd64 4.9.240-2 amd64 Header files for Linux 4.9.0-14-amd64
ii linux-headers-4.9.0-14-common 4.9.240-2 all Common header files for Linux 4.9.0-14
ii linux-headers-amd64 4.9+80+deb9u12 amd64 Header files for Linux amd64 configuration (meta-package)
ii linux-image-4.9.0-14-amd64 4.9.240-2 amd64 Linux 4.9 for 64-bit PCs
ii linux-image-amd64 4.9+80+deb9u12 amd64 Linux for 64-bit PCs (meta-package)
ii util-linux-locales 2.29.2-1+deb9u1 all locales files for util-linux

Uniquement le nouveau système monté :

ii linux-image-4.9.0-14-amd64 4.9.240-2 amd64 Linux 4.9 for 64-bit PCs
ii linux-image-amd64 4.9+80+deb9u12 amd64 Linux for 64-bit PCs (meta-package)
ii util-linux-locales 2.29.2-1+deb9u1 all locales files for util-linux

J’ai pensé à supprimer les 3 images supplémentaires quand les deux systèmes sont montés avec la commande :

apt remove --purge linux-…

mais je crains que l’ordi ne démarre plus !

Merci à vous pour l’aide que vous pourrez m’apporter.

.

#2

A ta place j’en aurais profité pour installer la version 10 qui est la version stable actuelle. La version 9 est en LTS, elle n’est plus supportée officiellement par Debian.

Chargeur d’amorçage pas installé ou mal installé sur ce disque.

Depuis quel système ? Si c’est depuis le nouveau, c’est normal, il ne se cherche pas lui-même.

Si l’ancien système est en position 0 dans le menu de GRUB, alors c’est le GRUB de l’ancien système qui est lancé, et modifier la configuration du GRUB du nouveau système est sans effet.

Que veux-tu dire exactement par « monté » ? On monte un système de fichiers, pas un système d’exploitation. On ne peut démarrer qu’un système à la fois, un noyau à la fois.

Quelles images supplémentaires ? Les paquets en plus ne sont pas des images mais des en-têtes du noyau, pour compiler les modules externes ou des applications très liées au noyau.

Suggestion : installer le paquet boot-info-script, exécuter la commande bootinfoscript et poster le rapport.

#3

J’ai un vague souvenir d’une histoire de UUID mais sans plus de précision.

#4

Bonjour et merci pour vos réponses.

Effectivement, je n’y ai pensé qu’après la réinstallation de Stretch !

J’ai certainement fait une erreur concernant le chargeur d’amorçage, je ne savais pas trop quelle option choisir.

J’ai aussi mis le « GRUB_DEFAULT=2 » pour l’ancien système.

J’ai monté le système de fichiers /dev/sda qui correspond à l’ancien système. (Il s’est retrouvé monté dans /media)

J’avais lu sur internet qu’il fallait supprimer ces « images » que l’on ne souhaite pas utiliser, style les 3 ii linux-headers-…

Rapport de bootinfoscript en fichier joint.
RESULTS1.txt (45,8 Ko)

Le Boot Info Summary de ce fichier :

=> Grub2 (v1.99) is installed in the MBR of /dev/sda and looks at sector 1 of
the same hard drive for core.img. core.img is at this location and looks
in partition 85 for .
=> No boot loader is installed in the MBR of /dev/sdb.
=> Grub2 (v1.99) is installed in the MBR of /dev/sdc and looks at sector 1 of
the same hard drive for core.img. core.img is at this location and looks
in partition 85 for .

#5

D’après le rapport, GRUB est bien installé sur sdc.

A quelle étape reste-t-il bloqué ? Avant le menu de GRUB ? Après ? Qu’est-ce qui est affiché ?
Est-ce bien le nouveau SSD qui démarre dans ce cas ? Peux-tu sélectionner le disque au moment du démarrage, via le boot menu du BIOS ?

En tout cas on voir que ça n’a pas été propagé dans /grub/grub.cfg de sda2 (en exécutant update-grub depuis le système installé sur sda9).

Et c’est tout ? Ce n’est pas ça qui le rend actif, ni qui change le résultat de dpkg. Pas de chroot ?

Je répète : ce ne sont pas des imagesde noyau. Ce sont des en-têtes de compilation. Ils n’ont aucune influence sur le démarrage.

#6

Il reste bloqué avant le menu GRUB, écran noir et curseur clignotant.

Je n’ai jamais utilisé chroot, je ne connaissais pas cette commande avant que tu en parles.

J’avais juste modifié le /grub/grub.cfg, pensant que ce serait pris en compte au prochain reboot !
Après avoir lu cette réponse, j’ai tenté ce matin de démarrer l’ordi sur l’ancien système en mode dépannage, ne connaissant pas assez chroot. Il a fallu de nombreuses tentatives pour que j’y accède sans plantage.
J’ai fait un update-grub et un reboot, et le nouveau système sur sdc était sélectionné par défaut.

Concernant la suppression de l’ancien système dont le nouveau dépend, je le ferai en installant Buster.

Un grand merci à @PascalHambourg qui a résolu mon problème que je tentais de résoudre depuis de nombreuses semaines.

#7

Le vrai problème, c’est pourquoi GRUB ne démarre pas sur sdc, et il n’est pas résolu. Tant qu’il ne le sera pas, le système installé sur sdc sera dépendant du GRUB installé sur sda. Pas très enviable.

/grub/grub.cfg ou /etc/default/grub ?

Tout autre chose : j’ai vu dans le rapport de bootinfoscript qu’une partition de swap inexistante était définie dans le fstab de sda9 et un espace vide non alloué au début de sda. Ne serait-ce pas liés au problème de démarrage de l’ancien système ?

#8

C’est /etc/default/grub

Normalement, c’était le swap en /dev/sda1. C’est peut-être lié au problème de démarrage, malgré que j’ai démarré dessus hier.
Mais la majorité des erreurs qui s’affichaient avant la réinstallation était dûe à des « bad superblock ».

En effet, ce n’est pas très enviable. Le principal est que sdc est mis par défaut. Pas besoin de rester devant mon ordi pour sélectionner le système.
Et je n’utiliserai pas les partitions de sda dont sdc dépend. Un peu moins de 100 Go sur les 1,740 To.