Win10 and MX dual boot - startup goes directly to Windows

[noClue]

As I've said before, I don't really know very much about it since Mint uses Ubuntu signed UEFI Boot-Loader and since I'm disabling UEFI on each and every of my own computers before the very fist boot.
I've used it only 2 ~ 3 times and if I remember correct, it would bring up a list with all bootloaders it could find. One could set it up so that Windows sees them.
It really doesn't matter if the Grub boots Windows or the Windows shows Grub to boot Linux.
I only remember, I could rescue those computers with its help.

[Sparky]

try either the escape key or F12, it should take you to the startup manager of the BIOS and select which you want to boot.
Alternatively, enter BIOS the usual way and go to boot order and select Windoze as first boot

P.S. I just realized you said Mint, I'm not sure how it's done in Mint, but should be similar

[Stevo]

Could you at least give us the Quick System Info for the machine? Otherwise we're taking shots in the dark!

[Morcelas]

Could you at least give us the Quick System Info for the machine? Otherwise we're taking shots in the dark!

Sorry for the wait, here is the info:

Code: Select all

OS Name	Microsoft Windows 10 Home
Version	10.0.17763 Build 17763
Other OS Description 	Not Available
OS Manufacturer	Microsoft Corporation
System Name	DESKTOP-FV53VQ6
System Manufacturer	Hewlett-Packard
System Model	HP Pavilion 15 Notebook PC
System Type	x64-based PC
System SKU	F4V91EA#AB9
Processor	Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz, 2401 Mhz, 2 Core(s), 4 Logical Processor(s)
BIOS Version/Date	Insyde F.72, 3/9/2018
SMBIOS Version	2.7
Embedded Controller Version	29.66
BIOS Mode	UEFI
BaseBoard Manufacturer	Hewlett-Packard
BaseBoard Product	2166
BaseBoard Version	29.42
Platform Role	Mobile
Secure Boot State	Off
PCR7 Configuration	Binding Not Possible
Windows Directory	C:\WINDOWS
System Directory	C:\WINDOWS\system32
Boot Device	\Device\HarddiskVolume2
Locale	Portugal
Hardware Abstraction Layer	Version = "10.0.17763.194"
User Name	DESKTOP-FV53VQ6\Casa
Time Zone	GMT Standard Time
Installed Physical Memory (RAM)	8.00 GB
Total Physical Memory	7.78 GB
Available Physical Memory	5.35 GB
Total Virtual Memory	9.65 GB
Available Virtual Memory	6.99 GB
Page File Space	1.88 GB
Page File	C:\pagefile.sys
Kernel DMA Protection	Off
Virtualization-based security	Not enabled
Device Encryption Support	Reasons for failed automatic device encryption: TPM is not usable, PCR7 binding is not supported, Hardware Security Test Interface failed and device is not InstantGo, Un-allowed DMA capable bus/device(s) detected, TPM is not usable
Hyper-V - VM Monitor Mode Extensions	Yes
Hyper-V - Second Level Address Translation Extensions	Yes
Hyper-V - Virtualization Enabled in Firmware	No
Hyper-V - Data Execution Protection	Yes

With some UEFI firmeware you cannot do much, as it always try to boot into Windows first.

But there is still hope : One easy way which I would try fist is this one.
Windows does place two EFI-boot loaders on the ESP (EFI System partition)
Its official own Boot loader:
ESP-Partion: : /EFI/Microsoft/bootmgfm.efi
and a 2nd one:
under the so called EFI-fallback bootloader:
ESP-Partion: : /EFI/BOOT/bootx64.efi

Some UEFI firmware re-reading or ignoring the internal stored
boot order, when Microsoft is not first or something have changed and
do rescan the /EFI-directories and do choose very often to start the EFI-fallback loader

So you could try to first re-name (so you have a backup)
/EFI/BOOT/bootx64.efi to /EFI/BOOT/bootx64.efi.Windows
and
than copy
/EFI/MX18.1/grubx64.efi to /EFI/BOOT/bootx64.efi

With some luck you are in business, again ;=), as UEFI firmware might now boot directly into MX Linux.

Another way you might also try:
There are some other efibootmgr tricks, but all depends on the UEFI firmware of the device.
You could also try to NOT change the boot order with efibootmgr,
but instead "de-activating" the first Windows entry, but such that it still
stays on first boot position. As this might not trigger UEFI-firmware reordering.
But the deactivated "Windows" entry get ignored during UEFI-boot and next MX18.1 is choosen to boot into.
Good Luck.

HTH

The closest I have to a \EFI folder is C:\Windows\Boot\EFI with bootmgfw.efi and bootmgr.efi files and searching for bootx64.efi, grubx64.efi or MX18.1 turns up nothing

[fehlix]

The closest I have to a \EFI folder is C:\Windows\Boot\EFI with bootmgfw.efi and bootmgr.efi files and searching for bootx64.efi, grubx64.efi or MX18.1 turns up nothing

Better look from MX Live booted, as from within booted Windows you might not see the ESP-partition.
As Window tend to hide the boot partitions as they also do for their system partitions.

[Head_on_a_Stick]

It should be possible to instruct Windows to boot the MX .efi loader by running this command from an Administrator prompt in Powershell:

Code: Select all

bcdedit /set "{bootmgr}" path "\EFI\MX18.1\grubx64.efi"

More here: https://wiki.archlinux.org/index.php/Un ... boot_order

Renaming the MX .efi loader to bootmgfw.efi should also work but I think Windows may "correct" this after a major update.

[fehlix]

It should be possible to instruct Windows to boot the MX .efi loader by running this command from an Administrator prompt in Powershell:

Code: Select all

bcdedit /set "{bootmgr}" path "\EFI\MX18.1\grubx64.efi"

More here: https://wiki.archlinux.org/index.php/Un ... boot_order

Renaming the MX .efi loader to bootmgfw.efi should also work but I think Windows may "correct" this after a major update.

Very, good. Yes, using windows own bootmgr to chainload into grub's efi-bootloader, is good alternative.
Would not recommend replacing Windows bootmgfw.efi with mx-grubx64.efi. Alternatively placing mx-grubx64.efi
into as default efi-fallback into /EFI/BOOT/bootx64.efi.
A more robust way for non-secure boot is probably to use rEFInd bootmanager anyway,
which scans during startup all available efi-bootloader.
This all in addition to sort out UEFI's own bootable entries within UEFI-setup and/or in addition with linux efibootmgr.

[Head_on_a_Stick]

Would not recommend replacing Windows bootmgfw.efi with mx-grubx64.efi. Alternatively placing mx-grubx64.efi
into as default efi-fallback into /EFI/BOOT/bootx64.efi.

Unfortunately, some UEFI implementations are so broken that they will only boot $ESP/EFI/Microsoft/Boot/bootmgfw.efi

More on this on the rEFInd author's web site:

https://www.rodsbooks.com/efi-bootloade ... ive-naming

In a dual-boot situation it is possible to rename Windows' bootmgfw.efi and then use the chainloader directive in GRUB to start it.

[fehlix]

Unfortunately, some UEFI implementations are so broken that they will only boot $ESP/EFI/Microsoft/Boot/bootmgfw.efi

Yes, understand and a valid point. As not all UEFI'S do have this limitations would regard this as last resort, otherwise the OP might even get blocked to boot into WinOS. So recommend to try other things first. E.g in addtion to rEFInd create a grub-rescue iso, or chainloading from booted LiveUSB into the install MXlinux and try to sort this through this way.
In addtion one limitation is always secure boot has to be disabled.
But of course if that would be the only way, the rename could also reverted using LiveUSB if needed.

[Stevo]

Since it's using an Insyde "BIOS" like those Acers that have the same problem, I have to wonder if the same workarounds are necessary:

viewtopic.php?f=23&t=49009