Je suppose que tu voulais dire root=/dev/sdb1
?
Ce n’est pas normal. La racine devrait être spécifiée par son UUID, qui est un identifiant persistant au contraire du nom de périphérique d’une partition comme /dev/sdb1 qui peut devenir /dev/sda1 ou vice versa.
Depuis longtemps, en tout cas depuis l’introduction des pilotes ATA basés sur libata, udev, blkid et de l’initrd/initramfs, je n’ai jamais vu une installation de Debian utiliser par défaut un nom de partition comme racine. GRUB a bien une option GRUB_DISABLE_LINUX_UUID dans /etc/default/grub pour ne pas spécifier la racine par UUID, mais elle est désactivée par défaut.
La seule raison de ne pas utiliser les UUID avec un système Debian, c’est de ne pas utiliser d’initramfs, mais les noyaux fournis par Debian ne peuvent pas fonctionner sans initramfs, donc cela implique de ne pas utiliser un noyau fournir par Debian, ce qui ne peut pas arriver avec une installation normale. Et même dans ce cas, depuis Jessie la partition racine peut être spécifiée par son “UUID de partition” (PARTUUID), que le noyau sait lire contrairement à l’UUID classique qui est un UUID de système de fichiers.
Par curiosité, sous quelle forme est spécifiée la racine dans /etc/fstab ?
Et dans /boot/grub/grub.cfg ou le menu de GRUB, après update-grub
, la racine est-elle spécifiée par son UUID ou /dev/sda1 ?
Le nom de l’image du noyau est-il vraiment vmlinuz-4.9.0.0-amd64 ou vmlinuz-4.9.0-3-amd64 ? Le second est le nom de l’image du noyau officiel de Debian 9. Si c’est bien le premier, d’où vient-il et y a-t-il un initramfs (/boot/initrd.img* et ligne initrd
à la suite de linux
dans /boot/grub/grub.cfg et le code de l’entrée de menu de démarrage) ?
Inutile. Réinstaller le chargeur ne se justifie que si le menu de démarrage ne s’affiche pas, ou bien si ce n’est pas le bon GRUB qui se lance. Le contenu de grub.cfg qui détermine le menu ne dépend que de update-grub
.
Elle peut être identique. Simplement le périphérique d’amorçage spécifié, sans objet en UEFI, sera ignoré et peut être omis.