Hello,
I have a dualboot setup of Windows 10 Pro and openSUSE 15.2
I would like to change the boot proccess that I want to use the Windows bootloader in the MBR.
As of now YAST tells me that the Boot Loader Location is ‘Boot from MBR’
My question is - If I boot to Windows now and use EasyBSD to restore the Windows boot to the MBR, can I than add openSUSE 15.2 to the Windows bootloader AND will openSUSE actually boot?
Or do I have to change something in openSUSE first to make this work?
I’m not sure what you are trying to do, nor why. My advice would be to leave things the way that they are.
With legacy booting, Windows boots from a partition. It uses generic boot code in the MBR to locate the partition to boot from. With what you are doing, you have grub code in the MBR which then boots windows from its partition. So it isn’t much different as far as Windows is concerned.
If you really want to stop using the MBR, then you should set your system to boot from a partition and to put generic boot code in the MBR. But here’s the difficulty. With “btrfs”, you can only boot from a partition if it is the “btrfs” partition. The generic boot code that openSUSE uses will support that. But the generic boot code that Windows normally uses will not work for you because your linux system is in an extended partition rather than a primary partition.
That’s why my advice would be to continue booting the way that you have been doing it.
You need to check the boot from partition box to get Grub onto your openSUSE root partition, or there will be no way from disk to boot it.
Windows doesn’t put “boot” code in the MBR. It uses generic boot code, along with an active flag on its boot partition. If you were to have generic boot code installed to MBR by YaST, and the active flag put on the Windows system partition (sda2), you should be ready to boot Windows without EasyBCD, from which you could install EasyBCD to include a chainload entry for the partition with Grub on it (sda6).
O.k. - thanks for this answer.
I think I will stick to my current setup than.
The only reason to use it is that I thought this might solve a problem where Windows 10 would not complete its Windows updates.
I had this before. If booted directly into windows the Windows update would just work fine.
For some reason now, the windows updates get downloaded and prepared to be active on the next boot - but get reversed to the old version after the boot into Windows.
I have had that problem with Windows 7 and with Windows 8.1. I have avoided Windows 10.
As far as I know, it should be sufficient to set the Windows partition as the active partition. You can use “fdisk” for that. I think the problem occurs when Windows updates booting. After installing the update, it checks the boot path. And if the wrong partition is marked as active, that goes wrong.
With grub installed in the MBR, which partition is marked as active does not matter to linux. But it does still matter to Windows.
This is exactly the reason to use standard boot code, primary partition boot flag, and Grub on a primary partition. In this configuration the flag can be moved when it’s time for Windows to perform its update that won’t complete in the absence of its configuration expectation, then returned to the partition with Grub when it’s done. It’s more trouble to get the MBR code right when there is no primary on which to install Grub. So, every PC I have with Windows on it has a primary to host Grub, which is responsible for all booting when Windows doesn’t need a fussy major update.
Because of all this, the best option if Windows on multiboot on hardware (as opposed to in a VM) is required, is to switch to UEFI booting, if the PC supports it.
Well, from the above info I understand that I am not able to correctly update Windows10 Pro if for some reason the boot into Windows 10 is not initiated from the MBR.
So how would I be able to boot directly to Windows, let Windows update.
In my situation: can I update Windows10 and retain my setup without re-install of Windows and opensuse?
fdisk -l should tell us more then the pretty pictures. Generic MBR (also MS) uses the boot flag to determine the partition to boot from, Grub MBR is set to boot from a given partition and ignores boot flag.
IME, all you need is Windows-compatible MBR code, and a sole primary partition boot flag on Windows’ system/C partition, to succeed with updating Windows. Because I keep Windows-compatible boot code one the MBR instead of Grub, all I need to do to allow Windows to update without issue is move the flag from the primary partition that has Grub to the Windows system/C primary partition. When Windows is done, I simply move the flag back.
Installing standard MBR code doesn’t affect your openSUSE installation itself, only Grub. After Windows update is complete, the standard options are either rescue boot and reinstall Grub on MBR, or rescue boot and reconfigure openSUSE to boot from Grub on a native primary partition. The latter option for you is not immediately available because your primary partitions are all used up by existing Windows partitions. You would have to either wipe and repartition to have a primary partition available for openSUSE’s Grub to live on, or use the specific generic boot code that using YaST to perform the repair would install, which allows the boot flag to be on a logical partition instead of a primary, and then following the MBR code modification instruction provided by nrickert here in multiple forum posts. If choosing to repartition, the better way forward would be to convert to GPT partitioning, and if possible, UEFI for both openSUSE and Windows.
Using UEFI instead of Legacy booting removes the complexity. Neither openSUSE nor Windows care about MBR code or boot flags when using UEFI.
After change MBR -> GPT installed Windows 10 will not boot. User will need to reinstall Windows in 64-bit flavour.
For MBR dual boot you may use 2 (or more) physical drives. Booting with GRUB will let user to choose booting Windows from another drive.
Need more info about hardware to give better advice.
After change MBR -> GPT installed Windows 10 will not boot. User will need to reinstall Windows in 64-bit flavour.[/QUOTE]Of course! Repartition to GPT (from MBR) means 100% data loss, which means nothing to boot until fresh installation of openSUSE as well as Windows.
No, one can convert between MBR and GPT without losing data. Use utilities for that - MBR2GPT (from Windows 10), Paragon Hard Disk Manager, AOMEI Partition Assistant 6.6 or earlier, MiniTool Partition Wizard, or others.
does not have any extended/logical partition
For the above reason, this tool would be useless in probably most cases, if not by itself, by both itself and some other requirement. I wonder if this one’s considerable limitations are similar to the others.
As most probably all these tools are designed with only Windows in mind (yes, very narrow minded), I would be very reluctant to use them.
I also doubt if this will be of much use to the OP.
As far as I understand it, the original question was typically one of the kind: asking for the step (how to change off dual-boot) instead of asking for a solution for the real problem (how to get over the problem my Windows 10 update gives me).
IMHO we are now at the point where the several solutions are probably more difficult and time consuming then installing everything fresh.