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)
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 ?
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.
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 ?
fdisk -l devrait y pourvoir.
Oui, mais au même titre que pour exécuter les commandes nécessaires au chroot.
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)
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).
Oui → --disk /dev/sda --part 2
Bilan du test de la commande efibootmgr -c -d... :
Résultat de la commande : il y a bien une entrée debian créée
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
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 !
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)
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
Après arrêt de Windows et rallumage : idem au 5. dans le BIOS
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 :
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…).
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 ?
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*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"
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 :
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
Un instant j’ai une capture de ce soir…
Voila ce qu’il en est aujourd’hui :
Oui /dev/sda6 est bien la racine de ma Debian.
Ca te semble jouable de creer l’option de boot via le BIOS ?
Oui, c’est à tenter. Filesystem Part2 et path \EFI\debian\shimx64.efi. A mettre en premier dans l’ordre de boot.
Succès de l’opération par le menu de boot !
Merci @PascalHambourg pour tes éclairages productifs.
Pour mémo aux autres utilisateurs qui auraient le même problème : choisir le filesystem dont le code correspond au PARTUUID de la partition disque EFI :