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.
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?
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.
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…
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.
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.
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.
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.
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.
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”
(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.
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
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.
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.
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
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
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 ?
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.
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”).
