Triple booting - Leap 15, Win 7 and Win 10 Using Grub2 (Some Issues)

I would like to highlight an issue I have been having updating the
Windows OSes and how I work around it. I am using grub2 from Leap 15.0
to control the multi-booting on a legacy MBR partitioned disk. On sda1
is the system partition for windows, sda2 is win7-pro OS, sda3 is win
10-pro OS and sda4 is an extended partition where I have my Linux
partitions and 1 ntfs partition at the very end of it. Grub 2 is set to
boot from the boot partition but in fact it sets the extended partition
as active.

From time to time win7 OS would refuse to complete its monthly update
and win 10 has been doing same on a more regular basis (last 3 mths in a
row). I end up setting (from within windows OS) the windows system
partition (sda1) as active, reboot and all updates get installed without
any issues. I then boot into super grub disk 2 from a bootable usb
stick, pick my openSUSE OS and boot into it and reset my bootloader via
yast2 and all is OK after.

Unless someone knows an easier way to work around this issue, I think
that is my fate - mucking around and wasting time.

Cheers,
Peter

Yes, there’s a way around this.

I’ll just outline it here. You can ask for more detail where needed. I don’t know your level of knowledge, so better to wait for you to ask.

On your Leap 15 system, you should have a file “/usr/share/syslinux/altmbr.bin”.

That’s boot code for the MBR. It is actually 439 bytes long. You need to add one additional byte to make it 440 bytes long.

I’m using that on a laptop. On that laptop, linux (the partition containing “/boot”) is “/dev/sda5”. And Windows 7 boots from “/dev/sda3”.

I created a byte containing 5 (hexadecimal 05, binary 00000101), and appended that to “altmbr.bin”. I name the resulting file “altmbr-05.bin” to help me remember what is in that extra byte.

I then wrote that to the MBR (first 440 bytes of “/dev/sda”).

I then set the active flag of the MBR to partition 3 (the Windows 7 partition).

When I boot, that “altmbr-05.bin” as boot code will always boot partition 5, and ignore the active bit. So Windows thinks it is set to boot, but I actually get my grub2 boot menu.


There’s actually another alternative that I have also used. You can have the system set to always boot Windows. But add an entry to the Windows boot manager that you can select to boot openSUSE Leap 15.0.

On 4/16/19 1:33 PM, Peter_Abc wrote:
> I would like to highlight an issue I have been having updating the
> Windows OSes and how I work around it. I am using grub2 from Leap 15.0
> to control the multi-booting on a legacy MBR partitioned disk. On sda1
> is the system partition for windows, sda2 is win7-pro OS, sda3 is win
> 10-pro OS and sda4 is an extended partition where I have my Linux
> partitions and 1 ntfs partition at the very end of it. Grub 2 is set to
> boot from the boot partition but in fact it sets the extended partition
> as active.
>
> From time to time win7 OS would refuse to complete its monthly update
> and win 10 has been doing same on a more regular basis (last 3 mths in a
> row). I end up setting (from within windows OS) the windows system
> partition (sda1) as active, reboot and all updates get installed without
> any issues. I then boot into super grub disk 2 from a bootable usb
> stick, pick my openSUSE OS and boot into it and reset my bootloader via
> yast2 and all is OK after.
>
> Unless someone knows an easier way to work around this issue, I think
> that is my fate - mucking around and wasting time.
>
> Cheers,
> Peter

As I don’t use the windows OSes for anything at this stage and I mainly
boot into them once a month or once every few months, I had not noticed
that Windows 10 does not shutdown when Grub2 is running the show. It
restarts without any issue but shutdown option just brings up the login
screen. I tested with the system (sda1) partition as active and it shuts
down fine, no issues.

Furthermore, I previously ran into some serious issues when doing a
clean install of windows 10 from an iso (on a bootable usb stick) whilst
system was controlled by grub2. It did not recognise the system
partition and instead used the win 7 partition as the system partition
and installed the boot files in there. I ended up doing a complete
reinstall of everything windows from scratch with sda1 set as active.

On 4/16/19 3:06 PM, nrickert wrote:

Thanks for your informative reply and it is good to know that there some
options I can consider. But I have never read any warnings about these
issues before and I am quite disappointed that no prominent warning has
been given to Linux users like myself.

> Yes, there’s a way around this.
>
> I’ll just outline it here. You can ask for more detail where needed. I
> don’t know your level of knowledge, so better to wait for you to ask.

At this stage I don’t have a lot of time or energy to tackle this right
now. I have some serious health issues (dealing with cancer and the side
effects from treatment and surgeries) but maybe I can try later on in
the year if my health permits.

My technical knowledge is not very advanced and would be way below of
that of the experts and system admins that frequent these forums but I
can do a few things that a complete novice would think that I am an
“expert” at. I have been multi-booting for 20 plus years, mainly using
boot managers in the early days and grub/grub2 in the last 12+ years. I
have used openSUSE since I ventured into Linux and I can manage the
routine administration of a basic desktop system reasonably well. I use
commercial software tools for partitioning and backups from Paragon and
Acronis and Super Grub2 Disk for boot recovery.

Lastly, if my health permits I will call upon you for some guidance in
trying the first option. The second option I would not like to use as I
have Win 10 controlling win 7 in dual boot option and it is very
irritating to use. When I boot up I get the option to boot either Win 10
or win 7 and choosing Win 7 restarts the PC instead of booting directly
into it, as Grub2 does.

Cheers,
Peter

> On your Leap 15 system, you should have a file
> “/usr/share/syslinux/altmbr.bin”.
>
> That’s boot code for the MBR. It is actually 439 bytes long. You need
> to add one additional byte to make it 440 bytes long.
>
> I’m using that on a laptop. On that laptop, linux (the partition
> containing “/boot”) is “/dev/sda5”. And Windows 7 boots from
> “/dev/sda3”.
>
> I created a byte containing 5 (hexadecimal 05, binary 00000101), and
> appended that to “altmbr.bin”. I name the resulting file
> “altmbr-05.bin” to help me remember what is in that extra byte.
>
> I then wrote that to the MBR (first 440 bytes of “/dev/sda”).
>
> I then set the active flag of the MBR to partition 3 (the Windows 7
> partition).
>
> When I boot, that “altmbr-05.bin” as boot code will always boot
> partition 5, and ignore the active bit. So Windows thinks it is set to
> boot, but I actually get my grub2 boot menu.
>
> -----------
>
> There’s actually another alternative that I have also used. You can
> have the system set to always boot Windows. But add an entry to the
> Windows boot manager that you can select to boot openSUSE Leap 15.0.
>
>

Maybe I’ll leave a link here. When I first started using that method (in 2015), I posted about it on my blog:

Generic boot code
I have been happily using that method ever since. That blog post gives a bit more detail than I provided above.

I don’t know if this is pertinent, but I do what the OP wants(I think).
I installed EasyBCD in Windows 10, and set it up to load Win 10 and Win 7.
From the grub menu I choose Windows 10 on sdx, and it opens a Windows boot manager. From there I pick either Win10 or Win 7.
Note> of late I rarely go into either of the windows as MS has fubar’d them to the point of non-usability IMO.

Win 7 is history as of Jan, 2020.