UEFI options and non-booting USB stick

[Zoinks]

I'm having a hard time repairing a partition from a bootable USB drive. I keep getting "Active partition not found!" I've been trying several "compilation" ISO's like UBCD. This one for example, will boot to the menu after the not found message, but I can't start parted magic. I'm getting a lot of ISO's that don't boot, and a lot that boot but don't work.

To hopefully make it simpler, I purchased and downloaded ISO directly from parted magic, but that gives me "Reboot and select proper boot device" if I burn that alone to USB. I burned this with Rufus with the following:
Partition scheme: GPT
Target system UEFI (non CSM)
Burned as iso not dd.

I am totally confused by BIOS vs UEFI, MBR vs GPT, and CSM options.

I'm using a asrock taichi x399 MB. What combination of rufus and UEFI setting do I need to make this boot!

 

[Zoinks]

Simple yet obscure: disable CSM.

 

[Insert_Nickname]

In the boot options you should see two entries for a UEFI enabled flashdrive.

One is for BIOS/MBR booting and usually just lists the device name. F.x. "Kingston Flash Drive". The other is for UEFI/GPT booting. The entry should read something like "UEFI: Kingston Flash Drive". Use that one if you intend to install Windows in UEFI mode (usually best).

Windows requires a GPT partition table to boot in UEFI mode. If you try and boot the legacy BIOS/MBR device on a GPT disk, you'll be greeted by "Windows cannot be installed to this drive" when asked to choose install drive. And vice versa.

I hope that makes sense.

 

[RLGL]

Something else to look out for, Some boards have a selection for ultra fast boot, this does not detect the USB ports. They are picked up when the OS loads.

 

[mv2devnull]

Another quirk:
I got Windows 10 install media on USB. Those can boot both UEFI and legacy.
A Gigabyte(?) board saw only the legacy option.
It did turn out that at least that board was case sensitive about the \EFI\BOOT\BOOTX64.EFI
and since MS had written names with different case, UEFI saw "nothing".
(Fix was easy: copy to another pendrive and rename the crucial files/dirs. Inventing the fix took effort.)


The content of the image does affect how it has to be written.
Example: CentOS install image (that can be used to rescue) https://wiki.centos.org/HowTos/InstallFromUSBkey


Yes, the CSM. When on, only signed kernels can boot. And then some:
I had a valid Linux kernel that does boot with CSM. NVidia driver module has different signature. One has to add its key to UEFI in order to boot with CSM and get the driver loaded too.

 

[Shmee]

Yes this stuff can be a bit tricky, especially depending on all the different boards and their settings, not to mention different ISOs and methods of burning them to the drive.

Also keep in mind, a lot of times the compilation multiboot sort of images may have issues with some of their sub images regarding how the master is made with boot options in the GRUB. One example is YUMI UEFI, which works for me with most ubuntu based linux ISOs and even windows 10 installer, but I cannot get to work with memtest or Parted magic.

It turns out, I generally have to just use different drives for different images, or you can use a very handy ISO emulator on an external drive enclosure, such as my Zalman ZM-VE350. I put a 128GB SSD in it and by storing various ISO images under the _ISO folder, you can boot any of them using the switch on the enclosure like a DVD or CD, in either legacy or UEFI mode. Works well on most decent systems within 10 years of age. Only thing is the enclosures that support his are kinda pricey, generally $50 or more.

Also, unfortunately all the products that I have seen like this are a little bit older, in that none of them use USB C, but rather the USB 3 Micro B design.
http://www.zalman.com/contents/products/view.html?no=20

 

[Zoinks]

Thanks for all this. This used to be simple. Now, all these rules to learn...

 

[fire400]

don't worry, it'll change again when you switch motherboards and operating systems, and not to mention the flash drive classes - and additionally, what specific software tool was used to write the image onto the flash drive even though both pieces of software claim to use the "exact" same method, and the list goes on...