Pri

Welcome Eli, I hope you have a great time working on Unraid for all of our benefit

I think it's probably time Unraid supported more boot methods. Now that it has a lot of advanced functionality like Docker, VM's and is becoming more critical to peoples setups more redundancy should be available. I'm not suggesting that the USB method should be done away with, but it should be just one way to boot Unraid. As a new user to Unraid and someone who has built many redundant systems and writes server software (including resilient databases and cluster software) a few design choices do seem wrong to me but can be corrected. Please give me the benefit of the doubt with that statement as I don't mean to come in as the new guy and say you're doing it all wrong! I do like that Unraid runs from memory, keeps it fast and keeps developers constrained, they know it has to fit in memory and cannot be a resource hog. But the 32GB USB limit isn't great, it's becoming more difficult to get high quality name brand USB drives in this capacity, not impossible but difficult. It's also becoming harder to get USB 2.0 only drives, high quality ones anyway. These things can be mitigated by supporting USB 3.0 drives and higher capacity drives but then we move onto the USB flash quality. As the capacities have increased the NAND quality has decreased. We're in QLC territory now and even then with bargain barrel flash and at the extremely high transistor density level which lends itself to unreliability. Combined with that many of the good sticks run very hot and aren't at all intended to be left plugged into a USB port powered on for years at a time. I echo some earlier posters statements about heat and how some of the sticks are so hot even when just left idle without any read/writes occurring that you cannot pull them from the USB port without being burned or feeling that it's uncomfortably hot to the touch. Probably the final nail in the USB situation is you're performing writes to it when configuration changes are made but can't easily verify they worked and if you then later reboot or cold start the system that is when the USB drive is most likely to fail leaving you in a precarious situation. There's no RAID1 capability, we don't even have file checksums. What I'd really like is the capability to install Unraid on normal drives with RAID1 just for the added redundancy and flexibility. It will also allow those of us who are building more critically depended upon servers to spend the amount commiserate with our systems. I'm currently building a wildly expensive Unraid server and the lynch-pin is a $15 USB stick. If I had the option of using a SATA DOM with high quality SLC flash or a SATA or NVMe SSD with SLC flash then I would, and I would likely use RAID1. Also I recently discovered after using Unraid that you cannot enable or startup VM's unless the raid is started. And some on discord alluded to this being tied to the license which as you all are aware is tied to the USB sticks GUID. It seems very odd to me that anything should stop the VM's from being started independent of the Unraid disk array. They seem so separate to me, what if I have all my VM's on a pool device or a ZFS array. If I'm doing some kind of disk operation on my main array that means it has to be offline for several days then I cannot start up any VM's? - Seems like bad design to me and it's probably why some people on the forums and on Discord are running Unraid under a more full featured hypervisor. I know this issue isn't strictly USB drive related but it's all part of the same tangled mess. The licensing is tied to the USB drive, that's currently the only boot method, they're prone to failure, you can't run VM's without the array enabled which requires the USB drive for licensing etc I fully intend to build a whole bunch of Unraid servers for myself and friends and this is probably the biggest sore point, when you're building in so much redundancy, be it dual PSU's, dual Nics, dual parity protected disk arrays, dual SSD's in RAID1 for your cache and/or VM's but then it all comes down to such a unreliable booting method, that just seems to me something that needs to be corrected for the project to keep progressing and improving, just how TrueNAS is adding better VM support, offering Linux with better drivers, just how pfSense now supports ZFS booting with RAID1 disks etc - All these projects that are in the same sphere are examining things that made sense years ago and saying ya know, today that doesn't make sense, that needs to evolve so we can better serve the needs of our users. I hope my post comes across in the positive intent that I meant it, I'm definitely not saying the sky is falling I just want to express how important I feel more boot options are. This topic started in 2014, it's now 2022. I'd love to see this happen before the end of 2024 really.

I recently had this issue while trying Unraid for the first time and I found out what caused it at-least for me. When I uploaded my .iso I used the File Manager plugin of Unraid, meaning I uploaded it through my web browser into a folder on one of my storage disks and then used that to boot the VM. This always results in the error shown in this thread. However when I created a share on my Unraid which I accessed from my PC via SMB and uploaded the .iso to my Unraid server through that share it boots successfully, every single time. So I don't know why the uploader failed but I suspect it either corrupted the .iso in a non-obvious way or wiped some metadata from it I'm not sure, but uploading the boot media via a share works and uploading through the WebUI of Unraid does not. I know this is an old thread but when googling the error it's just this thread that comes up and I figure others may benefit from this answer