Live USB of endeavour is not being detected but other distros are

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

2 Likes

@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?

1 Like

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.

1 Like