Setting BIOS Boot Order To Linux On NVMe Card Doesn't Work But Manual Choice Does

ODYSSEY-X86J4105
No changes to the Windows configuration on the eMMC
NVMe card installed and recognized in BIOS
debian 4.19 installed on the NVMe, recognized in BIOS and fully working

When booting, if I press F7 and select debian, everything works as expected.

In BIOS if I set debian as the first boot option and Windows as the second and then save and reset, the system will boot into Windows. When I go back into BIOS, Windows is now the first boot option.

How can I get the system to preserve the boot order and to boot off the NVMe ?

Thanks!

Hi @YVRseeduser

Sorry for this issue. Did you try more than once(did it happen more than once). I have tested on the x86 on my end and it’s working okay. May be shift the windows boot option lower down?

Thanks for the response. I’ve tried multiple times and the result is the same.

I’ve disabled the eMMC in the BIOS so the only boot options are Debian on the nVME and it boots into UEFI manager.

I’ve changed the order so Debian is first, Windows is second and the UEFI manager is third - Windows boots.

I’ve changed the order so Debian is first, UEFI is second and Windows is third - UEFI boots.

Will see if I can modify the Windows boot manager to chain to grub which will start Debian.

1 Like

Hi @YVRseeduser

We did some testing and it could be the issue with the RTC battery. Save your settings in BIOS, then reboot again, see if you can see Seeed logo twice. If you see it twice then it’s the RTC battery that caused the issue. Or if you have multimeter around, you can simply measure the RTC battery to check.

Best Regards,
Anson

I experienced this issue as well and have not solved it. That is, the system would change windows to be first in the boot order, no matter what boot order I chose and saved in BIOS settings. Other BIOS settings got saved fine, and my CMOS battery shows 3.3v at the traces on the board. If I intervened with f7, I could choose the debian I installed on the M.2 nvme. But the system felt and feels it necessary to change windows to be first in the boot order if eMMC is enabled. I think it may largely or completely leave the boot order alone if eMMC is disabled (really, no windows present one way or the other in eMMC, presumably).

My workaround so far is to disable eMMC and leave it that way, install the seeed-provided windows 10 in a portion of the M.2 nvme, install debian in the rest, and use grub to choose debian or windows. I may or may not keep the windows, but for now, yes. (I’m also curious whether I could use windows, run debian in a VM, and still access the rpi GPIOs (as well as arduino - haven’t done that test. Or, debian and then windows in a VM – as I said, haven’t decided as to how important windows is, tho I have legacy stuff that uses it).

(I don’t have any answers from seeed on the boot order changes, because apparently they have chosen to ignore me after I had the audacity to ask them the function of the header pins on the board pre-sale (now figured out by experimentation).)

Did you ever figure out a solution?

I see the same problem with bios notoriously reverting to boot windows from the eMMC.
A part solution for me is to remove in bios any other boot option and only leave ubuntu bootloader on the NVME drive.
When it boots it still gives me an option to do load Windows, when I rarely need it to log some data form the 5G card.

Thank you, Maciej. Glad you solved it well enough for yourself. It’s been a few weeks since I was looking at that problem, so it’s a little hazy what I ended up with. My notes to myself say seeed support was no help at all, actually silent, sadly (seeed support has unfortunately been unhelpful, silent, or mildly confrontational so far, for me). Looks like what I did was install both windows and linux to the nvme, and I disabled emmc (well, at least, it is still disabled at this time). I suppose what I ought to try now is wipe the emmc so there’s not an OS there and re-enable it for data use. It was a little tricky as I remember installing the windows image as given by seeed to the nvme (perhaps a fresh install without using theirs would have been less trouble, but at the time I was trying to be as kosher as possible re the starting software and keep it as seeedlike as possible).

I notice I emailed myself about this, excerpted . . .


  1. One basic problem was that if emmc is enabled, the bios really wants to boot to any windows on it, ignoring bootable content on the m.2 ssd [no matter what the boot order says in bios]. They have no answer so far for that (or even admit it is a problem).

  2. Another problem is getting the windows 10 enterprise content onto an ssd in the m.2 slot.

I messed around for hours trying to play with (1) (no success), and eventually disabling emmc means it doesn’t try to boot from that, so there’s a workaround (or else, disable/enable emmc every time to avoid or use windows). I would rather not have to use such a workaround, and have a big ssd in m.2 slot, so try putting w10 on the m.2 ssd along with debian. Depending on whether I use windows much on this pc, that may not be needed, but I will leave the option open.

Re (2) I tried various methods to clone or migrate or restore the Windows 10 enterprise to the m.2 nvme ssd, but no luck, until, after I had finally and irritatingly messed up the emmc windows bootability, I was able to restore the emmc Windows 10 enterprise from the seeed Windows 10 enterprise image resource, and to restore as well (after disabling emmc) to the m.2 nvme drive, then shrink the partition on the m.2 ssd to allow for dual boot with debian until I figure out which approach I want to go (no windows at all, windows + debian dual boot, windows + debian as vm, but not sure I want win10 primary on this machine and not sure if one can access stuff like rpio with debian as a VM, so not sure about that last approach).

The restore procedure for solving (2) is, unzip the content of the seeed w10 resource, which I have stored as orig_w10_image__SD-JX-CJ41G-M-101-H. Then prepare a big SD card (I used 32GB) using diskpart, and copy the files from the resource to the root directory on the SD card. Then reboot to the USB drive/SD card, and windows will restore from it, critically making drive w: with the new w10 content, which is the drive you are restoring to and will be as big as the drive you restore to is (and I think it ditches any content on that drive).

The instructions for using diskpart to create the bootable usb with restorable w10 content [can be found by searching for this phrase and getting a hit on woshub.com (slash how-to-create-uefi-bootable-usb-drive-to-install-windows-7), look about one third of the way into the article], search phrase being “Using Diskpart to Create UEFI Boot-Stick with Windows”.

@toddcromiii We noticed this problem and we have fix it in next BIOS version. We will release soon.