Recently, all the times I installed EndeavourOS from the ISO file I flashed on a USB key, I noticed that the USB key is not anymore recognized as bootable, once I install EndeavourOS. This can either happen an hour after I flashed the USB key or a month later.
I flash the USB key from a Windows 10 machine using Rufus or, lately, balenaEtcher. I also tried flashing the USB key with dd, but half of the times, the USB key is not bootable.
Is there anything I can do to avoid it happens?
I am not trying to understand why that happens, but if there is anything I can do, like (for example) marking the USB key as not writable. (I guess it could make sense, since the support used to install could also be a read-only support like DVDs or CDs.)
I did it, but it only shows a generic Removable drive entry which does not boot from the USB key. (It actually boots EOS from my hard disk.)
Only once I flash again the ISO on the USB key, I can see a boot entry for the USB key, and boot from that.
Normally, no matter how old the ISO is, it should boot. In this case, it could be a mechanical issue with the connector from either the USB key or the port. But that is something for you to figure out by trying several times.
Before we go further asking each micro step to each other could you describe what you did?
With this I mean, which method do you use to write the ISO, and if you tried to boot another distro on these computers?
You can check in Gparted if the usb drive still has a boot flag checked? If not it is not recognized as boot medium anymore.
How that could happen is the question though
Are you running multiple OS’s on your computer? Like EnOS plus Windoze, or OS-X? That could reset some bios functions regularly.
Also, like Brian suggested, I’d look deeper into the start-up options of Bios/UEFI of your system. - Perhaps, it can be updated from the vendor’s site, too?
I installed only EndeavourOS.
To select the USB key for the next boot, I enter in the UEFI settings to select the USB key as first boot entry, but there is not entry for the USB key, except a generic one that does not select the USB key. (In fact, it just boots from EndeavourOS I installed from the USB key.)
not to rewarm this thread… but to mention… in cases you need to plug USB drive off the system and replug after power cycle to get it visible again. I have this randomly with usb sticks in general independend from what is written on them…
My experience with such issues is to ensure the USB partition table is using GPT rather than MBR. This almost certainly will always be recognized by UEFI only motherboards. I’ve only seen USB Live boot issues on motherboards that don’t officially support legacy boot.
Rufus and Ventoy are the only two applications I know of that give you the option to choose GPT partition table.
usually … the ISO creation is done in hybrid-iso mode it is ready to be used as it is and what is recommended is to write the image without any changes to the usb pendrive.
Every change of the structure will make the ISO unstable
I have a motherboard that doesn’t support legacy boot, and I can only boot the EOS ISO if it’s in the GPT partition table via Ventoy. If it’s MBR, the USB is never recognized by the BIOS BOOT. Took me a long time to figure this out through troubleshooting and I came to the conclusion that if it’s UEFI only, this is what it takes.
ventoy is a bootloader already… kinda a chainloader that loads the ISO in later state… i bet you can boot ISO just fine if you use direct write methods like dd ?
The partition table matters for some motherboards. It’s not just the EOS ISO. It’s the same for Arch, Debian, FreeBSD, slackware, gentoo, you name it. I used Fedora image writer, popsicle, dd, etc. All of them fail to detect the USB on boot. It simply doesn’t show it in the boot device options.
As soon as I make a Ventoy USB with GPT partition, voilà , Ventoy USB is detected and all ISOs load. I spoke to the manufacturer of my mobo (intel) and they told me legacy boot is not supported. That’s what led me to look deeper and find this solution.
can be that indeed, there are a lot of badly designed efi systems out there.
What i was mention was that the ISO itself can not be changed to hafe gpt nor msdos partition table, in case of ventoy you boot the ventoy bootloader and from there ventoy chanloading the ISO as it is or even using its own chanloader that uses grub to load the ISO… but the ISO is intact as it is you only copy it as it is to the ISO storage used by ventoy.
And the ISO is a hybrid ISO having both options to be autodetected and used by the firmware/Bios efi is following default standards to be booted properly on the ISO.
If the efi/firmware is wrongly detecting legacy boot also they say they do not support this… sounds a bit like they hide faulty design by that …