Lolight

Try this one listed as MLC. Once it's delivered, make sure to immediately verify the drive's components using ChipGenius and/or Flash Drive Information Extractor. Both are free tools that will reveal the drive's Flash ID and NAND type. Please share the readout here for future reference. https://www.reichelt.com/de/en/shop/product/usb_3_0_stick_16_gb_jetflash_780-220609#closemodal

Good question. The concern isn't about write-endurance at all -- Unraid writes almost nothing to the boot drive after the initial setup. The OS loads entirely into RAM on boot and runs from there, meaning the boot drive sits essentially idle 24/7. The actual concern is the exact opposite: long-term data retention and read-disturb resistance in a powered-on, idle state. Flash NAND cells store data as an electrical charge. Over time, particularly at elevated temperatures, those cells lose charge through a process called charge leakage. Smaller-geometry NAND (modern TLC and QLC) has smaller cells with thinner walls that hold less charge and lose it faster. In addition, they have many more voltage levels to manage, resulting in much tighter voltage margins -- especially QLC. Modern, powerful controllers must work overtime, producing significant heat even at idle, while managing all the extra noise generated by unstable modern flash memory. On the other hand large-geometry MLC NAND from older drives, with only four voltage levels, holds a charge far more reliably over long idle periods. Their controllers are basically doing nothing, since stable NAND doesn't require much processing power or complex algorithms. Read-disturb is a related issue. Repeatedly reading cells adjacent to stored data can disturb the charge state of neighboring cells over time. In an always-on server that occasionally reads the boot partition, this compounds slowly. Therefore, the criteria for an ideal Unraid boot drive are almost the inverse of what you'd want for a general-purpose USB drive: -- Large NAND geometry for better charge retention -- Fewer voltage levels -- A simple, low-activity controller that runs cool and performs minimal background work -- An Industrial temperature rating (preferred) -- USB 2.0 interface to keep the controller cool The drives most people buy today -- fast, high capacity, USB 3.0 consumer drives -- are optimized for everything except what actually matters for this specific use case.

NicT, the warning is just poorly worded legacy text from the older USB-to-USB transfer era. Clicking "Yes" won’t physically nuke your drive; it just blacklists that specific USB's GUID on Unraid's activation servers so it can never be used for a USB-style license again. Since you are moving to TPM (fTPM?) validation, Unraid will ignore the USB's GUID anyway, meaning you can keep booting off that exact same physical drive perfectly fine. However, you should weigh the massive architectural risks of moving to a TPM license while keeping your OS on a USB drive. You are essentially introducing the worst of both worlds: The Firmware Landmine: Motherboard BIOS updates sometimes clear the fTPM or reset platform security keys. If a future update alters your TPM cryptographic measurements, your Unraid license will suddenly show as invalid and lock you out of your array. Total Loss of Portability: The best feature of Unraid has always been its disaster recovery. If your motherboard fries on a Sunday night, you used to be able to just move the USB stick to a spare PC and be back online in 5 minutes. If your license is locked to the TPM, a dead motherboard means your license is trapped in dead silicon until you go through a manual emergency transfer with Unraid support. Double the Failure Points: You will still be exposed to the physical unreliability and heat degradation of a consumer USB drive holding your OS files, plus the hardware lock-in and firmware fragility of a motherboard TPM holding your license. If you want true portability and safety, you are much better off sticking to a USB-bound license, but upgrading the physical hardware to a real industrial-grade MLC USB drive (like a liquidated Innodisk 3ME currently on super sale) plugged into a USB 2.0 port.

Before you commit your paid license to that MicroSD card combo, I’d highly recommend reconsidering. While the teardown article you linked is excellent, it reveals that the card uses 3D TLC NAND. While 3D TLC is great for dashcams writing huge, continuous video files, it is not optimal when used as an OS boot drive. Furthermore, if that consumer SanDisk card reader dies or overheats, your license GUID goes with it, even if the MicroSD card itself is perfectly fine. A much more reliable option: a real industrial-grade MLC Innodisk USB Drive 3ME -- eBay item number: 326046070546 These use Toshiba industrial MLC NAND designed specifically for embedded operating systems paired with a heavy duty industrial Silicon Motion controller with aggressive hardware wear-leveling. Plug it into an internal motherboard header on a 9-pin USB adapter or a USB 2.0 port. Because Unraid runs entirely in RAM after booting, you don't need USB 3.0 speeds. Forcing it to USB 2.0 drops the power draw and lessens controller heat, making the drive practically immortal. It will cost you only $4 per drive. I'd suggest buying a couple or more before they're all gone. You won't see deals like that again.

Before committing to either internal boot or TPM licensing it's worth reading the Boot Devices guide in the Boot Devices section of this forum. https://forums.unraid.net/topic/196967-unraid-boot-device-guide-usb-and-nvme-hardware-selection/ It covers the practical differences between USB boot and internal boot in detail -- including the recovery path when something goes wrong with each approach -- which is relevant to your portability concerns. Your instinct in question 4 is sound. USB licensing tied to a quality flash drive is genuinely more portable and straightforward to recover from than TPM, which introduces dependencies on specific motherboard hardware and can be affected by firmware updates. On your high endurance USB drive -- what brand and model is it specifically? "High endurance" means very different things depending on the manufacturer. Some drives marketed as high endurance are real industrial grade MLC NAND appropriate for always-on server use. Others are consumer recycled TLC or even QLC drives with "high endurance" on the label as a marketing term. Knowing the specific model would help confirm whether it's as reliable as you're assuming before committing the license to it. Also worth knowing -- today's counterfeit USB drives are virtually impossible to distinguish from genuine ones by appearance alone. Before trusting any drive with your license it's highly advisable running Chipgenius and/or Flash Drive Information Extractor on it. These free tools take seconds to identify the exact controller, chip ID, and NAND type inside the drive (unless it's SanDisk) -- confirming whether what's printed on the label matches what's actually in the casing. The Boot Devices guide covers what to look for in those results.

Take this opportunity to choose a good quality USB drive. Cheap Amazon drives are a common source of problems. If you need suggestions, just ask.

Intel Optane (3D XPoint) -- Best by far. 16GB or 32GB Optane drives have essentially unlimited endurance for Unraid’s boot workload. They’re the gold standard. Higher end 3D TLC (e.g. Samsung 970/980/990 Pro, WD SN850X etc.) -- Good endurance, much better than QLC. Still consumer-grade, but significantly more durable than the Kingston NV3. QLC (Kingston NV3, many budget 1-2TB drives) -- Lowest endurance. Fine for light desktop use, but not good for 24/7 boot + cache duty. If you’re committed to a shared NVMe for boot + cache, go with a good 3D TLC drive at minimum. For the absolute best endurance and peace of mind, dedicated small Optane drives for boot (mirrored if possible) + separate cache pool is the superior configuration. https://forums.unraid.net/topic/196967-unraid-boot-device-guide-usb-and-nvme-hardware-selection/#comment-1606140

Google's answer depends entirely on how you frame the question. Ask about typical consumer NVMe longevity in a laptop or desktop and you'll get the 60-80 year figure based on light daily workloads. Ask about QLC NVMe endurance under sustained 24/7 server cache workloads and you'll get a very different answer. The Kingston NV3 in your X15 is QLC NAND. QLC has the lowest write endurance of any flash type -- roughly 100-150 program/erase cycles per cell versus 1000+ for more durable 3D TLC. Under sustained cache activity it degrades significantly faster than the typical consumer use case those longevity estimates assume. Whether that matters in practice depends entirely on your actual cache write volume over time. The mirrored 1TB pool approach is probably the most pragmatic path forward -- at least a mirror means a single drive failure doesn't take both your boot partition and cache data simultaneously.

One thing worth knowing about that Kingston A400 before trusting it as your internal boot device -- the A400 has a mixed reliability reputation, particularly older units. Depending on production batch it ships with either a Silicon Motion or a Phison PS3111-S11 controller, and the Phison variant has a documented history of firmware issues affecting reliability. If yours is an older drive that has never had a firmware update it may still be on the original firmware which had known problems. Worth checking which controller you actually have using CrystalDiskInfo and verifying the firmware version before committing to it as your boot device.

"USB drives while not known for their longevity" is too broad a statement. USB drive longevity varies enormously by NAND type, controller, and use case. Quality MLC drives on internal USB 2.0 headers routinely outlast other server components in Unraid's always-on near-zero-write boot environment. Cheap QLC consumer drives on USB 3.0 external ports can fail within weeks. The range between those extremes is significant and drive selection matters enormously. More importantly for DezzyTee's specific situation -- the failure pattern across multiple different drives points away from drive quality as the cause. Drives that are recoverable by reflashing aren't dying from wear. Something in the update write process is specifically corrupting the bootloader, and when the same failure reproduces across multiple brands and models the common factor is almost certainly the USB port or motherboard's USB controller behavior during sustained writes. The most useful test before buying another drive: try connecting the current flash drive to an internal USB 2.0 header via a cheap 9-pin adapter rather than an external port, then attempt the update. If the corruption stops occurring the problem was always the external USB port's power delivery or signal integrity during write operations -- not the drives.

The Samsung Bar is the least bad option, not the best. Please check the MLC Flash drives thread. You can find lots of reasonably priced MLC NOS USB drive options that are still selling in the range of $10--25 though shipping to Europe would add a significant price premium. You might also want to check a MLC $4 industrial drive: eBay item number:326046070546 The MSI motherboard detail: some MSI motherboards have had documented USB power management and write reliability issues on certain chipsets. A USB port that works fine for normal operations but has voltage instability under sustained write load would produce exactly this failure pattern -- corrupting specifically during the update write sequence. Try the update from a USB 2.0 internal header connection rather than an external USB port. If the failure is related to the external USB port's power delivery or signal integrity during sustained writes, an internal header connection would eliminate that variable.

The SanDisk Cruzer Glide 3.0 is one of the lower quality drives you can use for Unraid boot -- cheap consumer NAND, USB 3.0 which runs hotter than USB 2.0 in an always-on server, and a known target for counterfeiting. Your original USB drive going read-only and corrupt may not be unrelated to the drive quality. A replacement of the same type is likely to develop the same problems. On TPM -- if you're staying with USB boot there's no benefit to adding TPM licensing on top of it. You've just added a dependency on your motherboard's TPM implementation without removing the USB drive. BIOS updates that touch firmware can affect TPM state, potentially causing licensing issues down the road. USB licensing alone is simpler and more reliable for a USB boot setup. For a replacement drive worth trusting, search eBay for item number:326046070546 -- industrial grade, around $4, plug it into a USB 2.0 port. There's also a Boot Devices guide in the forum's Boot Devices section that explains what to look for.

Great result -- the pool looks exactly as it should. To verify Cache and Cache 2 are consistent, run a BTRFS scrub on the cache pool. It reads every block on both mirror members and compares checksums -- zero errors after completion confirms the mirror is healthy and both drives contain identical data. On showing appreciation -- the best thing you can do is pay it forward. When you see someone else on the forum in a similar situation, share what you learned. That's how this community works at its best.

Before letting this run for another 10 days, I’d strongly suggest checking the syslog (/var/log/syslog) for hardware errors -- especially SAS/ATA resets, CRC errors, or link speed drops. If you see those, stopping the check and fixing the underlying hardware issue first would be safer.

Thanks for the detailed write-up. However, I think the broad conclusion that HAMR drives are unsuitable for Unraid parity is premature. Many users are running the newer Seagate Exos HAMR drives (22–28TB) with rebuild speeds in the 120–180+ MB/s range. Since you mentioned that individual drive tests show normal speeds (~200-250 MB/s), the bottleneck is almost certainly not the HAMR drives themselves. Something in your specific setup is limiting performance during parity operations. A few things worth investigating: What HBAs/controllers are the parity drives connected to? Are the drives and HBA getting significantly hotter during the rebuild compared to normal operation? Any difference if you temporarily move one HAMR parity drive to a different HBA/slot? Have you tested sustained sequential writes directly on those drives while the array is active? Changing multiple things at once (as you noted) makes it hard to pinpoint the real cause. It’s very possible the slowdown is related to one of the other changes in your setup rather than the HAMR technology. 25MB/s sustained on drives capable of 250MB/s individual throughput is a configuration or infrastructure problem. HAMR physics cannot explain a 10x throughput reduction that only manifests during parity operations on a specific platform while ZFS on the same hardware performs normally. The conclusion is almost certainly wrong.

The "should" and "probably" in that answer give me pause -- internal boot and USB flash boot are fundamentally different architectures with different filesystems, different restore procedures, and different UEFI dependencies. Whether the Appdata Backup plugin's flash backup function actually works correctly with an internal boot ZFS partition -- and critically whether its restore routine produces a bootable system -- really needs a confirmed tested answer rather than an analogy from the USB boot workflow. Would also be good to hear from @JorgeB on this one before anyone relies on it as their backup strategy.

Good result -- mirrored SSDs as the boot pool is exactly the right configuration. On the Bootdata pool -- yes it's a leftover from the previous failed wizard attempts. Since it shows No device and 0KB partition size you can safely remove it. Click on Bootdata, scroll to the bottom of its properties page and click REMOVE POOL. Nothing will be lost. On the efibootmgr failures -- these are normal on many motherboards. The UEFI handled the boot entry update itself which is why your boot order shows the two SSDs correctly despite the wizard reporting failures. This is a known limitation of efibootmgr on certain platforms, not a problem with your setup. On TPM -- your motherboard's SPI header is the right path for TPM licensing when you're ready. A discrete TPM 2.0 module in that header will be recognized properly and won't be affected by BIOS updates the way fTPM would be. On no continuation of the onboarding wizard after reboot -- correct, that's expected behavior. The wizard runs once during the initial setup reboot. Your setup is now: -- Mirrored SSD internal boot pool -- correct -- USB flash drive as unassigned with licensing -- correct -- NVMe cache pool unaffected -- correct Well done getting through what was a generally complicated situation.

One thing worth doing before you run the wizard again: make a fresh backup of your /config folder from the USB flash drive to a Windows machine. Given the wizard's behavior last time having a clean known good config backup before you start is good insurance.

Great -- no important data lost. Your path forward is actually straightforward now. The SPCC 512GB SSD (sdm) showing in your unassigned devices is exactly what you should be using for internal boot -- an SSD, not spinning hard drives. If you can find a second 512GB SSD a mirrored boot pool would be a better setup and is strongly recommended. A single unmirrored internal boot drive is a single point of failure for both your boot configuration and any data partition on the same drive. Suggested steps: 1. Stop the array 2. Remove the current internal boot configuration from the spinning drives -- this means going back to USB boot temporarily 3. Once back on USB boot cleanly, run the internal boot wizard again with the SPCC SSD as the target device 4. If you find a second SSD configure a mirrored boot pool On the USB flash drive -- keep it plugged in. You're right that it's still needed for licensing since you haven't moved to TPM. It's also your safety net during this transition. On fTPM -- first generation Threadripper fTPM is genuinely problematic. If you want TPM licensing eventually a discrete TPM module in your board's SPI header is the right approach -- but that's a separate conversation once your boot setup is sorted correctly.

The HDD boot priority taking over USB boot is actually the problem, not the solution. Your system is booting from spinning hard drives -- the two Seagate 4TB drives (sda and sdd). These are mechanical hard drives, not NVMe or SSD. Spinning hard drives are not appropriate internal boot devices and should never be used for this purpose. Your NVMe drives are all committed to your cache pool and were unavailable to the wizard. Rather than refusing to proceed the wizard used whatever was available -- your spinning drives. Before anything else please answer these two questions: 1. What were those two Seagate 4TB drives (sda and sdd) before you ran the wizard? Array drives? Empty drives? 2. You mentioned formatting the data volumes on them after booting -- did they contain any data before that formatting happened? This is the most important question in this thread right now. Everything else -- fTPM, boot pool display, BIOS settings -- can wait until we know whether any data was lost on those drives.

Just a heads-up: BIOS updates mentioning Secure Boot key update in their description (KEK/DB/PK) have been known to reset fTPM on some boards, which would trigger a license state mismatch. Worth keeping in mind if you go with fTPM.

Random disconnections on USB storage are almost always power management related rather than a fundamental stability issue. Two things worth trying: 1. Disable USB autosuspend via the go file if enabled (/boot/config/go). This prevents the OS from suspending idle USB devices and persists across reboots. Search for "USB autosuspend go file" to confirm the exact syntax. 2. If disconnections continue, try a USB 2.0 port. Slower but USB 2.0 ports tend to have less aggressive power management behavior than USB 3.0 on many motherboards. The Crucial SSD should also be more reliable than the spinning portable drive regardless -- no spinning platters means no head park/unpark cycle issues and generally more stable USB behavior.

The greyed out POOL button with the array stopped is likely why it's not responding. Try starting the array first -- in maintenance mode is fine -- and then attempt the POOL button again on Dev 1 in Unassigned Devices. The array being started doesn't mean data is at risk here. The cache pool issue is separate from the array drives. If the POOL button is still greyed out after starting the array, post a screenshot of what you're seeing and it would be worth opening a dedicated thread for this specific issue to get more focused help.

Glad you're mostly back up. Don't start the array yet. 1. Click the POOL button next to Dev 1 in Unassigned Devices 2. Click Apply 3. The pool should return to mirrored state and resilver automatically 4. Once complete run a scrub on the cache pool to confirm integrity Double check you're assigning the correct drive before clicking Apply. Don't start the array until the pool looks correct.

This is purely a boot drive issue and fully recoverable. Use the Unraid USB Creator to create a fresh bootable drive on a new USB, selecting the current stable version (6.12.15 is fine -- you can update from within Unraid afterward). Then copy your config folder from your flashbackup to the new USB, replacing what the Creator put there. That's it. A few notes: -- Don't copy everything from the flashbackup, just the config folder -- The new drive will have a different GUID so you'll need to transfer your license. You get one self-service transfer per year via the Unraid Connect portal. -- Once back up, avoid USB 3.x ports for boot. -- While you're sourcing a replacement, check the Unraid Boot Devices Guide guide in the Boot Devices section of this forum. If in a hurry, get Innodisk DEUA1-64GI61BW1SC -- industrial grade, around $4, plug into a USB 2.0 port. Worth getting a couple while they're available at that price. eBay item number: 326046070546