Comment

Thanks for the additional details, that helps, but there are still some critical gaps that prevent a proper diagnosis.

Two important points first:

The dmesg output needs to be complete, from boot until the moment the affected drive is first detected.
What you posted is cut short and misses the most important part: the SCSI/SAS negotiation, protection information handling, block size reporting, and any sense errors when the kernel first sees the disk.

Please reboot, then run as root or use sudo:

dmesg -T > dmesg-full.txt

Do not filter or truncate it. Upload the full file.
All diagnostic commands must be run with sudo/root, otherwise capabilities, mode pages, and protection features may not be visible or may be incomplete.

Specifically, please re-run and provide full output (verbatim) of the following, all with sudo or as root, on the problem drive and (if possible) on a working identical drive for comparison:

sudo lspci -nnkvv

sudo lsblk -o NAME,MODEL,SIZE,PHY-SeC,LOG-SeC,ROTA

sudo fdisk -l /dev/sdX

sudo sg_inq -vv /dev/sdX

sudo sg_readcap -ll /dev/sdX

sudo sg_modes -a /dev/sdX

sudo sg_vpd -a /dev/sdX

Replace /dev/sdX with the correct device name as it appears at that moment.

Why this matters:

The Intel SATA controller you listed is not the LSI HBA. We need to see exactly which controller the drive is currently attached to and what features the kernel believes it supports.
That Seagate model is a 520/528-capable SAS drive with DIF/T10 PI support. If it was formatted with protection enabled and is now attached to a controller/driver path that does not expect DIF, Linux will report I/O errors even though the drive itself is fine.
sg_format -vv output alone does not tell us the current logical block size, protection type, or mode page state.

Important clarification:

Formatting the drive under TrueNAS (with a proper SAS HBA) and then attaching it to a different system/controller is a very common way to trigger exactly this situation.
This is still consistent with a recoverable configuration mismatch, not a permanently damaged disk.

Once we have:

Full boot-time dmesg
Root-level SCSI inquiry, mode pages, and read capacity
Confirmation of which controller is actually in use

…it becomes possible to say concretely whether the drive needs:

Reformatting to 512/4096 with protection disabled
A controller that supports DIF
Or if there is actual media or firmware failure (less likely)

At this point, the drive is “unusable”, not proven “bricked”. The missing data is the deciding factor.

One more important thing to verify, given the change of machines:

Please confirm whether the controller in the original TrueNAS system is the same type of LSI/Broadcom SAS HBA as the one in the current troubleshooting system.

This matters because:

DIF/T10 PI is handled by the HBA and driver, not just the drive.

A drive formatted with protection information on one controller may appear broken when moved to a different controller that does not support (or is not configured for) DIF.

Many onboard SATA/RAID controllers and some HBAs will enumerate a DIF-formatted drive but fail all I/O.

If the original TrueNAS machine used:

A proper SAS HBA with DIF support

then the best recovery path may be to put the drive back into that original system and either:

Reformat it there with protection disabled, or
Access it normally if the controller and OS were already DIF-aware

If the original controller was different:

Please provide lspci -nnkvv output from that system as well (using sudo or run as root)
And confirm the exact HBA model and firmware used in the TrueNAS SAS controller

At the moment, the controller change introduces an unknown that can fully explain the symptoms by itself. Verifying controller parity between systems is necessary before assuming the drive itself is at fault.

source

Sort:hotnew top

rook@lemmy.zip ⁨20⁩ ⁨hours⁩ ago
Thanks for the continued support! ❤

I’ve attached an identical Segate SAS drive from the server.

To confirm, it is the same LSI card that was in the TrueNAS server. I pulled it out of the server and put it into the trouble shooting machine, where I run the commands.

It is this one: 01:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS2308 PCI-Express Fusion-MPT SAS-2 [1000:0087] (rev 05)

I did not see your other reply lol, I will also try this command that you recommended:

sudo sg_format –format –size=512 –fmtpinfo=0 –pfu=0 /dev/sdb

Also, the sg_format ran for less than 5 minutes, very quick. However, if I can recall, it did say it was completed.

**Note: ** “Bricked Drive” turned to sdb

Identical working drive installed as sda

Here is the dmesg -T > dmesg-full.txt with the identical drive

Here is the code from: (with the output for each drive, separately)

sudo lspci -nnkvv

sudo lsblk -o NAME,MODEL,SIZE,PHY-SeC,LOG-SeC,ROTA

sudo fdisk -l /dev/sdX

sudo sg_inq -vv /dev/sdX

sudo sg_readcap -ll /dev/sdX

sudo sg_modes -a /dev/sdX

sudo sg_vpd -a /dev/sdX

Thanks again for all the help, I await your reply. :)

I will let you know the results of (sudo sg_format –format –size=512 –fmtpinfo=0 –pfu=0 /dev/sdb), as soon as it’s done.

source
- y0din@lemmy.world ⁨15⁩ ⁨hours⁩ ago
  Thanks for the update, that’s helpful.
  
  Confirming that the controller is a Broadcom / LSI SAS2308 and that it’s the same HBA that was used in the original TrueNAS system removes one major variable. It means the drive is now being tested under the same controller path it was previously attached to.
  
  The device mapping you described is clear:
  
  sda = known-good identical drive
  
  sdb = the problematic drive
  
  Running:
  
  sudo sg_format --format --size=512 --fmtpinfo=0 --pfu=0 /dev/sdb
  
  as you did is the correct next step to normalize the drive’s format and protection settings.
  
  A few general notes while this is in progress:
  
  Some drives report completion before all internal states are fully settled, which will cause reduced performance as the operation continues until finished in the background
  
  A power cycle after completion is recommended before testing the drive again
  
  At this point it makes sense to pause any further investigation until the current sg_format has fully completed and the system has been power-cycled.
  
  Once that’s done, the next step will be a direct comparison between sdb and the known-good sda using:
  
  sudo sg_readcap -lla
  
  Reported logical and physical sector sizes
  
  Protection / PI status
  
  As a general note going forward: on Linux / FreeBSD it’s safer to reference disks by persistent identifiers (e.g. /dev/disk/by-id/ on Linux or glabel on FreeBSD) rather than /dev/sdX, as device names can change across boots or hardware reordering.
  
  Post the results when you’re ready and the sg_format complete and we can continue from there.
  
  source
  - rook@lemmy.zip ⁨4⁩ ⁨hours⁩ ago
    Great News!
    
    Format completed and now the drive is viewable in “Disks” (however it is still unknown compared to the other one, it might just need a normal format.
    
    The code for the comparison returns invalid option, I assumed you need just -l comparison:
    
    sudo sg_readcap -l /dev/sdb and sudo sg_readcap -l /dev/sda
    
    One question I have is: what do you mean by powercycle? Is that another command to run on the problematic drive? If you mean turn off the pc and turn it back on, I will do that right now, just after the drive has completed formatting.
    
    After PowerCycle (turned pc off and on)
    
    sudo sg_readcap -l /dev/sdb and sudo sg_readcap -l /dev/sda
    
    Would the next step be formatting of some kind?
    
    source
    y0din@lemmy.world ⁨3⁩ ⁨hours⁩ ago
    That’s good news — what you’re seeing now is the expected state.
    
    A quick clarification first:
    
    Power cycle means exactly what you did: shut the machine down completely and turn it back on. There is no command involved. You did the right thing.
    
    Regarding the current status:
    
    The drive showing up in Disks but marked as unknown is normal
    
    At this point the disk has:
    
    No partition table
    
    No filesystem
    
    “Unknown” here does not indicate a problem, only that nothing has been created on it yet
    
    About sg_readcap:
    
    sg_readcap -l is correct
    
    There is no direct “comparison” mode; running it separately on sda and sdb is exactly what was intended
    
    The important thing is that both drives now report sane, consistent values (logical block size, capacity, no protection enabled)
    
    Next steps:
    
    Yes, the next step is normal disk setup, just like with any new drive:
    
    Create a partition table (GPT is typical)
    
    Create one or more partitions
    
    Create a filesystem (or add it back into ZFS if that’s your goal)
    
    At this stage the drive has transitioned from “unusable” to functionally recovered. From here on, you’re no longer fixing a problem — you’re just provisioning storage.
    
    If you plan to put it back into TrueNAS/ZFS, it’s usually best to let TrueNAS handle partitioning and formatting itself rather than doing it manually on Linux.
    
    Nice work sticking with the process and verifying things step by step.
    
    source