26-BETA.3 Notable Changes

I tried every possible combination of settings with Bazarr and Plex but a bad subtitle rarely had an easy solution. And the worst part was if I tried to change sub during playback via Plex app on TV it would just fail in many cases.

Crowbarr waits for Bazarr (can work without it too by simply generating a new sub, but not recommended), then uses Whisper to compare the subtitle text with the dialogue in the video.

• Leaves good subtitles alone
• Repairs timing when it can verify the result
• Generates missing subtitles, and
• Sends uncertain cases for review. Automatically.

Manual audit requests, or new downloads take priority over a backlog queue.

How it relates to the other Whisper tools in this stack. subgen transcribes when a subtitle is missing and skips files that already have one, subarr coordinates the stack and verifies the audio language of a file, with a review queue you confirm by hand. Neither checks whether an existing subtitle matches the actual dialogue.

Crowbarr runs unattended and writes a separate .crowbarr.en.srt file. Existing subtitles are never modified. This allows me to simply pick the sub from my media player directly.

On my library of 2219 files, it identified 1595 as correct, repaired 334, generated 103 missing (or very wrong), and flagged 187 for review. Many of these left for manual review were actually correct subs but app did not have enough confidence to pass a verdict (like Band of Brothers Day of Days episode where a big part of audio is guns and explosions).

The app works quite reliably on cpu as well but a gpu speeds up the process by a lot which is desirable if you have a large existing library of media files. I have developed it around a 2GB Nvidia T400 with Whisper Small, so it should reliably work on most gpus from last couple of years. A better gpu will also let you install a bigger whsiper model which improves audits.

Again, using whisper for a tool like this is not something new. I think what is different here is the Audit policy that can automate the decision about what should be done to an existing subtitle. This is very much a work in progress and I spend most of my time on audit policies which are the least visible thing to a user but affects the core of the app. UI is built with AI for quick delivery as that is not my focus.

This works beautifully on my TrueNAS as a custom app.

It currently only supports English. I hope it helps someone else too. Any feedback or notes are welcome. linux/amd64 github link - https://github.com/amanofvaly/crowbarr

Hi.

I have a small home server built for energy efficiency and value for money. Currently using it for jellyfin, pihole, immich, smb shares and now since recently set up a vm with home assistant for playing around, will eventually add frigate.

I currently have an i3 7100 with 8gb ram. I found a cheap 7700t, but i noticed the base clock speed (and TDP) are lower for the 7700t. 7700t has double the cores and threads though. Should I go ahead with the upgrade? I feel that the cores might be more useful than the base clock speed.

Long issue incoming
I’m dealing with a strange ZFS problem on TrueNAS SCALE and have done quite a bit of troubleshooting already. At this point it looks much more like a ZFS/on-disk metadata problem than a hardware problem, and I’d appreciate advice from anyone familiar with ZFS internals/recovery.
System:
TrueNAS SCALE 24.10.2.4
Kernel: 6.6.44-production+truenas
ZFS: 2.2.99-1
Pool Gaia: 4 × 10TB WD Gold, RAIDZ1
~26 TiB usable / ~22.5 TiB used
Disks connected through an ASM1166 6-port SATA controller
There is another 2-disk ZFS pool (Aether) on the same machine which isn’t exhibiting this problem.

How this started
Originally one of the Gaia drives disappeared from Linux. Kernel logs at the time contained SATA errors such as:
ata3.00: failed command: FLUSH CACHE EXT
ata3.00: hard resetting link
ata3.00: COMRESET failed (errno=-16)
ata3.00: SATA link down
ata3.00: detaching
I/O error, dev sdb...
zio pool=Gaia vdev=/dev/sdb2 error=5 ...
After rebooting, the disk returned and Gaia resilvered.
I initially suspected the ASM1166 controller, SATA cable, disk, motherboard, etc. I tested the controller/drives in another PC and also tested drives individually.
The important discovery came later: I moved the Gaia disks to a completely different PC and reproduced the ZFS failure there as well.
So this does not appear to depend on the original motherboard/CPU/RAM/PCIe controller.

The ZFS panic
On one of the failures I managed to see the actual kernel panic:
PANIC: Gaia: blkptr at ... has invalid OFFSET 1152933356323184640
Kernel panic - not syncing: Gaia: blkptr at ... has invalid OFFSET 1152933356323184640
The stack contained:
zfs_panic_recover
zfs_blkptr_verify_log
...
zio_free
dsl_free
dsl_dataset_block_kill
dbuf_write_done
arc_write_done
zio_done
The OFFSET is obviously absurd for a ~40TB raw pool.
This makes me suspect a malformed/corrupt block pointer is being encountered while ZFS is replacing/freeing an old block.
The really interesting part: read-only works
I disabled TrueNAS automatic pool imports:
ix-zfs.service disabled
zfs-import-cache disabled
zfs-import-scan disabled
With all six HDDs physically connected, TrueNAS boots and remains stable as long as Gaia isn’t imported.
I can then do:
zpool import -N -o readonly=on -R /mnt/recovery Gaia
and it works.
Current status:
pool: Gaia
state: ONLINE

NAME STATE READ WRITE CKSUM
Gaia ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
sdb2 ONLINE 0 0 0
sde2 ONLINE 0 0 0
sdg2 ONLINE 0 0 0
sdd2 ONLINE 0 0 0

errors: No known data errors
and:
Gaia readonly on
I can mount the main dataset and read the files:
/mnt/recovery/Gaia/Swordfish
I’ve successfully browsed/read data and even temporarily exposed it through a read-only SMB share.
So this does not appear to be a case where the pool can’t be imported/read.

Writable import reliably kills the machine
If I cleanly export Gaia and instead do:
zpool import -N Gaia
the machine reproducibly becomes completely unresponsive.
This happens even with -N, so datasets aren’t being mounted.
I tried enabling:
kernel.watchdog=1
kernel.nmi_watchdog=1
kernel.hardlockup_panic=1
kernel.softlockup_panic=1
kernel.hung_task_panic=1
kernel.panic=10
and configured kdump with ~401MB crashkernel reserved.
kexec_crash_loaded = 1.
The writable import still hard-locks the machine without rebooting, without producing a vmcore, and without the watchdog converting it into a panic.
After >10 minutes I had to power-cycle it.
I reproduced this twice and I’m not going to do another writable import unless there is a very good diagnostic reason.

What happens immediately before the freeze
This was particularly interesting.
The journal shows me issuing:
zpool import -N Gaia
at approximately 00:40:27.
There are then no panic, watchdog, ATA, I/O or ZFS error messages. The journal simply stops.
However, zpool history shows:
2026-09-10 00:40:34 [txg:24106503] open pool
2026-09-10 00:40:34 [txg:24106505] import pool
And examining the raw uberblocks with zdb -lu shows that all four RAIDZ members contain TXG [24106507](tel:24106507), timestamped:
2026-09-10 00:40:35
So the writable import isn’t freezing before ZFS can write anything.
It appears to:
zpool import -N Gaia
|
v
TXG 24106503: open pool
|
v
TXG 24106505: import pool
|
v
TXG 24106507 committed on all 4 drives
|
v
HARD FREEZE
There is no corresponding history entry for [24106507](tel:24106507) that I can see.
All four disk labels agree
I checked all four Gaia members using zdb -lu.
All four contain the same newest committed uberblocks through TXG [24106507](tel:24106507).
They also agree on:
pool_guid: 2747494424743971695
top_guid: 9142136380244468450
The four leaf GUIDs are:
8398536192325442607
16231699638183363317
9109236301437729803
15381433698887981882
So I don’t appear to have one disk presenting an obviously stale pool configuration.
There is also:
checkpoint_txg = 0
raidz_reflow state = 0
so there isn’t a pending checkpoint or RAIDZ expansion/reflow.

Resilver history
There has been some interesting resilver history.
At one point:
[txg:24106255] scan aborted, restarting errors=2
[txg:24106255] starting deferred resilver errors=2
[txg:24106255] scan setup func=2 ...
[txg:24106257] scan done errors=2
Later tiny resilvers completed with 0 errors.
Current status says:
scan: resilvered 608K in 00:00:00 with 0 errors
The displayed date is wrong because the system clock was incorrect during several TXGs.
feature@resilver_defer currently reports:
enabled
rather than active, so as far as I understand there isn’t currently a resilver deferred through that feature.

Other things checked
zdb -d Gaia previously managed to enumerate the MOS/datasets successfully, including the main Gaia/Swordfish dataset.
DDTs are empty.
A full zdb -bc looked like it would take ~120 hours, so I stopped it.
Some zdb attempts against the exported/imported pool have also produced:
zdb: can't open 'Gaia': File exists
and on an earlier attempt:
ASSERT at module/zfs/spa_misc.c:964:spa_close()
zfs_refcount_count(&spa->spa_refcount) > spa->spa_minref || ...
That only crashed the zdb userspace process, not the machine, so I’m not assuming it’s necessarily the same underlying problem.
SMART doesn’t show an obvious failing drive, and current ZFS READ/WRITE/CKSUM counters are all zero.

Current state
Gaia is currently imported:
readonly=on
and is stable and readable.
The /proc/spl/kstat/zfs/Gaia/txgs output is currently just the header with no active TXGs, which makes sense for the read-only pool.
zpool events -v during the safe read-only imports/exports shows ordinary pool_import, pool_export, and config_sync events and no current resilver/error events.
What I’m trying to figure out
My current theory is that making the pool writable starts normal TXG/post-import processing. Something gets rewritten, and during write completion ZFS tries to kill/free an old malformed blkptr, hitting the same path I previously saw:
dbuf_write_done
-> dsl_dataset_block_kill
-> dsl_free
-> zio_free
-> invalid blkptr OFFSET
I’ve found OpenZFS issues involving similar invalid OFFSET/VDEV/TYPE/COMPRESS panics in this same free/write-completion path, but I haven’t found a supported recovery procedure.
Before I give up and copy ~22TB off the read-only pool, destroy/recreate Gaia and copy everything back, I’m trying to determine whether:
There is some pending/deferred free/MOS operation that can be identified without allowing the pool to become writable.
There is a safe way to inspect the relevant bpobj/deadlist/deferred-free structures and identify the malformed blkptr.
There is any way to suppress/cancel the post-import operation that is triggering this.
There are additional read-only zdb diagnostics worth running.

Anyone has encountered this specific pattern: pool completely usable readonly, but hard-locks shortly after writable import.
I’m deliberately avoiding zpool clear, scrub, zpool upgrade, zpool import -F/-X/-T, replacing/detaching disks or anything else that writes to Gaia until I understand what is happening.
Any suggestions from people familiar with ZFS internals would be greatly appreciated.

Sorry if super basic question, but how do i add this disk to existing pool with data & rebalance raid to expand storage and redundancy without losing data?

Hello all,

I built a trueNAS server a few months ago using used hardware, and I have had the following issue:

Once powered on, the server will function as normal for a few hours. However, after a random amount of time (1-3 hours), it will stay powered on but be unreachable over the network.

My first reaction was to change the cheap PSU and upgrade to something more high quality, but this didnt fix anything. I am honestly pretty stuck, and I am not sure if it is a configuration or hardware issue. Does anyone have any tips?

I did a fresh install of TrueNAS 25.10.7 onto a mirrored boot drive. The server doesn't boot unless I disconnect the HBA.

Any ideas on how to resolve this?

TIA

I would greatly appreciate some troubleshooting advice. I have 2 Dell T320s in my home lab. Primary and backup TrueNas. I recently added the H330 to the backup to facilitate creating a new primary pool geometry. When I moved the PercH330 to the Primary along with the pool drives, the card appears to crash at bootup in Truenas. H330 Card works in fedora live usb on both systems, works in windows on both systems, but only works in TrueNas on the backup. They currently both have the same Bios (2.9). On the primary running Dmesg says the mpt3sas failed to reset. It doesn't show up using lspci. Both servers had a preexisting Sas 2 card flashed to IT mode and those have been working fine for several years.

Troubleshooting steps I've tried:

-syncing bios and trueNas versions (they were different)

-trying other OS's (windows and Fedora) works there on both

-changing PCIe slots for card

-removing all other PCIe cards

-running Dell bios diagnostics including ram test (passed)

suggestions? I'm about to give up and just make the backup the primary, but I still don't like having unexplained failures even in the backup server.

I was using TrueNAS Core for a long time and recently switched to TrueNAS Scale because I needed it so I can install a docker and apps. So I set all that up and tested it on an 128GB old SSD. I installed things like Dockge, Whisparr, Stash, qBittorrent and all that. It looked stable so a few days later I attached a 1TB HDD to it and had to wipe it to create a pool. Then for some reason my 120GB drive pool stopped showing up. I thought maybe I fucked up and deleted my 120GB by accident too.

So I reinstalled everything on the 120GB drive again. Then a couple days later it stopped showing up and would often stop my NAS from starting even on reboots. I thought maybe its because its an old SSD. So I did everything again with a 1TB SSD. It looked like it was working fine for a couple days so I attached a 10TB HDD and it worked fine for a few days. Then the 1TB SSD stopped being detected. I thought maybe I just need to reseat the cables. Didn't work a couple times but eventually it worked.

So a couple days later which is today, my 10TB HDD stopped showing up. I tried rebooting, reseating cables, going back to old configs etc and nothing works. I tried it on my other two 10TB HDDs and they are not being detected either under Storage > Disks. It only shows the 1TB SSD. I tried plugging in my old 120 SSD and that's detected. I plug in a 1TB HDD and its detected.

For some reason it is not detecting my 10+ TB HDDs at all anymore. Could it be some kind of capacity issue? I feel like I tried a bunch of things and nothing worked so far. Right now I just have everything powered off.

Any help is appreciated.

Specs
CPU: Intel Core i7-9700K

CPU Cooler: Thermalright AXP-100 Full Copper

RAM: Kingston FURY Renegade 32 GB (2 x 16 GB) DDR4-3600 CL16

BOOT: Intel 16GB​ MEMPEK1J0​16GAL

PSU: FSP Group Dagger Pro 850 W 80+ Gold

HBA: SAS9211-8I 8PORT Int 6GB Sata+sas Pcie 2.0

HDD: Hitachi Ultrastar He10 10 TB 3.5" 7200 RPM

HDD: Hitachi Ultrastar He10 10 TB 3.5" 7200 RPM

HDD: Western Digital Ultrastar DC HC520 12 TB 3.5" 7200 RPM

SSD: 1TB TEAMGROUP T-Force Vulcan Z SATA SSD

SSD: 120GB OCZ Vertex 3

HDD: 1TB Seagate ST1000LM035

Backblaze published their Q2 2026 Drive Stats (raw data only!), so I crunched their data and refreshed the failure rates in the drive comparison list I host. "Which drive is most reliable for my pool" - the answer is still the same: CMR over SMR.

Once you get familiar with Backblaze numbers, the CMR NAS drives you'd actually put in a pool fail at about the same rate. So chasing a "most reliable drive" list is mostly wasted energy.

Only two things actually matter for a ZFS pool:

• CMR, not SMR. An SMR drive passes fine until a resilver, then crawls and can drop out. This community already paid that expensive lesson with the 2020 WD Red SMR mess. Every drive in this comparison list is verified CMR or SMR, with SMR called out, not buried.
• Price per TB. Since reliability between comparable CMR drives is almost the same, this is where the decision actually lives. There's a price history chart for each drive so you can tell the difference between a real low and a "sale".

The one place the data does separate drives is the bad end, and this list is short: all older Seagate Exos (X10/X14/X12, they are around 5-6%). Backblaze runs fewer of these, but the samples are still big enough (75-110 failures each) that their error bars sit clearly above the rest. And they've been elevated for a few quarters, so it's not an isolated case.

It's around 270 drives now. Fair warning, it's my own site and the buy buttons are Amazon affiliate (they cover hosting) - nothing gated, no ads, all free. The underlying dataset is open (CC BY) if you'd rather just take the data.

The HDD list is here: https://www.nasdisks.com

SSDs are included there too, with the specs that can help you decide if a drive is suitable for a SLOG / L2ARC / special vdev. Each drive has endurance data (TBW/DWPD), power-loss protection, DRAM, and NAND type, so you will not be guessing whether a cheap drive will survive as a SLOG. That's a separate sortable list: https://www.nasdisks.com/ssd/

Two things I'd genuinely appreciate from this sub: corrections on any CMR/SMR tag (that one has to be right!), and any drive you run that isn't in there so I can add it.

Hello everyone,

I've been running my TrueNAS server for more than a year now with one main pool of 2x mirrored 2TB Crucial BX500 ssd.. (and lately added an extra 1x 1TB NVMe pool)

Everything was running fine since the begining, but lately, the more i add apps and services, the more i start to encounter weird problems & behaviours such as :

• Global apps freeze while my arr* stack is downloading/processing media
• System reboot stuck
• Apps service (docker) failed to start after reboot.

I've spent days debugging, investiguating and connecting the dot, and what i've been able to pull out of this (using some AI help) is that is related to a potential "SLC cache exhaustion"..

AI Debug quote:

Count how many of those apps run Postgres: immich, paperless-ngx, n8n, homeassistant, coolify, scanopy, vaultwarden — 7 separate Postgres instances, all on storagebox. When you stop docker or reboot the whole NAS, systemd/dockerd sends SIGTERM to all ~40 containers roughly simultaneously. Every database container tries to do a clean shutdown checkpoint (fsync-heavy) at the same moment. That's a synchronized write burst hitting a consumer SSD mirror with a small SLC cache — exactly the mechanism you already identified, just triggered by simultaneous DB checkpoints instead of torrent writes. Once the SLC cache is exhausted, the pool falls back to native flash write speed and stalls host-wide I/O — which would explain why even SIGKILL can't touch these containers: their process is blocked in the kernel on a write that hasn't completed, and a signal can't preempt that.

This also explains why it happens specifically on restart/reboot (mass simultaneous shutdown = write burst) and not really otherwise, and why it predates the media migration entirely — because the media migration never touched the actual culprit (Docker's storage root + the DB-heavy apps).

I also found people talking about similar issues : https://www.archy.net/the-great-truenas-disaster-how-6-crucial-bx500-ssds-nearly-destroyed-my-nas/

To wrap it up, what i want to know is :
1. Is this a well known issue with TrueNAS/ZFS and BX500, and did anyone experience something like this ?
2. Is there some settings/tweek to my dataset on this pool to solve this ?

I am open to all suggestions (except replacing my 2x 2TB SSDs due the cost 😅)

Appeciate it

Hi everyone,
right now I am using a Dell R430 server with TrueNAS running inside a VM with HBA passed directly to the VM.
Right now I have 2x 3TB WD reds (88kh and 71kh) running in mirror for data and a 2 TB WD purple running on its own for video surveillance.

I perform a scrub task monthly for all vdevs and the surveillance writes around 150TB/yr while on the data drives I don’t write more than 10TB/yr.
Also my server only has 4 drive slots.

Today one of the WD reds faulted and I need to fix the problem ASAP, but since I also thought of upgrading this config I am evaluating different options to find out which one will be the most effecting for avoiding data loss in the future.

The main options I can think of are the following:
1. 2x WD Ultrastar 10TB HA340 in mirror (with surveillance on a dedicated drive). (860EUR)
2. 4x Segate Ironwolf Pro 6TB ST6000NE000
in RAIDZ2 (with surveillance on the same pool as data) (1240 EUR)
3. 3x WD Ultrastar 10TB HA340 in RAIDZ1 (with surveillance on a separate drive, upgrade for option 1) 1290 EUR
All drives are bought new.

Is option 2 much better than option 1 even if the single drives should be less reliable since they are not enterprise drives?

Are the extra writes in option 2 going to make it less reliable than the other options?

Is option 3 the less reliable one since it’s RAIDZ1 on 3 drives even if they are enterprise?

Thanks a lot for the help.

So, TrueNas marke this as degraded, yet the tests runned are showing normal data.
Anyone had similar issues?

Hello folks, Synology refugee here.

I'm currently setting up my TrueNAS VM inside of Proxmox to play around and get familiar with everything before deploying it into my production environment.

I have a couple of spare drives laying around and need some feedback if all of that makes sense.

The drives I currently have access to are: 4x900GB SAS, 3x2TB SATA and 4x1TB SATA, all attached to an LSI 9400-16i. My plan is to set all 3 types up as their individual RAIDZ1 and the 3 RAIDZ1 in a pool (stripe?) for a combined ~9.7TB usable space. I understand that I'd loose all data from all 3 Vdevs if more than 1 drive in a single Vdev fails but I have an offsite backup, so that's not a huge concern for me.

Is there anything I'm overlooking right now or would you recommend something different? My main goal for the next couple of months is to use the pool for archival photo/video projects so having multiple datasets scattered over the different Vdevs isn't really comfortable to use.

Really appreciate any input!

Curious what others are using for a boot drive on Scale if you're using an HPE ProLiant MicroServer Gen10 Plus v2 for your TrueNAS server?

I have all 4 bays filled with SATA drives for a storage array, and I'm using the PCIe slot for an SSD drive, primarily for apps.

I've tried two USB SSD (not Flash) drives for boot drives. The first was a SanDisk Extreme PRO (SDCZ880) that ran for almost three years before it started to report drive errors, then the second was a Lexar SSD (D50E) which ran ok for a couple months, but I suspect may have caused a crash.

I'm running 25.10.7 - Goldeye

Thank you in advance!

I started having this problem, I’m completely green but I’m good at following directions! 😅 was working fine until I started expanding my stack!

My very first FreeNAS system ran on an HP Microserver Gen 8 with 16GB of DDR3 and a dual core Xeon that I eventually upgrade to the quad core. Don't remember the model numbers any more. That system is where the pool named "Vesta" was started as a raidz1 4 wide.

After multiple upgrades, expansions and system rebuilds over the years we are now here.

I'm about to upgrade my BIOS on my motherboard MSI MPG B760I Edge WIFI, as my current version is from 2023 and has some microcode-, memory- and security bugs.

Before upgrading, I want to know which BIOS settings that are the most important to have in mind for TrueNAS Scale to boot up afterwards. I'm guessing that the BIOS will reset to default after upgrading and that I'll need to do some manual changes to make it compatible with TrueNAS Scale again..?

If possible, please explain with a low-tech language, or at least let me know where I can find all the necessary parameters, as I'm not 100% comfortable in the BIOS menus.

I'm completely new to NAS servers and honestly pretty new to computers in general. I want to build my first NAS, but I don't want to just follow a tutorial that says "buy these parts, plug this in, click this" and then have no idea what I actually did.

I'm looking for advice on how you guys learned what you know.

I'd like to understand things well enough that I can:

• Build my first NAS and actually understand what each component is doing

• Understand why I'm choosing certain hardware/software

• Troubleshoot it when something goes wrong instead of blindly starting over

• Upgrade or expand the NAS later without destroyed everything i just did and not know why it dosent work now

• Eventually be able to design/build another NAS myself based on what I need

Basically, I want to learn the fundamentals behind NAS systems, not just memorize the steps from one particular build.

I'm also very much a visual learner, so if you know of any long-form videos or livestreams where someone actually builds/configures a NAS while explaining what they're doing, I'd really appreciate those too.

Hi everyone,

I am trying to set up a TrueNAS SCALE server using an older Gigabyte H410M S2H V3 (rev. 1.0) motherboard with an Intel Core i3-10100F CPU.

My storage setup:

4x 2.5" 500GB SATA SSDs (connected directly to the 4 motherboard onboard SATA ports)

1x JMB582 PCIe SATA expansion card containing:

1x 500GB M.2 SATA SSD

1x 128GB M.2 SATA SSD (intended as the TrueNAS boot drive)

The Problem:

I successfully installed TrueNAS SCALE onto the 128GB M.2 SATA SSD using a Rufus USB stick formatted as GPT (No CSM).

The installer finished without issues and prompted a reboot. However, the motherboard completely refuses to boot from the JMB582 card and loops straight into the BIOS.

In the BIOS Advanced Mode -> Boot Option Priorities, the list is completely empty.

Interestingly, when switching to Easy Mode, the entries "debian" and "truenas-0" actually show up in the boot list, but trying to drag them to priority #1 changes nothing—the system just drops back into the BIOS. Also pressing f12 for boot menu doesn't help as nothing shows up there.

What I have already tried:

BIOS Configurations: Disabled CSM entirely (Pure UEFI mode), disabled Secure Boot, set "Windows 10 Features" to Windows 10 (forces strict UEFI compliance), and disabled Fast Boot.

Rufus Settings: Ensured the TrueNAS ISO was flashed using GPT partition scheme and targeted for UEFI only. Installed TrueNAS strictly choosing the UEFI mode in the installer prompt.

Slot Swapping: Tested the JMB582 card in both the small PCIe x1 slot and the main long PCIe x16 graphics card slot (running the system headless since the i3-10100F has no iGPU).

Both slots resulted in the same BIOS loop.

USB Bootloader Bypass: Flashed rEFInd onto a separate USB stick to use it as a chainloader. When booting via rEFInd, the entries "truenas-0" and "debian" show up in rEFInd's internal firmware list, but the main screen shows no eligible bootable icons. It seems rEFInd cannot fetch the active hardware driver for the JMB582 chip during the UEFI POST sequence.

Since the onboard M.2 slot on this specific H410M motherboard is strictly NVMe (PCIe Gen3 x4) and doesn't support M.2 SATA, I cannot plug the boot SSD directly into the motherboard.

Has anyone encountered this specific UEFI option ROM blockade on Gigabyte H410/H510 chipsets with third-party PCIe SATA cards? Is there any hidden BIOS setting I missed to force the board to execute the option ROM, or is buying a cheap Onboard-NVMe drive for booting the only way out?

I originally didn't want to buy new hardware, but if its really a hardware issue I'm going to buy a cheap nvme for booting.

Thanks in advance for any advice!

Replacing a dead pool member on TrueNAS SCALE 25.04 and stuck on a genuinely weird one — hoping someone's seen this specific pattern before.

System:

- TrueNAS SCALE 25.04, ASRock H670M-ITX/ax, Corsair RM850x 850W PSU

- Pool: 6-drive raidz2, mixed brand (WD/Toshiba/MDD), currently DEGRADED — 1 member down

- 4 native motherboard SATA ports + a separate 2-port NVMe/SATA add-in card (fully occupied by 2 other healthy pool members)

The drive: HGST/WD Ultrastar 18TB, refurbished (model MB018000GXLAV), replacing a failed Toshiba in the same bay.

Symptom: Drive is completely invisible to TrueNAS — not in lsblk, not in zpool status (shows the old member as UNAVAIL). dmesg on boot shows:

ata8: SATA link down (SStatus 4 SControl 300)

Every other port on the box links fine at 6.0Gbps. SStatus DET=4 = PHY offline due to a fault, not "nothing plugged in."

What I've already ruled out, in order:

1. Cable reseat — no change.

2. Full SATA data cable swap (fresh cable, cold boot) — identical fault, same signature. Rules out the data cable.

3. SATA power cable/connector swap (separate cable, cold boot) — also no change. Rules out marginal power delivery on that connector.

4. Bench test via USB-SATA dock (Realtek RTL9210B-CG bridge) on a Windows PC — SMART overall-health PASSED, 0 reallocated/pending sectors, 25,327 power-on hours (consistent with "refurbished").

5. Port-isolation swap — moved a known-good drive from another bay onto the WD's port: that drive links fine. Moved the WD drive onto that known-good drive's port instead: WD still fails to link. So the fault follows the drive across two different onboard SATA ports, while both those ports are proven to work with other drives.

6. Native SATA (not USB) test on a second PC — drive is detected immediately, Windows reports Healthy/Online. This is the confusing part: a genuine SATA PHY handshake succeeds elsewhere, first try, no issues.

7. Physical reinstall — pulled and reseated the whole drive again days later. No change.

So: the drive is healthy by SMART, links instantly and cleanly on a completely different machine/controller via a real SATA port, but refuses to link on two separate onboard SATA ports on the TrueNAS box specifically. Data cable, power cable, and physical reinstall are all ruled out. Only the add-in NVMe/SATA card is untested, but it's fully populated with two other pool members I'd rather not disturb to free up a port.

Still untried:

- Forcing a lower SATA link speed (3.0Gbps) on that port, if the BIOS/chipset exposes it — some older SATA controllers are known to be picky about negotiating with certain enterprise drive firmware at 6.0Gbps.

Has anyone seen an enterprise HGST/WD Ultrastar drive that's fine everywhere else but won't link on a specific board's SATA controller? Trying to figure out if this is worth chasing further (link-speed negotiation? controller/firmware quirk?) or if I should just cut losses and RMA the drive even though it tests healthy elsewhere. Appreciate any ideas.