Lolight

Worth noting -- syslog to flash is optional and off by default. In standard configuration the write activity is minimal. The bigger issue for modern consumer drives isn't write activity at all -- it's idle controller heat from NAND instability running continuously regardless of user I/O. A QLC drive generates that maintenance workload whether you're writing to it or not. Which is why drives fail in always on duty even on systems that change configuration rarely -- the failure mechanism is the NAND type rather than the usage pattern. The USB Flash section guide covers exactly this.

That 2012 drive is almost certainly large-node MLC -- exactly why it's still running perfectly. The NAND era is what determines reliability, not the form factor. Which is also why splitting boot and licensing across two devices doesn't really help -- neither function was stressing the original USB drive in the first place. Near-zero workload on one device is the same as near-zero workload split across two.

Good point on ASPM and USB suspend — that's a separate failure mode worth ruling out in BIOS independently of drive quality. The drive failing ambiguously rather than obviously can lead you down a very expensive rabbit hole. The Bar Plus at three years tracks — it's the least bad widely available option rather than a genuinely reliable choice for Unraid.

That would be great! 👍

Some additions and refinements worth considering: On power consumption -- the idle current draw is determined by the controller's workload rather than by system power management. A controller managing QLC NAND's 16 voltage states continuously draws more idle current than a controller managing stable large-node MLC regardless of what the USB bus or system does. The NAND type determines the controller's idle workload -- which determines the heat generated -- which determines the degradation timeline. On luck -- the variance between drives lasting weeks and drives lasting 10+ years isn't random. It's determined by NAND type and node geometry. The 10+ year drives are almost universally large-node MLC from the pre-2012 production era. The drives failing in weeks or months are overwhelmingly modern consumer drives with QLC or late-node TLC NAND. The outcomes are deterministic and verifiable rather than luck-dependent -- which matters because deterministic outcomes are addressable through hardware selection while random outcomes aren't. On brand quality -- the declining quality is universal across consumer brands rather than specific to lesser-known manufacturers. Samsung, Kingston, SanDisk -- all current consumer USB flash drives from major brands use NAND that makes them unsuitable for always-on boot duty. The relevant quality signal is NAND type and node geometry rather than brand reputation. On cooling -- USB drives have never had meaningful thermal management beyond metal casing. The thermal problem in modern drives isn't inadequate cooling of otherwise stable NAND -- it's that QLC and late-node TLC NAND generates continuous controller heat from instability-driven maintenance workload regardless of the drive's physical design. Better cooling of an inherently hot controller is less effective than selecting a controller with inherently low idle heat requirements. The USB Flash section guide covers the NAND hierarchy and ChipGenius verification methodology that makes the "can't keep a list" problem tractable -- chip-level verification remains valid regardless of model changes and counterfeiting.

The boot performance benefit amounts to a few seconds saved on a machine that rarely reboots — essentially irrelevant in practice. On this specific setup — Haswell without TPM 2.0 — internal boot keeps the USB drive required for licensing, so the result is two devices instead of one with no USB elimination.

I have to disagree with you on that. There's nothing inherently wrong with using specific consumer drives 24/7. A legacy, large node MLC NAND USB flash drive is a perfect fit for the 24/7 duty in Unraid. Stable NAND paired with a simple controller (nearly zero activity/heat) is what makes it so reliable. Granted, modern enterprise drives universally come with much more advanced controllers than legacy drives. However, this is driven by necessity rather than choice. Modern NAND flash is significantly less stable and requires more sophisticated error-correction algorithms to ensure reliability.

This is excellent news for your Unraid setup. This specific NAND is the polar opposite of the cheap QLC we were discussing. Yeah, CrystalDiskinfo is of no use. I was under the assumption that it does show the controller ID. Just tried on my drives - nothing. And good job finding the SMI manufacturer tool -- those are your best bet if nothing else works.

Check out the last section of the guide: https://forums.unraid.net/topic/196967-unraid-boot-device-guide-usb-and-nvme-hardware-selection/

Excellent persistence working through that — the mount point collision was genuinely non-obvious and not something the standard troubleshooting sequence would have surfaced directly. That's a Garuda Linux specific behaviour where the automounter assigns mount points in a way that can create path conflicts between multiple devices. The VID/PID confirmed the drive is exactly what it should be -- correct for Unraid boot duty. Everything that followed was Linux filesystem management rather than anything wrong with the drive itself. Glad it's working. Enjoy the new Unraid setup!

Good news — the VID/PID confirms this is exactly the right drive. Your drive's ID 0930:6545 matches the verified PNY Attache Optima Pro with Phison PS2231 controller and very likely to contain the exact same, hard to find 56nm Toshiba NAND (see the MLC-based consumer USB Flash Drives thread for specs). The mounting errors and partition manager findings point to a different problem than permissions — the drive has an existing partial Unraid partition structure from a previous write attempt that's confusing the system. The 3MiB unallocated region is the Unraid boot partition's reserved space and the filesystem the system is trying to mount isn't a standard Linux filesystem -- which explains every error you're seeing. The fix is to completely wipe the existing partition table before trying the USB Creator again. Run these commands in sequence -- replace sdX with your confirmed device identifier from lsblk first: lsblkConfirm the PNY drive's identifier, then: sudo wipefs -a /dev/sdX sudo sgdisk --zap-all /dev/sdX sudo partprobe /dev/sdXThe wipefs command removes all filesystem signatures. The sgdisk command destroys both MBR and GPT partition tables completely. Together they return the drive to a blank state that the USB Creator can write to cleanly. Unplug and replug the drive after running these commands, then attempt the USB Creator again before the system automounts anything. Garuda Linux uses KDE's device notifier aggressively — if it tries to automount between the wipe and the USB Creator attempt run: sudo systemctl stop udisks2Then run the USB Creator, then restart udisks2 afterward with: sudo systemctl start udisks2Let me know what the USB Creator produces after the full wipe.

Thank you — both answers are very helpful. On the license drive point -- just to confirm the practical implication. Once the boot pool is established and the license file is copied to it, can the original USB flash drive be physically removed permanently? Or does it need to remain present for ongoing license validation even though it's not mounted? If the USB drive can be removed after initial setup that changes the configuration picture significantly -- USB licensing users would achieve complete USB elimination through the mirrored boot pool without needing TPM, which wasn't previously understood to be possible.

The X400 256GB has a fixed bill of materials with no production variance — Marvell 88SS1074 controller, DRAM cache, and SanDisk's own 15nm planar TLC NAND consistently across all documented units. The consistent BOM is a genuine advantage over the Kingston A400's lottery situation. The one limitation worth knowing is that 15nm planar TLC is older technology — 80 TBW endurance for 256GB is modest. For typical AppData and Docker cache duties that aren't heavily write-intensive it's adequate. So ranking your variants: The Samsung 870 EVO 1TB is the strongest option by a meaningful margin — Samsung 128-layer 3D TLC, 1GB DRAM cache, 600 TBW endurance, five-year warranty, fixed BOM with no variance across production runs. It sits at the top of the SATA SSD reliability hierarchy. No redundancy on known excellent hardware is a better starting position than redundancy on hardware of unknown or older quality. The SanDisk X400 256GB pair is a viable redundancy option — consistent and predictable, DRAM cache present, adequate endurance for the workload. Older planar TLC but not disqualifying for cache pool duty. The Kingston A400 pair is the unknown — run CrystalDiskInfo on both drives first. If the controller comes back as Silicon Motion SM2259XT they're reasonable cache candidates. If Phison PS3111-S11 appears the X400 pair is the stronger redundancy choice. The CrystalDiskInfo result on the A400s determines which path makes the most sense for your specific situation.

Good that you've settled on USB boot — the right call given the TPM situation. On your question — yes, exactly. You can install the SSDs physically and Unraid will see them in the interface but they won't participate in anything until you explicitly assign them to a pool. Unraid never touches unassigned devices without deliberate user action. They'll just sit there visible but inactive until you're ready. On the Kingston A400 480GB drives — worth a specific note before assigning them to cache pool duty. The A400 series is one of the more documented examples of NAND lottery variance in the budget SSD market. Kingston markets all variants as "3D NAND TLC" but the actual components vary significantly across production runs without any external indication of which variant you have. The specific variants documented for the 480GB model include a Phison PS3111-S11 controller with Toshiba 15nm planar TLC — not true 3D NAND despite the marketing — which appears in units from approximately 2017-2018. Later variants use Silicon Motion controllers with Micron or YMTC 3D TLC. Some BOM analyses document QLC variants in certain revisions. All carry the same model number, the same box, and the same rated specifications. The Phison PS3111-S11 variants have a specific documented failure mode — "SATAFIRM S11" firmware panics where the drive becomes inaccessible until power cycle or worse. For cache pool duty holding AppData and Docker configurations that failure mode is worth knowing about before committing the drives. Since your drives came from a box purchased a few years ago the planar TLC Phison variant is a realistic possibility rather than an edge case. Before assigning them to the cache pool run CrystalDiskInfo on both drives — it should show the controller identifier. Phison PS3111-S11 in the output means the older potentially planar TLC variant. Silicon Motion SM2259XT or SM2259XT2 means a more modern controller with higher probability of genuine 3D NAND. If CrystalDiskInfo shows the Phison S11 controller it's worth researching that specific unit's NAND before committing it to always-on cache duty. If it shows SMI the picture is considerably better — though NAND type verification through HWiNFO or physical inspection remains the definitive answer. Happy to help interpret the CrystalDiskInfo output when you have it.

The idProduct string showing multiple OEM names is noted — but to confirm this matches the verified unit we need the VID and PID values from the lsusb output. Can you share the full lsusb line for the PNY entry — it should show something like: Bus 00X Device 00X: ID xxxx:xxxx Kingston...The four digit values after "ID" are the VID and PID. For the verified unit those should be VID 0930 and PID 6545. If they match we can confirm the controller. If they differ it's worth knowing before proceeding further. On the formatting error — since the commands executed successfully but the USB Creator still fails the issue is almost certainly a permissions conflict between the USB Creator's process and udisks2. Try this sequence: First confirm your device identifier — run: lsblkIdentify the PNY drive's device identifier in the output before proceeding. Verify carefully — the next commands are destructive and writing to the wrong device causes irreversible data loss. Then with the correct identifier confirmed completely close the USB Creator application and run: sudo umount /dev/sdX sudo dd if=/dev/zero of=/dev/sdX bs=4M count=10 status=progress sudo partprobe /dev/sdXReplace sdX with your actual device identifier from the lsblk output. Then reopen the USB Creator immediately and attempt the write before the system automounts the drive again. If that still fails try running the USB Creator with elevated permissions: sudo unraid-usb-creatorOr whatever the specific executable name is for your distribution. The underlying issue is the USB Creator and udisks2 competing for device control — running the Creator with sudo gives it priority over the daemon. If neither works let me know your Linux distribution and desktop environment — some distributions have specific udisks2 permission configurations that require an additional step.

@JorgeB One more clarification if you don't mind — two questions: Does the onboarding wizard present USB flash drives as selectable boot pool devices in its interface, or does creating a USB mirrored boot pool require manual configuration outside the wizard? And on the license drive — in the mirrored boot pool configuration where the license USB drive serves purely as a license holder with no boot function, is there a minimum size requirement for that drive? The key file itself is kilobytes in size so theoretically any recognized USB device should work — but whether the licensing system has its own minimum size requirement independent of the boot drive requirements isn't documented anywhere I can find.

Thanks to @JorgeB confirmations above this is worth highlighting for anyone currently evaluating their boot options. A mirrored boot pool from two USB flash drives or industrial DOMs is confirmed supported in 7.3 -- USB devices work in boot pools, tested by JorgeB. The configuration is: Two USB flash drives or DOMs forming the mirrored ZFS boot pool -- providing redundancy against single drive failure. The existing USB license drive remaining in place as the license holder -- or TPM if available. One important constraint JorgeB flagged -- boot pool devices need to be 16GB minimum. The 16GB minimum restriction applies specifically to boot pool member devices — because those devices get the 50% partition rule applied to them during boot pool setup. The license drive bypasses that entire partition process entirely. This addresses the single-point-of-failure concern without requiring internal drive slots, TPM hardware, SATA or M.2 ports. For users with internal USB headers: two industrial USB DOMs of 16GB or larger or USB drives mounted internally via inexpensive 9-pin to USB-A adapters in the boot pool mirror plus the existing license drive on an external port or internal adapter is a particularly clean configuration -- redundant boot, no internal slots consumed, full hardware agnosticism preserved. The 16GB minimum means NAND type verification matters for the boot pool drives -- the same NAND quality considerations that apply to internal NVMe selection apply here. Verified 3D TLC or better from a reputable manufacturer at 16GB or above is the target. The USB Flash section guide covers NAND type identification and verification. This configuration wasn't mentioned in the promotional materials or tutorial videos. The USB Flash section guide will be updated to include it as a confirmed supported configuration.

The USB_TRANSPORT exclusion appears in dconklin's bug report from this thread -- posted Thursday at 7:39 PM. His onboarding wizard showed it as a disk check failure reason. Good to know it was a development-stage consideration that didn't make it to release. This confirmation changes the practical picture significantly. A mirrored boot pool from two quality USB flash drives or industrial DOMs -- with the existing license USB drive remaining in place -- addresses the single-point-of-failure concern for the broadest possible user base without requiring internal slots, TPM hardware, or NAND quality decisions beyond the existing USB guidance. Given that this wasn't mentioned in the promotional materials or tutorial videos it's likely totally unknown to most users currently evaluating their boot options. Worth prominent documentation -- it's the most accessible redundant boot configuration available and it works with hardware most Unraid users already have.

Thank you — just want to make sure I'm understanding this correctly before sharing it more widely. The configuration you're describing would be: Two USB flash drives or DOMs forming the mirrored boot pool — providing redundancy. A separate third USB drive holding the licence key as before — or TPM if available. Is that correct? And the USB_TRANSPORT exclusion that appeared in the onboarding wizard's disk checks — does that apply specifically to the currently active boot device being reassigned, rather than to USB devices generally as boot pool members? If the three-device USB mirrored configuration is confirmed it seems worth prominent documentation — it addresses the single-point-of-failure concern for users without available internal slots or TPM hardware.

Good questions — happy to clarify. On TPM -- Unraid 7.3's TPM licensing requires TPM 2.0 specifically. TPM 1.2 isn't supported. Haswell boards vary on whether their headers support 2.0 or only 1.2 -- worth checking your motherboard manual before buying a module. Given your motherboard generation USB boot with USB licensing is almost certainly the simpler and more reliable path anyway -- probably not necessary to pursue TPM at all. On docker and apps — nothing installs on the USB drive. Unraid loads into RAM at boot and the USB drive just holds the OS files, config, and license key. Docker images and all appdata live on your array or preferably cache pool drives. A 4GB drive is genuinely sufficient, 8-16GB gives comfortable headroom. Don't let sizing concerns push you toward a large modern drive — smaller older drives from reputable brands are actually preferable for the reasons the USB flash drive guide covers. On the box of SSDs — for your case these are most useful as cache pool drives rather than boot devices. USB boot on a quality drive remains your simplest and most reliable path given the TPM situation. When you dig out the box post the specific models here — depending on their age and NAND type they could be excellent cache pool candidates, which is exactly where SSD performance actually matters for Unraid's architecture.

A couple of clarifications on the boot partition — it is ZFS as @Niklas noted, confirmed officially in the 7.3 release notes and by the Unraid team directly. On mirroring — ZFS software mirroring operates entirely at the OS level and doesn't require BIOS RAID support. That's one of ZFS's primary architectural advantages. Two drives in a ZFS mirror are managed by the ZFS layer without any BIOS involvement. The specific question I've asked @JorgeB above is whether USB-connected devices — USB DOMs on internal headers specifically — are supported in the ZFS boot pool mirror, or whether the USB_TRANSPORT exclusion documented in the onboarding wizard applies to boot pool membership generally. That distinction matters for users evaluating industrial USB DOM hardware as a boot option.

@JorgeB A question on boot pool mirroring that came up in the Reddit beta thread worth clarifying here — specifically because the original question and answer were ambiguous in a way that matters. In the Reddit r/unRAID 7.3 beta thread approximately 3 days ago: Known_Palpitation805 asked: "Will we get boot drive mirroring if we use a multi DOM setup or is it restricted to SSDs etc?" UnraidOfficial replied: "Yes." The ambiguity is in the word "DOM" — which could mean two completely different things with different implications for boot pool support: USB DOM — an industrial flash device connecting via USB protocol through an internal motherboard USB header. Subject to what the onboarding wizard identifies as USB_TRANSPORT exclusion — dconklin's bug report from this thread documented "USB_TRANSPORT: This disk is connected over USB, which is not allowed for internal boot" as a specific disk check failure. SATA DOM — an industrial flash device connecting via SATA interface. Treated identically to any SATA SSD from Unraid's perspective with no USB exclusion applicable. Two specific questions: Does the USB_TRANSPORT exclusion apply to boot pool membership generally — meaning USB DOMs on internal headers cannot be used in a mirrored boot pool regardless of their industrial-grade NAND quality? If USB DOMs are excluded, can standard USB flash drives be mirrored through any mechanism in 7.3 — or is boot pool mirroring restricted exclusively to SATA and NVMe devices? The reason this matters practically — USB DOMs on internal headers represent the optimal boot device hardware for always-on Unraid duty based on NAND type and thermal characteristics. If they're excluded from boot pool mirroring by the USB_TRANSPORT restriction, that's worth documenting clearly so users evaluating their boot device options understand the constraint. If they're supported, that's equally worth documenting as it represents an accessible high-quality mirrored boot configuration without consuming SATA or M.2 slots.

For filtering lsusb to just the PNY drive try: lsusb -v -d 0930:6545That targets exactly the VID:PID of the verified unit. If it returns nothing the drive may have different identifiers — let me know what lsusb shows for the PNY entry and we can work from there. On the udisks2 formatting error — this is a Linux-specific issue unrelated to the drive itself. Most likely cause is the drive being mounted or having existing partition signatures. Try this sequence: udisksctl unmount -b /dev/sdX udisksctl power-off -b /dev/sdXUnplug the drive physically, replug it, then retry the USB Creator. If it still fails run: sudo wipefs -a /dev/sdXTo clear all existing filesystem signatures before attempting again. Replace sdX with your actual device identifier from lsblk. Let me know what the lsusb output shows and whether the formatting error persists after these steps.

Welcome to Unraid — good questions for a first build. One thing worth clarifying before committing to internal boot on your setup. Your 4th Gen Haswell board almost certainly doesn't have TPM 2.0 support — which means internal boot would keep the USB drive required for licensing anyway. You'd have two boot-related devices instead of one, adding complexity without the USB elimination benefit that makes internal boot most compelling. For a first build that tradeoff is worth thinking through. On using the remaining SSD space as a cache pool — the specific models of those older SATA SSDs matter more than their capacity for this decision. Consumer SSDs from different eras contain very different NAND types, and in always-on 24/7 server duty the NAND type determines long-term reliability more than brand or capacity does. An older SSD that's been sitting in a drawer unused could be excellent or problematic depending on what's inside it. Before committing any drive to combined boot plus cache duty it's worth identifying the specific model and checking its NAND type. The USB Flash section of this forum has a guide that covers exactly this — recently extended to include SATA SSD and NVMe selection for internal boot alongside the USB drive guidance. The NAND hierarchy and what to look for applies directly to your decision. For a first build the simplest reliable architecture is often a quality USB drive for boot and your matched SSDs dedicated entirely to cache pool — no partition complexity, full cache capacity available, hardware agnosticism preserved for the inevitable "I need to move this to different hardware" moment that every Unraid user eventually faces. What are the specific models of those older SATA SSDs? That would help narrow down whether combined boot plus cache is sensible for your situation.

The pinned comment is genuinely appreciated — the restore testing recommendation and Docker permission warning are exactly what users depending on that setup need to know. Thank you for following through! On hardware guidance — the 7.3 release notes state that "manufacturers have quietly shifted to cheaper NAND, endurance ratings have dropped." That's the correct USB failure diagnosis. The same variable now applies to internal boot device selection — a budget QLC NVMe in always-on boot plus cache duty fails for the same reason, with the added consequence of losing OS config and cached data simultaneously. The guidance needs to reach users before purchasing decisions are made — on product pages and in pinned community resources — not after hardware is already installed. Is NVMe hardware selection guidance part of what's on deck, and is there any possibility of it landing before the stable release rather than after the main adoption wave builds?