0

I moved / and /boot onto an M.2 drive, leaving /home on my SSD. After ensuring M.2 drive was booting correctly I started a LiveCD (Pop_OS because it's what I had around and it's Ubuntu more or less) and used gparted to delete the partitions on the SSD and then expand /home to the entire size of the SSD.

Apparently when Pop_OS' LiveCD is inactive it doesn't sleep or turn the screen off, it logs you out. And it logged me out midway through this above process.

"Grr!" but that's ok because I am not too attached to the contents of /home it was rsync'd to my laptop yesterday. So I load up Arch and it panics because systemd cannot find /home by UUID. No biggie, UUID must have changed. lsblk no longer shows my SSD. Weird.

End up back on the LiveCD. Gparted does show my SSD from the LiveCD. But it's throwing I/O errors. I try to use parted to access it, same I/O errors. I attempt to use gsmartcontrol, it shows the drive but no data about that drive (at least gparted showed the drive size).

I drop back to BIOS and pull up the SMART disk utility, except it doesn't see my drive either.

Any chance this thing can be recovered? I don't care about the data at all, I care about being out a $300 SSD that wasn't even four months old.

1
  • A 4 month old SSD will be under warranty. So no loss. Feb 20, 2019 at 2:25

1 Answer 1

0

After a good night's rest and some coffee I came back to this problem and was able to solve it.

First, I went into BIOS and turned SATA port 3, where this drive is connected to, off, rebooted, went back into BIOS turned SATA port 3 back on, rebooted, and now my Arch install sees the drive as does my BIOS. So far so good.

I ran cgdisk and sfdisk and I can see sdb5 but I cannot access it, mount it, or get any data about it. Looking at cgdisk it appears that the partition table, both main and backup, are totally borked. OK, so no easy data retrieval --again I just want a not-dead drive.

Decide to see if I can forcefully wipe the drive clean so...

dd if=/dev/zero of=/dev/sdb bs=4096 count=1

That wipes the drive, writing zeros to the entire disk.

Next step:

sgdisk -o /dev/sdb

Which returned an error and asked me to run with the -e flag. Did that and it successfully restored the main partition table.

Spun up gparted, deleted the partition table, created a new table, created a new partition, and viola! mount /dev/sdb1 /mnt/ finally succeeded.

Used rsync to copy my laptop's /home to my newly restored SSD on my desktop and I am back up and running!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .