Selfhosted

It doesn’t really need to be tedious… My notes are jokey, full of profanity, sarcasm, and self deprecating humor

So worse than tedium.

My notes are jokey, full of profanity, sarcasm, and self deprecating humor

I meant tedious, as in, it takes some effort to pause, write the shit down, and then proceed on. I can only speak for myself, but when I'm in the zone doing something, excitement can overshadow note taking. So, I have to make myself document line by line. But, yeah I have entries like 'Before proceeding, make sure you do _____ , dumbass!' LOL

Sorry for the mess with replies.

Please see the last comment I made on my own comment instead of yours where it should have been.

Your drive is almost certainly not dead, you just need a T10 / DIF capable controller to disable the PROTECTION flag.

Read more in the other post.

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

1.  Do not filter or truncate it. Upload the full file.

2. 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.

(edit:)

One last thing, how long did you let sg_format run for?

It can take hours to complete one percent if the drive is large, probably a full day or more considering the capacity of your drive.

I was just wondering if it might have been cut short for some reason and just needs to be restarted on the original hardware to complete the process and bring the drive back online.

How do you have the SAS drive connected to your Mint 22 box (what exact adapter/controller)? Is it going through a real SAS HBA (LSI/Broadcom-style, IT/HBA mode), or through a RAID controller / USB-SAS bridge / "virtual" adapter?

Reason I’m asking: there are basically two connection paths:

• True HBA/passthrough: Linux gets direct SCSI access (you’ll see a /dev/sgX for the disk) and you can usually low-level reformat it back to 512-byte logical blocks (e.g., from 520/528).
• RAID/USB/translation layer: the controller hides or emulates the SCSI commands, so tools like sg_format often can’t issue the low-level format needed to switch the sector size. That might be why the disk is visible in the disks app but not in gparted.

Given the screen shots I believe it's the later. Can someone smarter than me confirm?