Lolight

Good call on stocking up -- and thanks for confirming the $3 offer floor. That's useful for anyone still on the fence. At $3 per unit for industrial MLC there's essentially no reason to hesitate regardless of how many systems you currently run.

Interesting that USB 3.0 worked when USB 2.0 didn't -- that's the reverse of the usual pattern here. If it's a USB 3.0 drive running in a USB 3.0 port you've solved the immediate boot problem but may be creating a longer term one -- USB 3.0 drives in USB 3.0 ports run significantly hotter. You could run a quick test to isolate the problem. Grab a different USB 3.0 drive. Download a fresh copy of the Unraid trial and write it to this test drive. Shut down the Unraid server completely. Unplug the original Unraid flash drive. Plug the newly created test USB drive into the same USB 2.0 port that you were trying to use before. Power the server back on and see if it boots up successfully. When it boots up, you'll need to find its new IP address. If the server boots up successfully: this proves the motherboard, the USB 2.0 port, and the OS version are all working fine. It confirms the issue is specifically isolated to the original flash drive (likely a failing controller). If it fails to boot: the problem lies deeper within the motherboard's USB handling, BIOS settings, or the new OS kernel's interaction. When the test is done, simply shut down the server, unplug the test drive, and plug the original drive back in. The data is completely untouched on the hard drives, and everything will be right back where you started.

You're spot on for being suspicious -- the PSU is easily the most overlooked component in a system, right up until it causes trouble. It is always a smart idea to replace a very old PSU before it actually fails. When it finally dies, it doesn't always go quietly -- it can take your other components with it. That said, don't just rush out and grab the first bargain bin power supply you see. Quality matters a ton here. Definitely check out the PSU Tier lists before buying anything to make sure you're picking up something safe and reliable. Choose at least C-Tier or better. https://tuerie.github.io/psu-tier-list/ https://docs.google.com/spreadsheets/d/1akCHL7Vhzk_EhrpIGkz8zTEvYfLDcaSpZRB6Xt6JWkc/edit?gid=1719706335#gid=1719706335

Corsair PSU models use three different types of cables. As a general rule of thumb, you should always swap out all the cables and use the new ones that come with your new power supply even if of the same brand. You only can leave the existing cables in place if both your old PSU and your new PSU use the exact same cable generation (for example, replacing an old Corsair RM750x Type 4 with a new Corsair RM850x Type 4).

Not stubborn -- just prudent.

Update on the Innodisk 3ME USB flash drive on ebay. After appearing to sell out earlier yesterday the drive has been relisted. The seller has confirmed approximately 200 units remaining. At the current depletion pace -- accelerated by recent bulk orders -- this is the genuine final window. The last bulk order placed on July 22nd was for 171 unit. eBay item 327273841855 -- $3.99 per unit. For anyone who saw this thread and didn't act yet -- this is the last realistic opportunity.

That's a more precise framing from both of you and worth acknowledging. The probabilistic argument is fair -- unverified AI output is a real problem and the temptation to skip verification exists. That's a legitimate quality concern. But there's a difference between "AI output often has quality problems therefore disclose and verify" and "AI formatting is obvious therefore suspect." The first is a reasonable quality standard. The second is what's being applied here -- style as a proxy for quality rather than actual evaluation of the content. The disclosure at the end of my post was exactly what MowMdown is now describing as acceptable -- AI used for assistance, result revised and verified, transparently disclosed. If that's the standard then ReginaldBull should never have been turned away from the repo.

The translator distinction is fair as far as it goes. But AI assistance for non-native speakers isn't just translation -- it's helping someone express nuanced technical thinking in natural English rather than stilted literal output. Those are meaningfully different tools producing meaningfully different results. On laziness -- the relevant measure is whether the content is accurate, relevant and useful. How it was assembled is a process question not a quality question. Accurate and helpful content isn't lazy regardless of what tools assisted its production. The disclosure at the end of my post was transparency, not confession. That's exactly what ReginaldBull was arguing for in this thread -- and what got him turned away from the template repo in the first place.

A significant portion of this forum's members aren't native English speakers. Using AI to structure and clarify their thoughts before posting isn't gaming anything -- it's a communication tool that lets people with deep technical knowledge participate more effectively than their English fluency alone would allow. The question isn't whether AI was involved. It's whether the content is accurate, relevant and useful. Those are separable questions regardless of how the text was assembled. This response was formatted with AI assistance.

Syslog is the first indicator but only if you have persistent logging configured -- which most users don't. Honestly though -- it's pretty much impossible to know a boot drive is about to fail while it's still actively serving as one. By the time symptoms appear you're often already in trouble. The more practical approach is two-fold. First, check what you already have -- ChipGenius or Flash Drive Information Extractor will tell you what controller and NAND type is actually inside your current drive without disturbing it. That tells you a lot about what to expect long term. SanDisk being the exception since their controllers block identification tools entirely. If you want to actively test the drive you'd need to run H2testw on it -- full write and verify cycle that surfaces marginal NAND. Not practical for most people while it's the active boot device.

Exactly right on all counts -- you've worked through the logic correctly. The Innodisk drives are an excellent choice for a single boot drive setup. The same specifications that make them good for a mirror make them ideal as a single drive. A single Innodisk running Unraid will likely outlast everything else in the system. Buying an identical spare is exactly the right approach. On capacity -- yes, Unraid Flash Creator supports drives larger than 32GB now. 64GB is fine. But if you encounter any problems with formatting use Rufus first. Out of curiosity -- how did you confirm the Planar TLC on the SanDisk? Standard tools like ChipGenius or Flash Drive Info Extractor can't read SanDisk controller data since they lock out NAND identification. Wondering if you have a source for that specific model's internals.

Since you don't want to use fTPM, your license needs to remain on a USB drive. When you migrate to internal boot the two Innodisk drives handle the boot function -- but the license anchor stays on a separate USB drive that must remain permanently connected. So your actual configuration will be three USB drives total -- two Innodisk drives in the mirrored boot pool plus your existing USB drive repurposed as a dedicated license anchor. On hardware portability -- when you move to new hardware you'll need to bring all three USB drives along with your array and cache drives. The license travels with the dedicated USB license drive, not with the boot pool drives. Worth considering an alternative -- a discrete dTPM module for your motherboard's TPM header (if available) typically costs $10-20 and eliminates the third USB drive requirement entirely while avoiding the fTPM vulnerabilities the guide covers. If your motherboard has a physical TPM header this is worth looking at before committing to the three USB drive approach but your future migration would be restricted by the TPM header availability on the new machine. Now to your specific questions: The mirror continues operating on the surviving drive after a failure and Unraid notifies you. Be aware of a documented in an NVMe configuration bug in 7.3.1 where replacing the failed mirror member can leave a stale device entry requiring a terminal zpool detach command to clean up. Supposedly fixed by now. For port selection -- USB 2.0 ports for all three drives. USB 3.x drives in USB 3.x ports generate more heat. Use your motherboard's internal USB 2.0 headers with 9-pin adapter cables. On the partition structure -- the boot partition is ZFS not BTRFS. 8GB minimum -- sufficient for boot but it's up to you which size to select. The remainder becomes the data partition if you choose to use it. The Innodisk drives are the right choice for this application -- but make sure you account for the third drive in your planning before purchasing. One final note: the mirrored USB boot pool is the least utilized and tested configuration among all available Unraid boot options. Real world deployments are rare and documented cases even rarer. I've documented it in the guide based on JorgeB's confirmation that it's supported, but I don't use this configuration myself and can't speak from personal experience. Proceed with that context in mind and make sure you have solid backups of your config folder before attempting the migration. One more thought on the redundancy goal specifically -- it's worth stepping back and evaluating whether the additional complexity of this setup is justified for your situation. A mirrored boot pool protects against a single drive failure. But Unraid's config folder backup -- which you should be maintaining regardless of boot configuration -- already provides recovery from a complete boot drive failure in minutes. The question is whether the seamless failover of a mirror justifies three USB drives, the barely tested configuration complexity, and the migration process compared to simply maintaining a current config backup and keeping a spare USB drive on hand. For some use cases the mirror makes sense. For others the simpler answer is a quality boot drive with a current backup. Worth thinking through before committing

Fair question. The surplus origin isn't stated in the listing but it's inferable from several details. The drives carry LYTX DriveCam DVR-S70 custom branding -- LYTX is a commercial fleet dashcam company. Innodisk produces custom branded drives for OEM customers as a standard service. The drives arrive in individual anti-static bags which is Innodisk's factory new packaging. The iTracker output across tested units shows an erase count of 2 -- consistent with factory bench testing, not field deployment. The most likely scenario: LYTX transitioned to a different drive format for their DriveCam systems. The remaining inventory of custom branded Innodisk units had no further use to them and entered the secondary market through this eBay seller. The seller's other listings confirm the pattern -- they specialize in surplus industrial and laboratory equipment including Watlow process controllers, Laurel panel meters, and LabJack data acquisition hardware. This is an industrial surplus liquidation seller, not a consumer electronics reseller. None of this is stated explicitly in the listing -- it's assembled from the available evidence. But the combination of OEM branding, specific factory packaging, factory-baseline iTracker readings, and the seller's overall inventory profile makes the surplus origin the most coherent explanation by a significant margin.

Fair points all around -- let me address each one. Your second point is the most valid one. The vulnerability window is when you plug the drive into your Windows PC to run the Flash Creator -- that's when a BadUSB attack would execute, not on the Unraid server itself. That's a legitimate concern worth taking seriously. The reason I'm not worried about this specific listing is the iTracker testing. Eight drives from this listing were tested with Innodisk's proprietary monitoring tool which communicates through Innodisk's own vendor protocol. All eight returned factory-correct output. A controller running BadUSB firmware alongside Innodisk's proprietary monitoring protocol simultaneously would require reverse engineering that vendor interface entirely -- an enormous (!!!) engineering effort when anonymous $2 drives require none of that. iTracker is Innodisk's proprietary health monitoring utility -- not publicly downloadable, requires contacting Innodisk support directly with the drive's part number. https://www.innodisk.com/en/technology/itracker Happy to share my copy with you or anyone who wants to verify their own drives. Send me a PM. On the price -- this is surplus liquidation from LYTX, a commercial fleet dashcam company that transitioned to a different drive format. The same drive costs $120 or more at industrial distributors right now. Surplus liquidation pricing reflects what LYTX needed to clear inventory, not what the drives are worth.

The scenario you're describing -- a seller acquiring legitimate surplus drives and reprogramming the controllers with BadUSB firmware before resale. The SM3261 AB firmware can be updated using Silicon Motion's MPTool utilities. The tooling exists and 3,000 units is a scale where automated flashing rigs make it operationally feasible. So why am I not worried about this specific listing? Eight drives purchased from this listing were tested with Innodisk's proprietary iTracker utility -- the health monitoring tool that communicates with the SM3261 AB through Innodisk's own vendor protocol. All eight returned consistent factory-baseline output: 99.93% health, average erase count of 2, firmware version O0917v1, controller identified as SMI3261. A reprogrammed controller running BadUSB firmware would certainly not respond correctly to Innodisk's proprietary monitoring commands. Getting a drive to simultaneously implement BadUSB behavior AND correctly respond to Innodisk's vendor-specific health monitoring protocol would require significantly more sophisticated firmware development than standard BadUSB attacks involve. Eight units all returning consistent factory-correct iTracker output is proven evidence against firmware tampering. There's also the operational context -- Unraid is Linux running headless without an active terminal session in normal operation. BadUSB keyboard injection needs an active session to land in. The attack surface on a headless NAS is essentially nonexistent regardless. The concern is legitimate as a general principle. The iTracker evidence makes it super unlikely in this specific case.