Lost knowledge: just do not install GRUB2 into Master Boot Record (MBR), though this is the default

It is a couple of years ago - pre-UEFI times - when there repeatedly were users on this forum asking for help because their windows updates or service packs wouldn’t work after they had created a dual boot of windows and openSUSE on their (legacy) systems.

The reason was quite simple, though hidden to users with little experience: the default for the bootloader during a fresh installation of openSUSE for a longer time had been to install the bootloader in the MBR, or to “Boot from Master Boot Record”. This as well did lead to problems with the co-existence with other linux distributions in a multi boot.

One among other reminders of those problems is
https://forums.opensuse.org/showthread.php/454535-openSUSE-Dual-Booting-with-Windows-7-AND-Loading-Service-Pack-1-for-Windows-7
which for legacy systems using an MBR is still valid.

Another reminder is
https://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_up_a_working_GRUB.3F
which was cited just recently

I was astonished to remark that this default of “Boot from Master Boot Record”, which in the past gave rise to so many problems on legacy multi boot systems, had returned.
I discovered that when I made a fresh install of Leap 15.0 some time ago.

Now for fresh installations of Leap 15.1 this default of “Boot from Master Boot Record” still was the same, and I therefore had to change that actively.

The solution was and is simple: in the checkboxes of YaST > Bootloader > Boot Code Options

  • uncheck “Boot from Master Boot Record”
  • check “Boot from (Root) Partition”
  • check “Set active Flag in Partition Table for Boot Partition”
  • check “Write generic Boot Code to MBR”

Then fdisk, parted, or other tools like gparted can be used to move the boot flag to the right windows partition to make windows updates work, and moved back again afterwards, without overwriting the MBR using a windows installation CD - which in turn would disable booting openSUSE.

Why making certain windows updates impossible, and in consequence force a number of less experienced users to destroy their linux bootloader setup, just by making this option of “Boot from Master Boot Record” the default of the openSUSE installer?

My guess is some combination of the following:

  1. Monkey see, monkey do. All distros (that I’m aware of) put bootloader on MBR by default.
  2. It’s what Windows does (so the “favor” of usurping boot control in favor of the last installed OS is returned).
  3. MBR Grub installation usually works well enough (until
    Windows needs unpredictable updates, or reinstallation).
  4. In an ideal world, once Linux is installed, the need for Windows would ultimately be reduced to zero.
  5. It’s subjectable to QA.
  6. Once Windows recaptures the boot flag, it’s not obvious what de minimus correction is required, or how to go about it.
  7. Grub on partition doesn’t always fit the available space.
    *] There is no single right way to configure multiboot.

I disagree with a lot of this.

Actually, my experience is that, for a long time, openSUSE would install so as to boot from “/boot” if that separate “/boot” partition existed. Yes, they recently changed the defaults, and I’ll comment on that in a followup reply.

I could be mistaken. But it has been my impression that booting from the MBR avoids these problems with windows updates.

Then fdisk, parted, or other tools like gparted can be used to move the boot flag to the right windows partition to make windows updates work, and moved back again afterwards, without overwriting the MBR using a windows installation CD - which in turn would disable booting openSUSE.

But this is a problem. If you have to change the boot flag for Windows updates, then change it back afterwards, then you don’t have booting working well. As far as I know, booting from the MBR solves this problem. And it solves it, because you can leave windows marked with the boot flag (to keep windows happy), but still get a grub boot menu when you boot.

A followup, as promised.

With “btrfs” it is better to not have a separate “/boot”. And that is part of why defaults have changed.

Another followup.

Here’s what I am doing on older (on-UEFI) systems:

(1) I still use a separate “/boot”
(2) I install to boot from “/boot” (not from the MBR).
(3) I create my own generic boot code, based on the syslinux boot code. These days, “syslinux” is normally installed at “/usr/share/syslinux”. I use the file “altmbr.bin” for generic boot code. But you have modify that first. Typically, I have “/boot” as “/dev/sda1”. So I append one byte containing binary 1 to “altmbr.bin”. Then I install that as generic boot code.

The effect is that this will always boot partition 1, and ignore the boot flag (active partition flag). So I set the boot flag to the windows partition. That way, Windows thinks it is the partition that is booted. But the linux/grub partition is actually booted. And I don’t need to keep moving that boot flag. It works quite well.

And another followup. This one is about UEFI systems.

My experience with a UEFI system and Windows 8.1, is that some Windows updates still fail.

My workaround – before updating, I change the UEFI boot order to make Windows the first in boot order. Then I update. I have not run into problems with this. All updates have worked.

Afterwards, I change the boot order back so that opensuse-secureboot is first.

However: I am considering making the change in boot order permanent. That is, alway have Windows first. If I want to boot to openSUSE, then I can hit F12 during boot to select the openSUSE boot.

After using Windows, I typically do a SHIFT-restart. Then, on the next prompt, I say to boot from a device. This offers the opensuse boot, which I select. This seems to have the nice side effect that windows file systems are cleanly shutdown.

Hi
Since the Intel M/B I have doesn’t support booting from a NVMe device, I had to separate /boot (format to btrfs) out onto the SSD as well as /boot/efi to get things working…

Yes, one has to adapt to special situations.

But, why would “Write generic Boot Code to MBR”, available as a choice for the openSUSE boot loader, would work then for windows being able to do certain updates / service packs?
It is the boot flag, and not writing some GRUB code to MBR.

It was you who advocated this.

I was not talking about a separate /boot partition. I never had that. I just made fresh installs of openSUSE over the years starting from 10.2.

First,
It should be noted that very few hyvisor-based virtualization supports UEFI booting well.
Also Win10 MFT Win10 and IIRC Win8.1 install naturally implementing UEFI and secure boot by default, but support switching to MBR only after installing UEFI.

At least, the above has been my personal experience, there may be ways to get around the above natural behavior I’m not aware of.

TSU

[QUOTE=nrickert;2914963]

But it has been my impression that booting from the MBR avoids these problems with windows updates.

Some Windows updates replace MBR boot code making Linux unbootable.

If you have to change the boot flag for Windows updates, then change it back afterwards, then you don’t have booting working well.

If you have to open umbrella and then close it your weather is not working well.

Yes, sometimes you are forced to do something you are not happy with. It does not mean “something is not working well”. It just means “something works as it works - you need to understand how it works and be prepared to deal with it”.

And it solves it, because you can leave windows marked with the boot flag (to keep windows happy), but still get a grub boot menu when you boot.

There are two problems - MBR code and active partition. You cannot solve both of them at the same time. But it is much more simple to change active partition than restore MBR code once Windows overwrote it.

The reason why my comment that the OP quoted. :slight_smile:

BTW, with UEFI what I do differs rather little from that nrickert does with UEFI. With MBR, I’m still using a separate boot partition, but without ever mounting it to /boot/, and still only with Grub Legacy. I build menu.lst myself, using symlinks to kernels and initrds.

[quote="“arvidjaar,post:12,topic:137992”]

This is why I prefer to not install grub to the MBR.

Using syslinux altmbr.bin, I keep a copy of the MBR boot code in a place that I can easily find. So it is then

  • boot from rescue media
  • find my saved copy of the mbr code
  • install that mbr code

I have not needed to do that in the last few years.

Another thread reflecting my perception of things about MBR and boot flags is in
https://forums.opensuse.org/showthread.php/464607-reinstall-grub-boot-loader?p=2378822#post2378822

Just this was my experience: unselect “Boot from Master Boot Record” in the openSUSE installer (as long as this had been the default in former times), and your system with a dual boot with windoze will continue to work.

I can confirm that this stayed like that with windoze 7 - but I didn’t have windoze XP.
No problem at all then installing openSUSE that way.

Maybe, that with windoze 8 and the upgrade to 8.1 things changed.

But who would have liked to have windoze 8 or 8.1 ?

Today the situation is different, after the offer of Microsoft to upgrade windoze 7 to windoze 10.

OK, not all of that windoze users may want to have openSUSE.

But because of that “free” upgrade to windoze 10, there will be many legacy systems around with a partition table of the type ‘msdos’, but despite of that having a windoze 10 installed.

So better prepare for that, whatever that would mean.

I would say, NOT to “Boot from Master Boot Record” would just be defensive.

Hi

I was interested in how this all would work - I don’t mean copying the MBR using dd which would be quickly done - but the other stuff with the /boot partition that I never had, and the boot flag then, because I was always installing openSUSE with / and /home only, as suggested anyway by the openSUSE installer constantly over the years as default.
And I further was inspired by the thread
[https://forums.opensuse.org/showthread.php/537619-CentOS-7-not-visible-in-grub-menu-made-by-Leap-15-1](CentOS 7 not visible in grub menu made by Leap 15.1)
which appeared shortly after this thread here had been opened.

I decided to do some testing.

(1)
On a new USB stick I created the following partitions during the installation of Leap 15.0 on it using the partitioner of the 15.0 installer (the following output of “parted -l” was obtained AFTER the installation on the USB running an openSUSE installed on an internal disk):

Model: SanDisk Ultra USB 3.0 (scsi)
Disk /dev/sdc: 61.5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type      File system  Flags
 1      1049kB  525MB   524MB   primary   xfs          type=83
 2      525MB   13.4GB  12.9GB  primary   ext4         type=83
 3      13.4GB  26.3GB  12.9GB  primary   ext4         type=83
 4      26.3GB  61.5GB  35.2GB  extended               lba, type=0f
 5      26.3GB  43.5GB  17.2GB  logical   ext4         type=83
 6      43.5GB  61.5GB  18.1GB  logical   ext4         type=83

In this, during that installation of 15.0 on the USB, partition 1 formatted xfs was assigned the mount point /boot, partition 2 the mount point /, and partition 5 the mount point /home.

Partitions 3 and 6 have been created for a further installation of a Linux, with the aim to finally obtain a dual boot.

(2)
In the bootloader section of the 15.0 installer, I made the following setup

] Boot From Master Boot Record (here an MBR could be added to make things a bit clearer)
] Custom Boot Partition
Set active Flag in Partition Table for Boot Partition
Write generic Boot Code to MBR

I did NOT get a checkbox for “Boot from Partition”, which I usually did find here when installing in partitions / and /home only (i.e. when installing without a separate /boot partition).

In the installation summary I then did get a warning:
“Warning: No location for bootloader stage1 selected.Unless you know what you are doing please select above location”

https://paste.opensuse.org/images/6816391.png

(3)
Installation otherwise went smoothly.
But afterwards it was not possible to boot the installed 15.0 from that USB.
When I tried, I got a black screen with a blinking text cursor in the upper left corner of the screen.

As a first very basic check, GParted (running from internal disk) then revealed that the bootloader, the kernel, and the software had very likely been installed successfully, see the amount of space used in the different partitions
https://paste.opensuse.org/images/40201198.png

But most astonishing for me from this output of gparted was, that despite that during the installation I had selected to set the boot flag in the boot section of the installer - c.f. point (2) above - NO boot flag was set at all, as was as well revealed by the above output from “parted -l” after the installation, given above under point (1).

Mounting partition 1 ( /boot ) and partition 2 ( / ) things looked well there.
As well the contents of the 4 files
/etc/default/grub
/boot/grub2/device.map (obviously created by the installer)
/boot/grub2/grub.cfg
/etc/sysconfig/bootloader
mentioned in section 17.5.2.4 of
[https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.startup/cha.trouble.html](Common Problems and Their Solutions | openSUSE Leap 15.1)
which were present on the USB looked good.

(4)
Using GParted I set the boot flag to the /boot partition 1 on the USB.

Model: SanDisk Ultra USB 3.0 (scsi)
Disk /dev/sdc: 61.5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type      File system  Flags
 1      1049kB  525MB   524MB   primary   xfs          boot, type=83
 2      525MB   13.4GB  12.9GB  primary   ext4         type=83
 3      13.4GB  26.3GB  12.9GB  primary   ext4         type=83
 4      26.3GB  61.5GB  35.2GB  extended               lba, type=0f
 5      26.3GB  43.5GB  17.2GB  logical   ext4         type=83
 6      43.5GB  61.5GB  18.1GB  logical   ext4         type=83

On an internal hard disk I have a similar setup with windoze 7 - if I want to boot that directly for certain updates then I have to put the boot flag on a small 100MB NTFS partition labeled “MSsystem” that was created by the installer of that windoze 7.

Reboot from USB, again using the boot menu of the BIOS.
15.0 doesn’t boot.

(5)
Using GParted I even tried the following, although I was not convinced that it would succeed: I did set the boot flag to the /root partition 2 of 15.0 on the USB.
Reboot from USB.
15.0 doesn’t boot.
Moved boot flag back to partition 1 ( /boot ).

(6)
Booting from the 15.0 installer, in the upcoming menu I chose: More … > Boot Linux System .
Initially that worked fine.
Under “Select a system to boot” I found and selected sdc2 (label 150root, see GParted window above).
Under “Select a kernel to boot” I found and selected sdc1 (label 150boot).
Under “You may select an alternative device name for the system partition” I selected the /dev/disk/by-uuid/e904… version.
Under “Edit kernel options” the root=/dev/disk/by-uuid/e904… looked well.

Result: “Sorry, system didn’t boot.”

(7)
Booting the rescue system from the 15.0 installer and following the instructions in section 17.5.2.3 of
[https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.startup/cha.trouble.html](Common Problems and Their Solutions | openSUSE Leap 15.1)
I successfully chroot’ed to the installed 15.0

https://paste.opensuse.org/images/72810333.png

Here I entered

rescue:/ # yast

and got to the text version of YaST.

In the bootloader section I checked
Custom Boot Partition
and entered the path to the boot partition: /dev/disk/by-label/150boot

https://paste.opensuse.org/images/45652099.png

On exiting the bootloader section I got the messages

Saving Boot Loader Configuration
 Prepare system
 Create initrd
 Save boot loader configuration

After exiting yast, I left the chroot environment with “umount -a” and “exit” and then shut down with “shutdown -h now”.
Power on again and in the BIOS boot menu selecting the USB.

Result: No boot.

Repeating the procedure, i.e. chrooting into sdc2 again and calling “yast”, in the bootloader section I discovered, that
] Custom Boot Partition
was NOT checked anymore, and that the path /dev/disk/by-label/150boot to the boot partition - which I had entered before - had NOT been stored.

Well, it however was possible to boot that 15.0 from the USB, showing as well that the installation as such had been successful, see next posting.

OK, after all these trials, I did something that I usually abstain from.

As the very last possibility I chrooted into the 15.0 on the USB again, then again “yast”, and bootloader.
This time I checked
[X] Boot from Master Boot Record

https://paste.opensuse.org/images/29590469.png

Save and exit.
Shutdown.
Power on again.
Guess what:

Boot !

After checking out all of this it is not quite clear to me, how at least for openSUSE Leap 15.0 booting from a separate /boot partition could be combined in any way with NOT booting from MBR, i.e. wihout writing non-generic boot code to MBR.

Next test.

Install an additional openSUSE Leap 15.1 on the USB stick where Leap 15.0 had been installed before with a separate /boot partition with xfs file system.
This Leap 15.0 could be booted only after “Boot from Master Boot Record” had been selected in the bootloader settings.

The partition setup on the USB was that shown in the output from “parted -l” in
https://forums.opensuse.org/showthread.php/537614-Lost-knowledge-just-do-not-install-GRUB2-into-Master-Boot-Record-(MBR)-though-this-is-the-default?p=2915231#post2915231

In that partition setup the empty (i.e. only formatted) partition sdc3 was to be used for / (or root), and the empty logical volume sdc6 for /home (compare as well the output of GParted AFTER the installation that is shown further down below).
No separate /boot partition seclected for 15.1, i.e. sdc1 was NOT used for this installation.

For the bootloader of 15.1 use the default settings.

The bootloader section during the installation thus looked like

https://paste.opensuse.org/images/45101941.png

and the result in the installation summary from this was

https://paste.opensuse.org/images/41935162.png

Disk usage after the installation of 15.1 can be seen from the following

https://paste.opensuse.org/images/71721321.png

and in this there is a funny detail: the installer of 15.1 did put the boot flag on the extended partition sdc4 in which no root partition is present.
From the labels of the partitions in that output of GParted it can easily be seen which the single partitions are serving for.

OK, now, booting from the USB, the following GRUB2 menu shows up

https://paste.opensuse.org/images/97035343.png

But in this: where are the entries for the openSUSE Leap 15.0 which was installed beforehand, which is still present, and which booted from the same USB stick until 15.1 was installed on it ?

Oooops, sorry, a GLITCH:

Because the list in the GRUB2 menu at boot was too long, due to the entries from the internal drives, I didn’t see the boot entry for the 15.0 on the USB stick and didn’t scroll down with the arrow-down-key (there is no scroll bar in that GRUB2 menu).
In the boot loader settings of 15.1 I then removed the internal disks sda and sdb, however, the list remained just as long.
I must finally have unchecked the checkbox for “Probe Foreign OS” in the “Bootloader Options” … I was a bit tired after several hours of installing, chrooting, reading, and trying out.

I just changed that back a few minutes ago, after thinking about all again.
The long, long list in the GRUB2 menu is back again, and at the very bottom of that long list, after scrolling down, I find the entry for the 15.0 on the USB stick.

And 15.0 boots from there.

Sorry for any inconvenience.

I think I’ll stop posting for a while …

When you configure grub to boot from the MBR, it also stores some code/data in the gap between the MBR and the first partition. Well, that assume legacy partitioning. It doesn’t do that with GPT partitioning, but instead stores that in the “bios_boot” partition (sometimes called “bios_grub” partition).

So copying the MBR with “dd” may miss some of what has to be copied.

but the other stuff with the /boot partition that I never had, and the boot flag then, because I was always installing openSUSE with / and /home only, as suggested anyway by the openSUSE installer constantly over the years as default.

You don’t really need a separate “/boot” these days, except perhaps with very old computers. Keeping “/boot” part of the root partition should be okay. I still use a separate “/boot” because I use an encrypted LVM, and I keep “/boot” unencrypted. That’s not strictly needed either, but it does simplify some things.

I decided to do some testing.

You appear to be using “xfs” for “/boot”. I’m not sure if that works. There seem to be some restrictions on using “xfs” for booting.

When I use a separate “/boot”, I normally use “ext2” for that, on the principle that grub really doesn’t look at the file system journal (with “ext4”).