GRUB problem after updating to Leap 42.3 (dual boot system)

Dear all,

I am opening this forum thread, to address a grub boot issue I got, when updating from Leap 42.2 to 42.3 via zypper dup. The update was done by the standard method of renaming the repositories

# | Alias                     | Name                      | Enabled | GPG Check | Refresh
--+---------------------------+---------------------------+---------+-----------+--------
1 | adobe                     | adobe                     | Yes     | ( p) Yes  | Yes    
2 | download.opensuse.org-oss | Main Repository (OSS)     | Yes     | (r ) Yes  | Yes    
3 | packman                   | packman                   | Yes     | (r ) Yes  | Yes    
4 | repo-update               | openSUSE-Leap-42.3-Update | Yes     | (r ) Yes  | Yes


I had a dual boot system between Leap 42.2 and windows 7. I decided to update and unfortunately, after completing the update I got grub_tpm_measure and a grub rescue> prompt. I tried to use live Leap 42.3 usb to mount the partitions and check what is going on. At the beginning I run the command

vgimport -a

OUTPUT
/run/lvm/lvmetad.socket: connect failed: No such file or directory
 WARNING: Failed to connect to lvmetad. Falling back to internal scanning


Subsequently I mounted my root partition and run chroot

mount /dev/sd5 /mnt
sudo mount -t proc none /mnt/proc
sudo mount --rbind /dev /mnt/dev
sudo mount --rbind /sys /mnt/sys

I checked and all of the following files exist.

/etc/default/grub
/boot/grub2/device.map 
/boot/grub2/grub.cfg 
/etc/sysconfig/bootloader

ls -ltr tells me that these files have been updated, except /etc/sysconfig/bootloader, which is 3 years old.

The user arvidjaar](https://forums.opensuse.org/member.php/69818-arvidjaar) suggested to run bootinfoscript. The RESULTS.txt file can be found here https://susepaste.org/5576780

efibootmgr -v gives the error EFI variables are not supported on this system. I guess i have legacy bios.

I also run

cat /etc/default/grub_installdevice
/dev/disk/by-id/wwn-0x5000c50052c57048-part3
activate

Based on this results, the following conclusion was drawn.

So your openSUSE is configured to put grub in partition 3 and that is where updated grub was written. At the same time you have grub in MBR of your drive and that is what is actually used during boot by BIOS. This grub instance was not updated, so now code in MBR does not match the rest if grub binaries under /boot/grub2.

You also have rather strange active partition 5 which is logical partition (so normally cannot be used as boot partition by BIOS) and does not contain any boot code so would not work even with Syslinux MBR that does support it.

At this point you need to decide whether you want to leave grub in MBR or you want leave it as configured in partition 3 and install generic code in MBR. If you ever need or want to boot Windows directly (not via grub) you need generic code that allows booting Windows by changing active partition.

I would be grateful for any suggestions how to fix this issue. What I would like to have is to be able, to choose between windows 7 and leap 42.3 from the grub menu as before. If it is possible to leave grub in the MBR, this is fine with me. In general, I would say that I am fine with any solution which would not wipe my data. If I would have to move grub from the MBR this is is also fine, as long as I won’t have to reinstall windows and linux. Basically, I am open to your suggestions and hope that the issue with GRUB is fixable. i am getting scared tight now.

Some reasoning for the strange configuration can be found in the forum link below. I was having problems with my dual boot and most probably, something went wrong there.

https://forums.opensuse.org/showthread.php/508264-Dual-boot-windows-8-and-opensuse-the-boot-loader-was-wrongly-set-to-grub2/page4?highlight=john_snow](https://forums.opensuse.org/showthread.php/508264-Dual-boot-windows-8-and-opensuse-the-boot-loader-was-wrongly-set-to-grub2/page4?highlight=john_snow)

Thank you for your help.

The first piece of CODE you show (apparently it should be your repos list) is useless. You do not show what command you used (please whenever possible, do the copy/paste including the promtp/command line at the begin and the new prompt line at the end, then everybody can see what you did, and that it is complete), but it should have been

zypper lr -d

Now we only see your local given names and aliases, but not what the URLs, and thus which repos they are.

Hello and thank you for you reply
I am sorry, I have done a mistake the proper output of the zypper repositories list is


>zypper lr -d
Repository priorities are without effect. All enabled repositories share the same priority.

# | Alias                     | Name                      | Enabled | GPG Check | Refresh | Priority | Type   | URI                                                           | Service
--+---------------------------+---------------------------+---------+-----------+---------+----------+--------+---------------------------------------------------------------+--------
1 | adobe                     | adobe                     | Yes     | ( p) Yes  | Yes     |   99     | rpm-md | http://linuxdownload.adobe.com/linux/x86_64/                  |        
2 | download.opensuse.org-oss | Main Repository (OSS)     | Yes     | (r ) Yes  | Yes     |   99     | yast2  | http://download.opensuse.org/distribution/leap/42.3/repo/oss/ |        
3 | packman                   | packman                   | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | ftp://packman.inode.at/suse/openSUSE_Leap_42.3/               |        
4 | repo-update               | openSUSE-Leap-42.3-Update | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://download.opensuse.org/update/leap/42.3/oss/            |        

The above code was produced after mounting the devices and running chroot via the rescue system USB


vgimport -a
mount /dev/sda5 /mnt
mount -t proc none /mnt/proc
mount --rbind /dev /mnt/dev
mount --rbind /sys /mnt/sys
chroot /mnt /bin/bash
mount -a

For completeness I am sending a lsblk output in addition (i have two usb plugged in /dev/sdb /dev/sdc, one is mounted on /usb)./dev/sda2 is the windows drive.

>lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0    7:0    0    58M  1 loop 
loop1    7:1    0    12M  1 loop 
loop2    7:2    0  41.4M  1 loop 
loop3    7:3    0    44M  1 loop 
loop4    7:4    0   4.1M  1 loop 
sda      8:0    0 298.1G  0 disk 
├─sda1   8:1    0   100M  0 part 
├─sda2   8:2    0 117.2G  0 part 
├─sda3   8:3    0     1K  0 part 
├─sda5   8:5    0    45G  0 part /
├─sda6   8:6    0   130G  0 part /home
└─sda7   8:7    0   5.8G  0 part 
sdb      8:16   1  14.5G  0 disk 
├─sdb1   8:17   1   3.8M  0 part 
└─sdb2   8:18   1   4.3G  0 part 
sdc      8:32   1  57.9G  0 disk 
└─sdc1   8:33   1  57.9G  0 part /usb

Best regards

I’ll note here the earlier thread that has an analysis of the boot situation:

https://forums.opensuse.org/showthread.php/534665-Conflicts-when-updating-from-Leap-42-2-to-42-3

I suggest you do that again. Then, at the chroot command line:

yast

That should give you a command line version of yast.

The idea is to run yast bootloader. And have it reinstall your boot loader.

Make sure that you change something so that it reinstalls. Safest might be to set it “boot from MBR”.

When done, exit from chroot session and reboot. And this time it should boot properly into openSUSE.

Hello and thank you for your reply.

I managed to get the blue screen of yast as you suggested, repeating the entire mount chroot procedure. The boot loader is in
System>Boot Loader

Then I get a small list

Boot Loader Location
] Boot from Root Partition
] Boot from Master Boot Record
Boot from Extended Partition
] Custom Boot Partition.

If I understand you correctly, I should shift the to “Boot from Master Boot Recor**d”.
**Ii changed this using Alt and the highlighted letter

Alt+Shift+m 

and

Alt+Shift+f

to uncheck the old option. The list looks like this now

Boot Loader Location
] Boot from Root Partition
Boot from Master Boot Record
] Boot from Extended Partition
] Custom Boot Partition.

So far so good. Is this correct and what should I do next.

Below I have options that can be selected via Alt+ highlighted letter

Set active Flag in Partition Table for Boot Partition
] Write generic Boot Code to MBR
] Enable Trusted Boot Support
Edit Disk Boot Order]

And at the very bottom
Help] Cancel] OK]

I have never used the text version of yast or reinstalled the boot loader, therefore I am really insecure.

I just pressed [OK] and it was all fine. Thank you so much for taking the time to answer my question. :slight_smile:

In addition, I would be very grateful if you would explain to me what i just did.
I presume, that i reinstalled grub2 on the MBR, but what happened with the grub2 which was installed on /dev/sda3
In theory, if I would update again should I do the same procedure again?

I’m glad to hear that things are now working.

Yes, the command line (ncurses) version of Yast is a bit awkward to use. But it is great to have it there when things are broken enough that a command line is all that you have.

In addition, I would be very grateful if you would explain to me what i just did.

You reinstalled grub2 to boot from the MBR. Importantly, you used Yast to do that. And it’s important because that updates other information about how grub2 is installed. Not having that other information match is what caused your problems.

I presume, that i reinstalled grub2 on the MBR, but what happened with the grub2 which was installed on /dev/sda3

There is still some boot code in “/dev/sda3”. But it is just sitting and not being used. It is in a sector that isn’t used for anything else, so it does not harm.

In theory, if I would update again should I do the same procedure again?

At least, in theory, if you update again you should not run into this problem. By using Yast, you have stored information about booting that the update would use to get things right the next time.

Of course, that’s “in theory”. We all know that reality doesn’t always work out as we expect.

Current reality can be checked in /etc/default/grub_installdevice.

Note that random Windows updates require generic code on MBR, and that any Windows boot repair or (re-)installation of Windows will install generic code without asking permission. With Grub on a primary partition, generic code will load Grub just as well as it will load Windows’ bootloader. Switching which bootloader loads after POST is a quite simple matter of (re-)assigning the boot flag in the primary partition table, readily done no matter what happens to be currently booted.

In my case I have (see below). I find this interesting, since no partition number is given. Perhaps this is the way to reference the MBR


sudo cat /etc/default/grub_installdevice
/dev/sda
activate

Yes, that is referencing the MBR.