BOOT : option boot debian12 disparue après MAJ noyau linux + MAJ Windows10

Support Debian
,
Tags: #<Tag:0x00007f509b1f73e8> #<Tag:0x00007f509b1f7320>
#1

Bonjour,

J’ai installé Debian 12 en dual boot d’un système Windows 10 existant en septembre 2023 (partitionnement GPT donc BIOS-UEFI). J’ai séparé dans différentes partitions /, /var, /tmp, /home.

Jusqu’à hier le 16/12/2023, j’ai fait un certain nombre de mises à jour de Debian dont le noyau linux : exemple = mise à jour noyau vers linux-image-6.1.0-15-amd64 le 14/12/2023. Sur cet exemple-là en particulier, j’ai constaté que la mise à jour noyau avait un impact sur GRUB :

  1. D’après la liste des commandes exécutées affichées dans le terminal lors de l’application de la mise à jour (dont os-prober)
  2. En l’occurrence, au redémarrage de mon ordinateur, l’option de boot Debian était ignorée et la machine lançait directement Windows (avec l’option de boot Windows donc)
  3. Après un nouveau redémarrage, je retrouvais le menu GRUB à nouveau avec (contrairement à la fois d’avant)

Jusque là, je n’étais pas très étonné sachant que la mise à jour avait impacté GRUB et que je retrouvais celui-ci, fonctionnel, après un 2nd redémarrage.

Hier le 16/12/2023, je constate que les dépôts Debian proposent une nouvelle mise à jour noyau linux-image-6.1.0-16-amd64, je procède donc à la mise à jour et vois que des commandes s’exécutent cette fois-ci encore sur GRUB. Je m’attends donc à voir les mêmes effets que ceux décrits dans la liste numérotée ci-dessus. Toutefois :

  1. Au lancement de Windows qui arrive au 1er redémarrage, je passe un peu de temps sur cet OS au lieu de redémarrer illico
  2. Je ne me rends pas compte à ce moment-là que Windows télécharge à son tour des mises à jour (2023-12 Mise à jour cumulative pour Windows 10 Version 22H2 pour les systèmes x64 (KB5033372))
  3. Je finis par arrêter Windows en sélectionnant Appliquer les mises à jour et arrêter
  4. La mise à jour WIndows s’applique et l’ordinateur s’arrête
  5. Au 2e redémarrage, je vois le menu GRUB apparaître avec les options Debian et Windows, je sélectionne Windows
  6. Après ce nouveau lancement de Windows, j’arrête à nouveau le système
  7. Au 3e redémarrage, je consulte les options de boot dans le BIOS-UEFI : l’entrée Debian-GRUB a disparu !

Depuis, l’option de boot Debian-GRUB n’est plus disponible.
Je suppose que cette option de boot a été supprimée avec la mise à jour WIndows arrivée en 2nde alors que Debian ne s’était pas lancé « pour de bon » après sa propre mise à jour.

J’envisage d’appliquer la méthode chroot suggérée par @PascalHambourg ici : DEBIAN 12 installé en dual boot après WIN10 - GRUB absent des options boot - 03/09/23 11:33 et DEBIAN 12 installé en dual boot après WIN10 - GRUB absent des options boot - 03/09/23 00:27 ; en utilisant le live USB que j’ai utilisé à l’installation de Debian.
Cependant, je voudrais être bien assuré des commandes que je dois appliquer avant d’arriver sur un terminal. J’ai trouvé plusieurs sources assez détaillées pour appliquer cette méthode « chroot » :

  1. linuxtrick.fr : chroot sous Linux : Explications et exemples
  2. ubuntu-fr.org : Chroot : changement de dossier racine

Ci-dessous les commandes que je prévois d’appliquer dans un terminal de la session live-USB, une fois que j’aurai identifié avec lsblk -f :

  • le n° de la partition racine sur mon disque (partition désignée ‹ sdXY › ici)
  • le n° de la partition /boot/efi sur mon disque (partition désignée ‹ sdXZ › ici)

su
… j’ai un doute sur ce qui va s’afficher dans le terminal de la session live-USB, car j’ai déjà essayé de monter une partition de l’installation Debian via l’explorateur de fichiers de la session live-USB, en vain : le mot de passe root de Debian installé ne convient pas
mkdir /media/system
mount /dev/sdXY /media/system
mount /dev/sdXY/var /media/system/var
mount /dev/sdXY/tmp /media/system/tmp
mount --bind /dev /media/system/dev
mount -t proc /proc /media/system/proc
mount --bind /run /media/system/run
mount -t sysfs /sys /media/system/sys
mount -t efivarfs efivarfs /sys/firmware/efi/efivars (j’ai un doute sur l’utilité de cette ligne [car /sys monté sur /media/system/sys ci-dessus] et sur la syntaxe)
mkdir /boot/efi
mount /dev/sdXZ /boot/efi
chroot /media/system /bin/bash
apt install grub-efi-amd64
grub-install
vi /etc/default/grub
changement de ‹ GRUB_DISABLE_OS_PROBER › en ‹ GRUB_DISABLE_OS_PROBER=false ›
update-grub
exit
umount /boot/efi
umount /sys/firmware/efi/efivars
umount /media/system/sys
umount /media/system/run
umount /media/system/proc
umount /media/system/dev
umount /media/system
exit

Cet enchaînement de commandes est-il correct ?

Merci par avance pour vos retours.

#2

salut
je ne suis pas spécialiste de cette question mais mon chroot pour ce genre de problème ( avec une seule partition pour / , pas de question de os_prober) et qui a déjà marché est :
mkdir -p /mnt/chroot
mount /dev/sda1 /mnt/chroot
mount -o bind /dev /mnt/chroot/dev
mount -o bind /sys /mnt/chroot/sys
mount -o bind /proc /mnt/chroot/proc
chroot /mnt/chroot
update-grub
si ça peut t’aider

PS
différences en regardant ton code :
je ne monte pas sysfs, je n’utilise pas d’option spéciales ( toujours -o)
par contre tes lignes
mount /dev/sdXY/var /media/system/var
mount /dev/sdXY/tmp /media/system/tmp
me semble bizarres,
tu devrais avoir me semble-t-il
`mount /dev/sdXY /media/system

mount /dev/sdXY’ /media/system/var

mount /dev/sdXY" /media/system/tmp`
puisque ce sont des paritions différentes

#3

Bonjour @dindoun,

Merci pour ton retour. Dans quelles circonstances as-tu besoin de faire ce genre de manip’ ?

Concernant ton PS :
J’ai prévu les commandes « mount /dev/sdXY/var /media/system/var » et « mount /dev/sdXY/tmp /media/system/tmp » selon les recommandations de PascalHambourg dans sa réponse ici, sachant que j’ai séparé les répertoires /, /var, /tmp, /home sur des partitions différentes à l’installation de Debian.
En y réfléchissant maintenant suite à ton PS (je n’ai pas encore testé lsblk -f), je pense en effet que je devrais peut-être faire plutôt :

mount /dev/sdXV /media/system/var où ‹ sdXV › est le nom de la partition de /var de ma Debian
mount /dev/sdXT /media/system/tmp où ‹ sdXT › est le nom de la partition de /tmp de ma Debian

#4

salut
a priori tu peux faire confiance à ce qu’a dit pascal hambourg, bien que je n’ai pas vérifié

pour les deux mount ça me parait évident

quand j’ai eu des problèmes de grub ( 3 fois ) j’ai toujours fait ça , j’ai d’alleurs un fichier pour m’en rappeler et refaire la même chose

l’idée « je monte en chroot, je change les options de grub, je lance update-grub » est en plus sans grand risque ( faire quand même une sauvegarde des fichiers que tu changes)

1 J'aime
#5

@dindoun,

Vu qu’il s’agit chez moi d’un problème survenu sur un GRUB parfaitement installé et qui fonctionnait, tu penses que je pourrais lancer directement update-grub sans exécuter auparavant apt install grub-efi-amd64 puis grub-install ?
Pour la sauvegarde préalable des fichiers existants, j’ai seulement besoin de sauvegarder /etc/default/grub ? Ou y en a-t-il d’autres ?

#6

Le seul impact de la mise à jour du noyau sur GRUB est l’exécution de update-grub pour regénérer le menu de GRUB. En aucun cas cela n’affecte la façon dont GRUB est enregistré dans la configuration d’amorçage UEFI de la machine. Seuls l’exécution de grub-install (manuellement via la mise à jour du paquet grub-efi-amd64), le programme efibootmgr, un autre OS comme Windows ou le firmware UEFI de la machine le peuvent. La mise à jour 12.4 de bookworm n’a pas apporté de mise à jour de grub donc « l’impact » que tu décris ne peut pas être dû à celle-ci.

Les recettes que je suggère ne sont pas forcément applicables à tous les cas, je fais du sur-mesure.
Si GRUB est toujours installé dans le répertoire /EFI/debian de la partition EFI, plutôt que s’embêter à faire un chroot et réinstaller GRUB, il est plus simple de recréer une entrée de boot EFI pour Debian avec efibootmgr. Exemple pour une partition EFI /dev/sda1 (disque /dev/sda, partition 1) :

efibootmgr --create --disk /dev/sda --part 1 --label debian --loader '\EFI\debian\shimx64.efi'

(les guillemets simples sont importants)
En tout cas update-grub ne sert à rien dans cette situation, il n’a aucun effet sur les variables de boot EFI.

#7

Bonjour @PascalHambourg,

Merci pour ce retour.

Quand j’ai indiqué « impact sur GRUB » je voulais effectivement faire référence au menu GRUB régénéré par la mise à jour du noyau. Il me manquait les logs (« enfermés » dans ma Debian pour le moment non amorcable :-)) pour expliciter cette expression mal choisie.

Les références que j’ai faites à tes postes et le bout de code que j’ai proposé (avec des réserves) visaient à lancer le débat sur la problématique à laquelle j’ai affaire.

Sur la solution proposée avec efibootmgr, j’ai quand même une question avant de la tester : sous réserve bien sûr d’avoir bien identifié le n° de la partition EFI, il faut quand même que je saisisse la commande en étant root sur mon live-USB, non ?

#8

fdisk -l devrait y pourvoir.

Oui, mais au même titre que pour exécuter les commandes nécessaires au chroot.

1 J'aime
#9

Avec fdisk -l j’obtiens le resultat suivant :

user@debian:~$ sudo fdisk -l
The backup GPT table is corrupt, but the primary appears OK, so that will be used.
Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 870
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: ########-####-####-####-############ (je garde ça pour moi :slight_smile: )

Device Start End Sectors Size Type
/dev/sda1 2048 1363975 1361928 665M Windows recovery environment
/dev/sda2 1363976 1773583 409608 200M EFI System
/dev/sda3 1773584 2035735 262152 128M Microsoft reserved
/dev/sda4 2035736 1258682543 1256646808 599.2G Microsoft basic data
/dev/sda5 1258682544 3292629063 2033946520 969.9G Microsoft basic data
/dev/sda6 3292631040 3341457407 48826368 23.3G Linux filesystem
/dev/sda7 3341457408 3360989183 19531776 9.3G Linux filesystem
/dev/sda8 3360989184 3362990079 2000896 977M Linux swap
/dev/sda9 3362990080 3366895615 3905536 1.9G Linux filesystem
/dev/sda10 3366895616 3907028991 540133376 257.6G Linux filesystem

Disk /dev/sdb: 7.62 GiB, 8178892800 bytes, 15974400 sectors
Disk model: Flash Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: ##########

Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 64 6821759 6821696 3.3G 0 Empty
/dev/sdb2 6908 17083 10176 5M ef EFI (FAT-12/16/32)

Disk /dev/loop0: 2.76 GiB, 2958356480 bytes, 5778040 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

Si j’interprète correctement le résultat, la partition EFI serait donc /dev/sda2, non ?
Sachant que les partitions /dev/sda6, /dev/sda7, /dev/sda9, /dev/sda10 correspondent a /, /var, /tmp, /home (j’ai séparé les partitions a l’installation de Debian).

#10

Oui → --disk /dev/sda --part 2

1 J'aime
#11

Bilan du test de la commande efibootmgr -c -d... :

  1. Résultat de la commande : il y a bien une entrée debian créée
    IMG_20231218_235932

  2. La liste des entrées se maintient lors d’un efibootmgr ; l’entrée debian (0001) a été placée automatiquement en 1ère dans l’ordre de boot
    IMG_20231219_000119

  3. 1er redémarrage : j’ai retiré ma clé USB de live avant le rallumage, je m’attends à voir debian de nouveau dans les options de boot dans le BIOS… mais plus d’options de boot hormis le lecteur de CD/DVD !
    IMG_20231219_000256

  4. Je sors du BIOS sans enregistrer et l’ordinateur redémarre en demandant « d’introduire un périphérique d’amorçage et d’appuyer une touche » (en gros)

  5. Je reviens à l’étape 3 en appuyant F2 à répétition pour accéder au BIOS et afficher les options de boot : et là, l’option de boot Windows est revenue, mais rien pour debian ; j’enregistre en quittant le BIOS et l’ordinateur démarre alors sur Windows
    IMG_20231219_000412

  6. Après arrêt de Windows et rallumage : idem au 5. dans le BIOS
    IMG_20231219_000850

Alors, comment rétablir l’option de boot de Debian ?
Je vois qu’il y a des menus dans le BIOS pour créer des options de boot, mais j’ignore comment les utiliser :
IMG_20231216_221057
IMG_20231216_212924
IMG_20231216_212950

#12

Pour créer une entrée de boot via l’interface du firmware UEFI, il faut normalement sélectionner la partition EFI (Part2) comme filesystem, puis le fichier \EFI\debian\shimx64.efi comme path.
Si l’interface n’affiche pas l’arborescence de la partition vérifie depuis un système live ou l’installateur que la partition EFI contient encore le répertoire /EFI/debian et ses fichiers (shimx64.efi, grubx64.efi…).

#13

1er test realise sur une session live-USB :

user@debian:~$ sudo mkdir /media/efi
user@debian:~$ sudo mount -v /dev/sda2 /media/efi
mount: /dev/sda2 mounted on /media/efi.

user@debian:~$ cd /media/efi/EFI
user@debian:/media/efi/EFI$ ls -l
total 8
drwxr-xr-x 2 root root 2048 Jul 10 2012 ASUS
drwxr-xr-x 2 root root 2048 Jul 10 2012 Boot
drwxr-xr-x 2 root root 2048 Sep 3 11:15 debian
drwxr-xr-x 4 root root 2048 Jul 10 2012 Microsoft

user@debian:/media/efi/EFI/debian$ ls -l
total 5950
-rwxr-xr-x 1 root root 108 Oct 10 22:32 BOOTX64.CSV
-rwxr-xr-x 1 root root 87328 Oct 10 22:32 fbx64.efi
-rwxr-xr-x 1 root root 126 Oct 10 22:32 grub.cfg
-rwxr-xr-x 1 root root 4199872 Oct 10 22:32 grubx64.efi
-rwxr-xr-x 1 root root 849616 Oct 10 22:32 mmx64.efi
-rwxr-xr-x 1 root root 948768 Oct 10 22:32 shimx64.efi

Les fichiers shimx64.efi, grubx64.efi sont bien presents.

Puisque j’y suis, je jette un oeil au contenu de certains fichiers :

user@debian:/media/efi/EFI/debian$ cat BOOTX64.CSV
shimx64.efi,debian,,This is the boot entry for debian

user@debian:/media/efi/EFI/debian$ cat grub.cfg
search.fs_uuid 19d4b5a3-eea3-4249-8b83-d457b5f51ced root hd0,gpt6
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

A present je vais tester un ajout d’option au BIOS. Quetion au passage : ne faut-il pas indiquer pour le ‹ path › un chemin de la forme fs0:\EFI\debian\shimx64.efi ?

#14

Non, seulement \EFI\... La partition est spécifiée séparément par HD(...).
Je voudrais vérifier si les UUID qu’on voit sur la copie d’écran correspondent bien aux PARTUUID des partitions, c’est curieux que les deux premiers soient si proches. Peux-tu poster la sortie de

blkid /dev/sda*
1 J'aime
#15

Voila le resultat :

user@debian:/home$ sudo blkid /dev/sda*
/dev/sda: PTUUID="44825676-3ea3-11ee-b62a-685d436693f5" PTTYPE="gpt"

/dev/sda1: BLOCK_SIZE="512" UUID="01D6EC5877AB71D0" TYPE="ntfs" PARTUUID="44825677-3ea3-11ee-b62a-685d436693f5"

/dev/sda10: UUID="8f052ba4-fe21-4fab-ae89-7fce4b68dad9" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="46dbca0b-bf3c-4dd8-a3d3-e2fef3fb2a0c"

/dev/sda2: LABEL_FATBOOT="SYSTEM" LABEL="SYSTEM" UUID="5AAA-E9A1" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="44825678-3ea3-11ee-b62a-685d436693f5"

/dev/sda3: PARTLABEL="Microsoft reserved partition" PARTUUID="44825679-3ea3-11ee-b62a-685d436693f5"

/dev/sda4: LABEL="OS" BLOCK_SIZE="512" UUID="54AA984AAA982A8E" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="4482567a-3ea3-11ee-b62a-685d436693f5"

/dev/sda5: LABEL="DATA" BLOCK_SIZE="512" UUID="01D6EC5843DB21C0" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="35386235-3661-6666-2d33-6561632d3131"

/dev/sda6: UUID="19d4b5a3-eea3-4249-8b83-d457b5f51ced" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b0f271d9-d475-48db-af0f-33b9f6e7e959"

/dev/sda7: UUID="ccd1ee76-be3c-4473-ac1e-c45c1afb396a" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="58821c89-3fa6-4f06-90c6-725782da5a4c"

/dev/sda8: UUID="bd72915a-e1ef-4889-85c3-40c9520a9d9b" TYPE="swap" PARTUUID="c2756e96-8e67-4b21-85b3-8ed431f863c0"

/dev/sda9: UUID="4a0b6e55-9290-4660-a1d0-a39c2fd82f8b" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="a40d9955-994f-42cb-95b0-8f26245e6d38"

#16

Pour /dev/sda2, le PARTUUID correspond visiblement avec le filesystem en 2e ligne de l’avant derniere capture d’ecran du post du 19/12/2023 00:36.

Mais pas avec le resultat de :

#17

Oui. Mais je ne vois pas pourquoi l’écran ne propose que les partitions 1, 2 et 5. Les partitions 1 et 5 sont de type NTFS, or la partition 4 aussi mais elle n’est pas proposée. Tant pis, de toute façon c’est la 2 qui nous intéresse.

C’est l’UUID de sda6, qui est la partition racine je suppose. Mais ce fichier n’est lu que si GRUB est lancé par le firmware UEFI

#18

Un instant j’ai une capture de ce soir…

#19

Voila ce qu’il en est aujourd’hui :
IMG_20231220_215505

#20

Oui /dev/sda6 est bien la racine de ma Debian.