I used the Unraid drive creation tool to make a bootable USB on a 32gb Patriot stick I had lying around, and it reported success. If I try to boot from that USB however, it gets to my motherboard splash screen (the "Gigabyte: insist on ultra durable" one, where the OS is supposed to load) and appears to hang at that point, and also doesn't respond to keyboard inputs to jump into BIOS.

 

I've tried rebooting a few times, and have made darn sure that the USB is the top of the boot priority list.

 

Posting here because booting from a USB image of Ubuntu works fine and I can get to the operating system, so I don't think it's a hardware/BIOS issue, but rather something about the Unraid image specifically.

 

System information:

• AMD Ryzen 5600GT
• Gigabyte A520i M/B
• 2x g.Skill 16gb memory sticks
• WD Green 1TB NVME drive in the M.2 slot.
• No HDDs plugged in yet, was trying to prove I can get to the OS first before plugging everything in and buttoning it up.
• Attempting to image Unraid 6.12.8

You may have better success if you use the Manual method of creating the USB drive.   Seems to often work where the tool fails.

Still seeing the same behavior - the make_bootable.bat script appears to terminate successfully, but I can't actually boot to Unraid, and booting off my other USB to Ubuntu still works.

To add some more information here:
I'm not getting to the Unraid boot option GUI referenced in step 2 here: https://docs.unraid.net/unraid-os/manual/troubleshooting/

I've tried 3 different drives - a random USB 2 drive I had lying around, the Patriot 32GB, and a 16GB SanDisk Ultrafit. First and last by doing the manual install process, and the Patriot both manually and via the USB Creator tool.

 

Searching the forums for similar issues it seems like mostly it's "I forgot to rename 'EFI-' to 'EFI'", but I have definitely confirmed that the folder is appropriately named; each drive shows up in BIOS as a UEFI boot option, and I verified that it was first in the boot order.

 

I'm pretty sure I'm following the suggested settings here: https://docs.unraid.net/unraid-os/getting-started/advanced-bios-config/
Specifically, it is definitely the primary boot device, storage controller is not RAID, virtualization and IOMMU are enabled, and it's a direct USB port off the motherboard, and fast boot is off.

For all cases, I get to the BIOS splash screen but it hangs prior to seeing any Unraid OS elements.

Have you reformatted to FAT32 using RUFUS?

Try this during the POST routine of the MB startup (From the Manual):

 

 

Huh, okay, it works from F12 forced boot device, but then doesn't from the default boot menu. Any suggestions? Unless I'm going crazy I'm setting the normal boot priority in BIOS to be the USB drive first, but it doesn't seem to want to.

Is fast boot disabled?

 

Can you select the USB drive in the hard drive boot section? Some motherboards put the USB sticks in the hard drive list as well as the USB list.

Fast boot is definitely disabled. As far as I can tell this particular BIOS only has one location to set boot order, and it seems to be USB first. That said I'm not sure if the F12 menu is supposed to update as well or not, since the USB is not first in that list.

Every BIOS is different-- Even for similiar MB's from the same manufacturer.  This makes offering solutions for these types of problems very difficult.  Sometimes even a close reading of the manual will not answer some questions.   @IWasBornOnAWaterMoon, I would be googling the problem.  Keep asking Google with variations of the problem until you find the answer. You can also look at every screen in the BIOS to see if, buried deep down in the menu setup, there is another option for setting boot order. 

Edited March 5, 20242 yr by Frank1940

Okay, so this is solved, though I'm not entirely sure why:

On this particular Gigabyte motherboard, the USB appears as both "UEFI: DeviceName" and "DeviceName". Boot override into UEFI worked, but boot priority to UEFI didn't. Setting the boot order to the non-UEFI legacy version of the USB drive and leaving CSM enabled seems to have fixed it for a normal boot up procedure.