The partition table is inside the ISO. I am not in front of a PC right now to check though.
I am looking into this, havenât tried it yet. Seems confusing a tad.
I donât know if the USB drive is or isnât using a GPT partition. I am simply writing the ISO to the USB and attempting to run it. I havenât seen anything in the process of flashing the ISO that asks to edit any options with GPT partition in it.
First, make sure that the usb drive is not mounted. You can check with the lsblk command. Take note of the device path of your usb. For this example, letâs assume that the device path is /dev/sda
After that, you just have to run this command:
# dd bs=4M if=path/to/isofile.iso of=/dev/sda conv=fsync oflag=direct status=progress
For the device path, do not specify the partition number. E.g. use /dev/sda not /dev/sda1
Okay, I was able to write the USB using this dd command method but still no luck. Wonât detect the USB.
Iâm noticing a pattern here. All Arch based distros do not live boot from USB. All Debian/Ubuntu based distros do boot from USB.
Yup. Like @dalto has pointed out above.
This may be a long shot, but try resetting the BIOS to factory defaults. Then double-check secure boot is disabled and test again.
I clicked âload optimized defaultsâ⌠then tried again. No luck. This is driving me nuts.
What does Intelâs support team says? If itâs a bug in the BIOS that shows âSecure Bootâ as disabled when itâs actually still enabledâŚ
Is there a way to verify whether secure boot is truly disabled other than through the BIOS? Like from inside an OS, for example.
mokutil --sb-state
@Kundalini You said you have other distros installed, right?
I think this is worth a try.
Intelâs support is overseas agents with scripted responses. They simply say âwe do not support linux blah blahâ.
I ran that command in Fedora Konsole, and it came back âSecureBoot disabledâ
you could try playing with the settings in the UEFI/BIOS. eg. TPM off, Arch supports TPM normally, but it doesnât hurt to try to track down the problem. later you can reset all settings.
Does UEFI shell access come in handy in any way? I was able to access this by turning it on in the boot settings.
I should also note that I took an NVMe M.2 SSD from another computer I have with EOS already installed on it and put it into this device we are having trouble with to see if it will let me boot into EOS and it does. I tried this just for testing purposes. So the conclusion is that the OS can run, but just getting the USB to be detected by BIOS is the issue at hand.
Can anyone verify this?
@Kundalini Maybe log into an OS (any OS that you have access to) plug in the live USB and run parted -l or something?
Before buying this Intel NUC 12 Enthusiast, I owned the 11 Enthusiast model and EOS installed just fine. Itâs this new one that seems to be an issue. The only major difference in hardware is now I have an Intel GPU compared to the last one which was an Nvidia GPU. I ran that command in fedora, and it came back with this:
Correct me if Iâm wrong, but it looks like the live USB currently uses msdos as the partition table?
This contradicts what was stated in the article I shared above?
That is likely the issue. Archiso, which most Arch-based distros use, is using a legacy/mbr partition table.
@Kundalini, to work around that BIOS limitation you can can disable UEFI boot and legacy boot the installer instead unless you need EFI support in your install.


