Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#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