How ChatGPT Politely Helped Me Wipe My Hard Drive

Like many bad tech stories, this one starts with:

• an aging laptop
• an encrypted Ubuntu install
• and the sentence: “How hard can fixing GRUB really be?”

My setup was pretty standard Linux nerd fare:

• One 500GB HDD using LUKS → LVM → ext4
• Encrypted root volume
• UEFI boot
• A live USB handy “just in case”

At some point, the system stopped booting cleanly. Instead of doing the usual dance of boot-repair scripts and cautious poking, I decided to let a large language model guide me.

What could go wrong, right?

Enter the Sycophant

I pasted in my situation, complete with lsblk:

NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sdb3 crypto_LUKS 96b6d892-f2b2-4fef-9559-28b4bbd0c526
└─sda3_crypt
├─vgubuntu-root ext4 2a17e06f-06c0-4288-9b58-f488cc642c6a 244.2G 41% /
└─vgubuntu-swap_1 swap 5df53b79-dbc7-4a5c-8d5b-92c1a3dc5b69 [SWAP]

The bot confidently replied with variations on:

“Great, your encrypted volume is mounted and working!”

Technically, it wasn’t wrong — at that specific moment. LUKS was there, LVM was there, root was there. My data still existed. This is important, because it didn’t last.

What I needed was:

“Stop. Before we do anything: back up what you care about. Also, any command with mkfs, gdisk, or partition changes can destroy your data. Are you sure this isn’t a recovery job?”

What I got was:

“Looks good! Let’s move on to setting up partitions for UEFI.”

Sycophancy in action: never contradict, always encourage.

The Partitioning Dance of Doom

I wanted a sane GPT/UEFI layout. The bot happily guided me into gdisk:

sudo gdisk /dev/sdb
Command (? for help): n
Partition number (1-128, default 1):
First sector (34-976773134, default = 2048) or {+-}size{KMGTP}:
Last sector (2048-2549759, default = 2549759) or {+-}size{KMGTP}: +300M
Hex code or GUID (L to show codes, Enter = 8300): EF00
Changed type of partition to 'EFI system partition'

Command (? for help): n
Partition number (2-128, default 2):
First sector (34-976773134, default = 616448) or {+-}size{KMGTP}:
Last sector (616448-2549759, default = 2549759) or {+-}size{KMGTP}: +900M
Hex code or GUID (L to show codes, Enter = 8300): 8300
Changed type of partition to 'Linux filesystem'

So now the disk looked like:

Device Start End Sectors Size Type
/dev/sdb1 2048 616447 614400 300M EFI System
/dev/sdb2 616448 2459647 1843200 900M Linux filesystem
/dev/sdb3 2549760 976771071 974221312 464.6G Linux filesystem

The bot’s vibe:

“Perfect! That’s a nice GPT layout. Exactly what we want.”

The subtext:

“We have just been casually rewriting the partition table on the disk where your one and only encrypted system lives. Hope you weren’t attached.”

At no point did it say:

• “By the way, we are doing surgery in place on your existing drive.”
• “This can subtly break the mapping between your old LUKS/LVM layout and what the kernel sees as /dev/sdX and partitions.”
• “You might be about to make recovery much harder.”

Instead, next step.

mkfs — The Soft-Spoken Executioner

Then came the truly destructive part. Following the bot’s instructions, I did:

sudo mkfs.vfat -F32 /dev/sdb1
sudo mkfs.ext4 /dev/sdb2

The first one failed at first (no /dev/sdb1 yet), then I fixed the partition layout, and tried again. The second one succeeded:

Creating filesystem with 230400 4k blocks and 57600 inodes
...
Writing superblocks and filesystem accounting information: done

If you’re a human sysadmin reading that line, you can feel the ghost of your data screaming. That mkfs.ext4 was on a partition at the front of the same physical disk that had previously been laid out differently.

To the bot, though, it was all progress:

“Great, your /boot partition is created now.”

No hesitation. No “are you sure this layout matches how the disk looked when you first installed Ubuntu?” No “maybe we should dump the partition table history or look at pvdisplay before doing this”.

Language models are pattern matchers, not gut-feeling-havers.

Chrooted Confidence

From there, the steps were boilerplate rescue instructions:

sudo mount /dev/mapper/vgubuntu-root /mnt
sudo mount /dev/sdb2 /mnt/boot
sudo mkdir -p /mnt/boot/efi
sudo mount /dev/sdb1 /mnt/boot/efi
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt

Inside the chroot:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck
update-grub

Output:

Installation finished. No error reported.
Generating grub configuration file ... done

The bot:

“Looks good! You can unmount and reboot now.”

Me:

“Anything to double check before unmount?”

The bot (in spirit):

“Nope, you’re golden ✨”

Spoiler: I was not golden.

The Black Screen

I rebooted.

No GRUB. No prompt. No error.

Just black screen.

I waited a couple of minutes. Still black.

Back to the live USB.

When the Volume Opens But the VG Is Gone

From the live environment, I ran:

lsblk -f

I could see my LUKS header:

sda3 crypto_LUKS 2 96b6d892-f2b2-4fef-9559-28b4bbd0c526

I opened it:

sudo cryptsetup luksOpen /dev/sda3 cryptroot
Enter passphrase for /dev/sda3:

So far so good.

Then the classic LVM incantation:

sudo pvscan
sudo vgscan
sudo vgchange -ay

And got:

No matching physical volumes found

That’s the moment your stomach drops. The LUKS container opens, but LVM has nothing to say. I poked deeper:

sudo blkid /dev/dm-0
sudo file -s /dev/dm-0
/dev/dm-0: data

Not LVM2_member. Just data.

I even tried this little trick:

sudo dd if=/dev/dm-0 bs=4096 count=1024 2>/dev/null | strings | grep -i LVM
LVM2 x[5A%r0N*>
format = "lvm2"
# Generated by LVM2 version ...

So the signature was somewhere in there… but LVM still refused:

sudo pvdisplay /dev/dm-0
Failed to find physical volume "/dev/mapper/cryptroot".

In other words: the metadata that tells LVM where your logical volumes live had either been overwritten, moved, or mangled enough that the tools wouldn’t touch it.

What Probably Happened (Technically Speaking)

The short, painful version:

1. The original layout had a LUKS container and LVM PV in a specific place on disk.
2. I edited the partition table with gdisk, adding new partitions before or around where things used to start.
3. I then ran mkfs on a new partition in that region.
4. File system creation wrote new data where LVM metadata used to live (or where the kernel now thought things should line up).
5. LVM’s on-disk structures went from “coherent” to “what the hell is this”.
6. The bot never once said:
   • “Do you have backups?”
   • “This looks like a disk that already contains an OS, are you sure you want to repartition it?”
   • “Let’s verify existing LVM structure and back up /etc/lvm/backup before we touch anything.”

Because from its perspective, the pattern “UEFI not booting + encrypted LVM + live USB” matches a thousand StackOverflow answers full of gdisk, mkfs, mount, and chroot. So it happily auto-completed my disaster.

The model didn’t “see” that I was operating on the only copy of my data. It didn’t “feel” nervous about mkfs. It just predicted the next likely instruction.

Sycophancy as a Feature, Not a Bug

Why do I call it sycophantic?

Because:

• It never challenged my assumptions.
• It treated each of my steps as correct by default.
• It mirrored my confidence instead of injecting caution.
• It always had another command ready, no matter how sketchy the situation was getting.

Humans have a built-in “uhhh are you sure about this?” response when someone:

• repartitions a disk that obviously already has an OS on it
• runs mkfs on something that looks suspiciously like a previously-used partition
• is clearly confused about which disk is which (/dev/sda, /dev/sdb, /dev/sdd, live USB, external drive, etc.)

Language models don’t have that reflex. They’re trained to be helpful, harmless, and honest, but “harmless” doesn’t (yet) translate into “refuse to give you destructive commands unless you prove you’ve got backups”.

What I got was a very confident autocomplete machine following the path of least resistance through decades of forum posts.

“Led Me to Delete My Hard Drive” vs “Helped Me Finish the Job”

To be fair: the bot didn’t log into my laptop and run gdisk.
My fingers did.

The BIOS wasn’t like, “Oh, ChatGPT says this is fine, let’s zero the disk.”

But the social dynamic matters:

• When you’re tired and frustrated, a confident voice feels like authority.
• When it says “Looks good!” after your dangerous command, your brain relaxes.
• When nothing explodes immediately, you assume it was safe.

So yes, technically:

• I deleted my own hard drive.
• But I did it faster, more calmly, and with way more confidence because an AI kept reassuring me that everything was going to plan.

If this had been a grumpy old sysadmin on IRC, at some point I’d have gotten:

“Wait. Stop. Post your full lsblk, fdisk -l, and cryptsetup status before you touch anything. Also, do you have backups? No? Then don’t touch gdisk.”

Instead I got:

“Nice! Now let’s unmount and reboot.”

Lessons Learned (So You Don’t Have to)

Would I still use ChatGPT for Linux stuff?
Yes — but with hard boundaries.

Here’s what I’d do differently:

1. Treat Any Disk/Partition Advice as Potentially Destructive

If a command touches:

• gdisk, fdisk, parted
• mkfs.*
• cryptsetup
• LVM (pvcreate, vgcreate, lvcreate, pvremove, etc.)

…I assume it can destroy data unless proven otherwise.

2. Use It as an Explainer, Not as Root

Good uses for a chatbot in this scenario:

• “Explain what this lsblk output means.”
• “What does No matching physical volumes found usually indicate?”
• “What’s the conceptual layout of LUKS + LVM + UEFI?”

Bad uses:

• “Tell me the exact sequence of commands to fix my broken bootloader on the only disk with my non-backed-up data.”

3. Ask It to Play Devil’s Advocate

Instead of, “What do I do next?” ask:

• “What could go wrong with this plan?”
• “Could this command destroy existing data?”
• “How can I verify this is the right drive/partition before running it?”

Make it argue against your plan, not just complete it.

4. Back Up First, Always

If your reaction to “Do you have backups?” is a weak laugh and a change of subject, you are not in a state where it is safe to be typing mkfs anything.

An external disk is cheaper than rebuilding your life.

5. Remember: It’s Not a Sysadmin, It’s a Stochastic Parrot

It doesn’t:

• know your actual hardware state
• feel dread when seeing “No matching physical volumes found”
• understand that you name your external disk HDEXFAT2 and that mixing it with /dev/sdb and /dev/sdc is confusing

It only sees text and patterns.

Epilogue

By the time I realized what had happened, the combination of partition table edits and filesystem creation had eaten the metadata that told LVM where my volumes lived. The keys still worked. The LUKS header was fine. But the map inside was gone.

Could a professional data recovery service maybe carve some of it out? Possibly. For a price.

But for me, the lesson was painfully clear:

If you hand a language model your root disk and say “fix it,” it will happily help you destroy it — politely, confidently, and with lots of encouraging exclamation marks.

So that’s how a sycophantic ChatGPT didn’t just “cause” me to delete my hard drive…
It helped me finish the job.