this post was submitted on 26 Dec 2025
-48 points (36.8% liked)

Selfhosted

55934 readers
794 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

  7. No low-effort posts. This is subjective and will largely be determined by the community member reports.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
HybridSarcasm@lemmy.world
HybridSarcasm@lemmy.hybridsarcasm.xyz
-48
ChatGPT fried my drive!? [Solved] (lemmy.zip)
submitted 1 month ago* (last edited 1 month ago) by rook@lemmy.zip to c/selfhosted@lemmy.world
93 comments fedilink hide all child comments
 

Did I just brick my SAS drive?

I was trying to make a pool with the other 5 drives and this one kept giving errors. As a completer beginner I turned to gpt.....

What can I do? Is that drive bricked for good?

Don't clown on me, I understand my mistake in running shell scripts from Ai...

EMPTY DRIVES NO DATA

The initial error was:

Edit: sde and SDA are the same drive, name just changed for some reason And also I know it was 100% my fault and preventable 😞

**Edit: ** from LM22, output of sudo sg_format -vv /dev/sda (broken link)

BIG EDIT:

For people that can help (btw, thx a lot), some more relevant info:

Exact drive model: SEAGATE ST4000NM0023 XMGG

HBA model and firmware: lspci | grep -i raid 00:17.0 RAID bus controller: Intel Corporation SATA Controller [RAID mode] Its an LSI card Bought it here

Kernel version / distro: I was using Truenas when I formatted it. Now trouble shooting on other PC got (6.8.0-38-generic), Linux Mint 22

Whether the controller supports DIF/DIX (T10 PI): output of lspci -vv (broken link)

Whether other identical drives still work in the same slot/cable: yes all the other 5 drives worked when i set up a RAIDZ2 and a couple of them are exact same model of HDD

COMMANDS This is what I got for each command: (broken link)

Solved by y0din! Thank you soo much!

Thanks for all the help 😁

top 50 comments
sorted by: hot top controversial new old
[–] recklessengagement@lemmy.world 152 points 1 month ago* (last edited 1 month ago)

ChatGPT didn't fry your drive. You fried your drive.

You should be looking up these commands and flags before you run them.

[–] 6nk06@sh.itjust.works 122 points 1 month ago (24 children)

As a completer beginner I turned to gpt

I tell people not to do that all the time. They'd rather listen to the statistical vomit machine.

load more comments (24 replies)
[–] rtxn@lemmy.world 73 points 1 month ago

@Mods, please don't delete this. It's a valuable lesson.

[–] kingofras@lemmy.world 72 points 1 month ago (1 children)

It’s really next to impossible to read that and not clown on you, so I’ll just print these out and hang them in the server room next to the no cats or drinks signs.

[–] Holytimes@sh.itjust.works 9 points 1 month ago (1 children)

No cats?! High blasphemy! Servers are warm and the perfect bed!

load more comments (1 replies)
[–] Greg@lemmy.ca 67 points 1 month ago* (last edited 1 month ago) (4 children)

I'm confident this is recoverable. Can you throw the failing drive into a USB enclosure? It might be easier to reformat the drive in the OS you're most familiar with.

And don't feel bad about breaking things, that's the best way to learn! I've been breaking things long before ChatGPT came along.

[–] irmadlad@lemmy.world 12 points 1 month ago

And don’t feel bad about breaking things, that’s the best way to learn

Most of what I know, which is not a a huge repository of intellect, I learned thusly:

  • Read ---> try--->fuck it up #$%^^
  • re-read ---> try again--->fuck it up once more #$%^^
  • $$@#!!! more reading ---> more trying --->That WORKED! Write that shit down!
[–] rook@lemmy.zip 4 points 1 month ago (2 children)

Thanks for the uplifting words

I've connected to drive to another PC running Linux Mint 22, and the disks app can see the drive but no actions can be done on it. And Gparted can't even read it lol.

Any ideas?

load more comments (2 replies)
load more comments (2 replies)
[–] entropicdrift@lemmy.sdf.org 52 points 1 month ago* (last edited 1 month ago) (1 children)

Don't trust AI to know what they're doing for you. The only time they work reliably as a tool is when you already know what you're doing enough to spot their errors/hallucinations.

AI is the wrong tool here. You need to do real internet research.

[–] scrubbles@poptalk.scrubbles.tech 14 points 1 month ago (2 children)

Exactly this. People here mass downvote but I personally find AI to be extremely useful... To do things I already know how to do but don't have the time for. I don't trust it to do things I can't spot the errors in

load more comments (2 replies)
[–] y0din@lemmy.world 50 points 1 month ago* (last edited 1 month ago) (2 children)

Right now there isn’t enough information to conclude that the drive is “bricked”.

sg_format on a SAS drive with DIF enabled can absolutely make the disk temporarily unusable to the OS if the format parameters no longer match what the HBA/driver expects, but that is very different from a dead drive.

To make any determination, more data is required. At minimum (boot with a live Linux USB drive if you are unable to get to this information):

Please provide verbatim output from:

  • dmesg -T (from boot and when the drive is detected)
  • sblk -o NAME,MODEL,SIZE,PHY-SeC,LOG-SeC
  • fdisk -l /dev/sdX
  • sg_inq /dev/sdX
  • sg_readcap -l /dev/sdX
  • sg_modes -a /dev/sdX

Also specify:

  • Exact drive model
  • HBA model and firmware
  • Kernel version / distro
  • Whether the controller supports DIF/DIX (T10 PI)
  • Whether other identical drives still work in the same slot/cable

Common possibilities (none can be confirmed without logs):

  • Drive formatted with DIF enabled but HBA/OS not configured for it
  • Logical/physical block size mismatch (e.g. 520/528 vs 512/4096)
  • Format still in progress or left the drive in a non-ready state
  • Mode pages changed that Linux does not like by default

Things that are usually recoverable on SAS drives:

  • Re-formatting with correct sector size and DIF disabled
  • Clearing protection information
  • Power-cycling the drive after format completion
  • Formatting from a controller that fully supports the drive’s feature set

Actual permanent bricking from sg_format alone is rare unless firmware flashing or vendor-specific commands were involved.

Until logs are posted, all anyone can honestly say is:

The drive is not currently usable, but there is no evidence yet that it is permanently damaged.

If you can share this information it might be possible to get the drive back online, though I make no promises.

(edit typos)

[–] y0din@lemmy.world 8 points 1 month ago* (last edited 1 month ago)

One more hopefully happy update:

Based on everything you’ve shown so far in the information you have given, the most probable cause is that the drive was formatted with T10 DIF / Protection Information enabled (PROTECT=1), and you are now accessing it through a controller path that does not support DIF.

This is a very common failure mode with enterprise SAS drives and sg_format.

(edit: oh, how I am in a love/hate relationship with my brain on delayed thoughts...)

In your paste from sg_format you can see this flag:

sudo sg_format -vv /dev/sda open /dev/sda with flags=0x802 inquiry cdb: [12 00 00 00 24 00] SEAGATE ST4000NM0023 XMGG peripheral_type: disk [0x0] PROTECT=1

(end of edit)

What this means in practice:

  • PROTECT=1 = the drive was formatted with DIF Type 1
  • Logical blocks are no longer plain 512/4096 bytes (e.g. 520/528 instead)
  • The HBA + driver must explicitly support T10 PI
  • If the controller does not support DIF, the drive may:
    • Be detected
    • But fail all I/O
    • Appear “dead” even though it is healthy

This is not bricking. It is a configuration mismatch.

How to fix it (most reliable path)

You need to connect the drive to a DIF-capable SAS HBA (LSI/Broadcom, same type as originally used if possible).
Best option is to do this on the original hardware, even via a USB live Linux environment.

Once the drive is on a T10-capable controller, reformat it with protection disabled.

Example (this will ERASE the drive and might take a LONG time to complete):

sudo sg_format --format --size=512 --fmtpinfo=0 --pfu=0 /dev/sdX

Key flags:

  • --fmtpinfo=0 → disables DIF / PROTECT
  • --size=512 (or 4096 if you prefer standard 4K)
  • --pfu=0 (disables PROTECTION flag, your GPT forgot to include this which actually disables the protection)
  • Use the correct /dev/sdX

After this completes and the system is power-cycled, the drive should behave like a normal disk again on non-DIF controllers.

Important notes

  • sg_format alone almost never permanently damages SAS drives
  • This exact scenario happens frequently when drives are moved between controllers
  • Until tested on a DIF-capable HBA, there is no evidence of permanent failure

If you cannot access a T10-capable controller, the drive may remain unusable on that system, but still be perfectly recoverable elsewhere.

A case of a user with another problem but where he needed to disable DIF, got it fixed after a new format with these parameters (from Google):

https://www.truenas.com/community/threads/drives-formatted-with-type-1-protection-eventually-lead-to-data-loss.86007/

[–] rook@lemmy.zip 3 points 1 month ago* (last edited 1 month ago) (2 children)

Thank you for helping! Like I said I'm a complete beginner with little knowledge of all this, means a lot 🤗

just so you know I connected the drive to my dell pc, so its just the one broken drive not all 6.

Exact drive model: SEAGATE ST4000NM0023 XMGG

HBA model and firmware: lspci | grep -i raid 00:17.0 RAID bus controller: Intel Corporation SATA Controller [RAID mode] Its an LSI card Bought it here

Kernel version / distro: I was using Truenas when I formatted it. Now trouble shooting on other PC got (6.8.0-38-generic), Linux Mint 22

Whether the controller supports DIF/DIX (T10 PI): output of lspci -vv

Whether other identical drives still work in the same slot/cable: yes all the other 5 drives worked when i set up a RAIDZ2 and a couple of them are exact same model of HDD

COMMANDS This is what I got for each command: verbatim output from

Edit: from LM22, output of sudo sg_format -vv /dev/sda

I really appreciate your knowledge and help 🙂
Let me know if anything else is needed

[–] y0din@lemmy.world 5 points 1 month ago* (last edited 1 month ago) (1 children)

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.

[–] rook@lemmy.zip 3 points 1 month ago (5 children)

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.

load more comments (5 replies)
[–] y0din@lemmy.world 3 points 1 month ago

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.

[–] xxce2AAb@feddit.dk 43 points 1 month ago (1 children)

And what have we learned?

[–] N0x0n@lemmy.ml 14 points 1 month ago (1 children)

All together: Don't blindy copy/past from the internet OR from AI !

load more comments (1 replies)
[–] TuEstUnePommeDeTerre@lemmy.blahaj.zone 41 points 1 month ago

Per this forum post, you might just need to reboot. This was the first link that came up when I searched for your error. In the future, turn to documentation and the forums/support for the software rather than a dumb text generator.

[–] artyom@piefed.social 39 points 1 month ago

No, you fried your drive, by listening to CGPT. Also learn how to take a screenshot.

[–] irmadlad@lemmy.world 35 points 1 month ago* (last edited 1 month ago) (2 children)

OP, I am sorry that I cannot offer any immediate solution to your issue. However, if I may, pass along a bit of advice I learned long ago, and it has nothing to do with AI. TAKE PROLIFIC NOTES!!! It is tedious, it is work, but it will save your ass in the long run. Write everything down. Don't be lulled into the mindset that you will be able to remember each and every thing you've done to the server, especially when you're breaking new ground in your selfhosting journey. 9 times out of 10, you won't. Then when you are successful with your endeavors, go back, clean up your notes, and store them for future reference.

[–] Elkenders@feddit.uk 5 points 1 month ago

I very much wish I'd done this. I'm very happy with my system but it'll be a slog if and when I need to set it up again.

[–] zebidiah@lemmy.ca 5 points 1 month ago (2 children)

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

for context, these are my personal notes for my personal machine. These will never be shared with anyone else, and nobody else has to try to read them or make sense of them (well... sometimes I make chatbot read my notes in order to train it on whatever I need help troubleshooting)

Before I started keeping a hot_log.txt file every single install of Linux I ever ran was a unique snowflake and no two systems were ever the same

[–] irmadlad@lemmy.world 5 points 1 month ago

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

[–] jerkface@lemmy.ca 4 points 1 month ago* (last edited 1 month ago)

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

So worse than tedium.

[–] jerkface@lemmy.ca 32 points 1 month ago* (last edited 1 month ago) (1 children)

There are so many things wrong here, people don't even have the bandwidth to complain about how the blurry, off-angle, fucking ROTATED photos of a screen contribute to this absolute dumpster fire of a post. Just trying to do my part.

[–] qaz@lemmy.world 6 points 1 month ago (1 children)

Don't forget about the glare

load more comments (1 replies)
[–] fodor@lemmy.zip 22 points 1 month ago

Oh dear God, what were you thinking? Why did you turn to chatgbt knowing that you could have actually found a website that told you what to do correctly written by someone who actually did it before?

[–] possiblylinux127@lemmy.zip 21 points 1 month ago

I would strongly recommend against using AI

[–] nutbutter@discuss.tchncs.de 18 points 1 month ago (6 children)

Why do you trust a text generator for critical things? And did you really not cross check what command it is asking you to run?

Anyway, the solution...

If I were you I would plug the drive into a system where I can run gparted or KDE Partition Manager, with a GUI and try to format the drive again, create the partition table again. If you have tried that, what errors are you getting?

load more comments (6 replies)
[–] Big_Boss_77@lemmynsfw.com 17 points 1 month ago

[–] Skyline969@lemmy.ca 15 points 1 month ago

AI strikes again.

[–] PhobosAnomaly@feddit.uk 15 points 1 month ago* (last edited 1 month ago)

Sorry friend.

If your data was occupationally-sensitive or renders you vulnerable to financial ruination, it's time to move to a recovery phase and see if modern data recovery specialists can work their voodoo.

Remember: never run experimental commands (you or a GenAI) in a live environment. See how it breaks things in a test environment first - if it shits itself, you may even get to learn how to fix it before running the instruction on live data.

Anecdote time! A good friend of mine drove his car to a mutual colleague's place once because the wipers were about as much use as two chicken breasts on metal poles. He says to our colleague "Hey Foxy, I hear you're good with cars, can you fix these wipers for me? The rubber seems to be in good nick but it's not clearing anything".

"Sure thing," Foxy proudly announces, "I'll get to work".

Foxy strips the wipers down, one component at a time, before dusting his hands off and walking away.

"What's going on, Foxy? The thing's still in bits!" my pal says.

"No idea," says Foxy, "not a fucking Scooby mate" and goes back inside, leaving his wipers and actuating motor in about fourteen pieces on the roadside.

So much for being good with cars.

[–] Andres4NY@social.ridetrans.it 9 points 1 month ago

@rook To be fair, that's an extremely zen attitude ChatGPT has - "Focus on the 5 healthy SAS drives." Therapy goals! 😏

[–] DieserTypMatthias@lemmy.ml 8 points 1 month ago

Don't trust a chatbot.

[–] PushButton@lemmy.world 4 points 1 month ago

You should have clicked on the "get smarter responses" button...

Sorry, I couldn't resist. I am going now, good luck.

ᕕ(ᐛ)ᕗ

load more comments
view more: next ›