a quick googling search appears to indicate that i’s because it’s based off of xen and xen is the issue.
Unfortunately my odyssey board is sitting in its flight case as my ground station computer so i don’t really want to overwrite the emmc partitions just to try qubes.
I could always install. Booting was the issue due to having an non EFI boot loader. There is a workaround for the bios EFI issues adjusting the boot loader manually but did not attempt as it would potentially cause other issues and constant hassles with system updates. Not worth it for the constant issues and time involved. It is more reasonable to pick up a different system or an nvme ssd
Successfully installed with boot to eMMc:
Mint UEFI from live desktop 
Fedora UEFI from live desktop “posting from unit at the moment”
Successfully installed with boot to sata SSD:
Qubes OS NON-UEFI from usb.
With none of the above hassle.
Hey just reviving this to say I too encountered this issue - when I had Windows on the MMC I had no problem installing an OS to the M.2 SSD I attached, but as soon as I wiped the MMC partition table to start a clean slate, no matter what install process I followed, no Linux distro would install for me. Most of the time install would go successfully but would simply not show as a boot option (so no GRUB install) despite the partitioning being done correctly for UEFI with GPT+EFI FAT32 /boot/efi partition + ext4 system partition. Ubuntu boot-repair tool could not fix the issues except to say that SecureBoot (or lock?) was maybe enabled on the NVMe SSD I had in the M.2 slot. I could not find any SecureBoot option in the BIOS, which I found very unusual as every computer I’ve owned has had an option to toggle it.
Fiddling around with CSM did nothing, and really that should only be used for running ancient operating systems that don’t support UEFI, it absolutely shouldn’t be necessary for anything modern.
I finally updated the BIOS and the EC, disabled the built-in MMC, then did yet another manual repartitioning of my SSD in the M.2 slot with a GPT table and the /boot/efi part and / ext4 part, and this time I was able to install Void Linux to the SSD and boot from it with UEFI enabled. I am not really sure why this worked, since the bios and EC update alone did not fix the issue, and I tried only installing to the SSD multiple times and ways before.
I have two theories what might have been happening:
A) Not having a CMOS battery is causing some issue perhaps? The sales material says its only for the real time clock, and indeed my BIOS settings saved no problem for months without it but now seem to reset frequently/every boot. Perhaps this device actually does require the batt for CMOS and I just lucked out and had a chip that held its programming without power for a few hours longer than usual until recently no longer being able to?
B) The BIOS flash may have a quality issue and is being tempermental/corrupted subtly? Perhaps the BIOS update didn’t fix the issue - just doing a BIOS flash was the fix as it would restore a fresh copy of the BIOS data until corruption occurred again.
C) The BIOS seems to have undocumented SecureBoot functionality that is not properly implemented and definitely has no options I can find. I could be wrong but most Intel x86 microcomputers & laptops shipping with Windows DO have SecureBoot enabled by default. Usually it can simply be toggled off in the BIOS settings.
D) Maybe its just as simple as the MMC itself failing/having quality issues? Odd though because once I finally got Linux onto it the system itself has experienced zero corruption issues. Also while I was initially trying both built in and the SSD would not work.
So I am really not sure why this is happening - but I strongly think its either undocumented SecureBoot functionality or some sort of intermittent issue with the BIOS memory or MMC storage chip. The fix for me was updating the BIOS and EC, disabling MMC in BIOS and using an SSD alone in the M.2 slot. Use GParted to do the partitioning, make it a GPT partition table, create a 300MB FAT32 partition give it the flags “boot” and “esp”, create your system partition (ext4, btrfs etc), and make sure when formatting with your distro (use the partitions made with gparted do not let the installer redo them) that you give the FAT32 partition a mount point of “/boot/efi” and your system part “/”. Use the application ‘efibootmgr’ before rebooting after installing to be sure an entry was added to the boot table. If not, you need to manually install GRUB to your /boot/efi partition - google for this as it tends to be specific to what you’re trying to setup.
Last but not least if this doesn’t work - before I finally got mine working, my next step was going to be to play around with the system’s UEFI Shell. When there is no OS installed the Odyssey boots to it by default but you can access it from the F7 boot manager too. This shell should be the final place where there’s a shot at fixing this as from there you can directly manipulate the UEFI firmware config. If this doesn’t work out I’m almost certain its out of your hands and a hardware issue
@LiamSP Thanks for pointing the problem. The answer to the question is as follows:
A&B : Odyssey need a RTC battery to hold the time and BIOS setting.
C: Yes, we will release a new version added secureboot and pxe boot.
D: it’s seems the UEFI setting problem. You can refer https://help.ubuntu.com/community/UEFI#General_principles
We just release the new EC and BIOS firmware, you can update now.
Ahh ok - I didn’t immediately install the batt as I was just testing it out and didn’t care about the time yet - no trouble to install.
Thats excellent I guess boot-repair was just detecting the SecureBoot feature in the chipset but was wrong that it was enabled. Looking forward to the updates to provide control of that and really liking the Odyssey so far!
