Comment on ChatGPT fried my drive!?
rook@lemmy.zip 22 hours agoThanks 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.
y0din@lemmy.world 16 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/sdbas 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:
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 -llaReported 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.
rook@lemmy.zip 5 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?
y0din@lemmy.world 5 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.