#1 Le 16/09/2016, à 10:32
- Bougron
[INFO] Mise à jour Windows 10 : provoque un grub rescue [FYI]
[INFO] Mise à jour Windows 10 : provoque un grub rescue [FYI]
Bonjour.
Je suis actuellement en dual-boot. avec ubuntu 16.04.1.
La façon de démarrer ubuntu par le grub est toujours aussi pitoyable.
Il lui faut ceinture et bretelle. Donc la nouvelle mise à jour de windows 1607 du 16 septembre 15h29' (N°14926) l'a pendu.
"j'ai une erreur lors de l'allumage de ma machine avec un écran noir et l'erreur "grub 2.02 minimal bash like" avec une invite de commande".
Le plus comique est que je regardais les multiples redémarrages de windows, afin de positionner le grub pour lancer windows au lieu de ubuntu.
Je ne sais plus à combien de redémarrages j'en étais lorsque cela s'est produit.....
Le virus introduit par windows est très efficace. Mais d'une portée limitée. Voici le conditions nécessaires
A) disposer d'un grub qui exige pour booter de disposer de l'UUID de la partition contenant ubuntu ainsi que de la position relative de cette partition dans le disque dur.
Je pense que cela fait beaucoup de monde potentiellement impacté.
On trouve cela.
1) Pour un bios LEGACY : Dans le MBR du disque dur => (,msdos5)/boot/grub
============================= Boot Info Summary: ===============================
=> Grub2 (v2.00) 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
for (,msdos5)/boot/grub. It also embeds following components: 2) Pour un bios EFI: Dans le fichier de paramétrage /boot/efi/EFI/ubuntu/grub.cfg
Je rappelle que ce fichier de paramétrage n'est actuellement pas encore visible dans boot-info.
search.fs_uuid 0cdf2ac8-7678-4156-be85-dfe4539be124 root hd0,gpt7
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg
Ainsi qu'en de multiples endroits dans le fichier /boot/grub/grub.cfg par exemple ici.
menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-0cdf2ac8-7678-4156-be85-dfe4539be124' {
recordfail
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt7'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt7 --hint-efi=hd0,gpt7 --hint-baremetal=ahci0,gpt7 0cdf2ac8-7678-4156-be85-dfe4539be124
else
search --no-floppy --fs-uuid --set=root 0cdf2ac8-7678-4156-be85-dfe4539be124
fi
linux /boot/vmlinuz-4.4.0-36-generic.efi.signed root=UUID=0cdf2ac8-7678-4156-be85-dfe4539be124 ro quiet splash $vt_handoff
initrd /boot/initrd.img-4.4.0-36-generic
}
Vous l'avez deviné: Le virus est simple. Renuméroter les partitions afin qu'elle soient dans l'ordre.
Bien sur, la renumérotation peut être identique. Mais, windows fabrique des nouvelles partitions si elles manquent. Dans ce cas, les partitions peuvent se trouver installées avant la partition SLASH.
Aucune idée de ce qui pourrait se passer s'il n'y avait pas eu de place pour créer de telles partitions.
Un exemple de renumérotation avec création des partitions 6 et 9 (1 windows étant installé sur la partition SDA5 et un autre sur la partition 10)
u16041@u16041:~$ sudo fdisk -l|grep sda
Disque /dev/sda : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
/dev/sda1 2048 262143 260096 127M EFI System
/dev/sda2 262144 294911 32768 16M Microsoft reserved
/dev/sda3 294912 555007 260096 127M Microsoft basic data
/dev/sda4 555008 13137919 12582912 6G Partition d'échange Linux
/dev/sda5 68192256 145994484 77802229 37,1G Microsoft basic data
/dev/sda6 145995776 146935807 940032 459M Windows recovery environment
/dev/sda7 336625664 407144447 70518784 33,6G Linux filesystem
/dev/sda8 407144448 535596815 128452368 61,3G Microsoft basic data
/dev/sda9 535597056 536528895 931840 455M Windows recovery environment
/dev/sda10 912986112 1354586111 441600000 210,6G Microsoft basic data
/dev/sda11 1354586112 1421695486 67109375 32G Linux filesystem
/dev/sda12 1421697024 1430085631 8388608 4G Linux filesystem
/dev/sda13 1430085632 1526554623 96468992 46G Linux filesystem
/dev/sda14 1526554624 1819305983 292751360 139,6G Linux filesystem
/dev/sda15 1819305984 1839785983 20480000 9,8G Microsoft basic data
/dev/sda16 1839785984 1860265983 20480000 9,8G Microsoft basic data
/dev/sda17 1860265984 1953523711 93257728 44,5G Linux filesystem
u16041@u16041:~$Dernière modification par Bougron (Le 16/09/2016, à 10:49)
Hors ligne
#2 Le 16/09/2016, à 11:16
- Nasman
Re : [INFO] Mise à jour Windows 10 : provoque un grub rescue [FYI]
Je me suis aperçu de l'importance de ce fichier quand j'ai fait le test d'avoir un ubuntu bootant à la fois en mode efi et en mode bios.
J'ai commencé par une installation efi puis j'ai refait une installation en mode bios. Comme l'uuid de la partition système avait changé (la réinstallation a modifié la valeur de l'uuid), le mode uefi ne marchait plus.
En corrigeant (depuis le lancement en mode bios) la valeur dans /EFI/ubuntu/grub-cfg le problème a été résolu. Dans la même ligne on a ausi le numéro de la partition système linux (à moins que ce ne soit celle de /boot/grub (si partition dédiée)
PC fixe sous Bionic 64 bits et portable avec Focal 64 bits
Hors ligne