4

I had Arch installed on a 128GB SATA SSD in BIOS/MBR mode. I did an update, (which also updated the kernel) and rebooted. Instead of rebooting properly, I got a GRUB rescue shell. I took the SSD out of that computer and plugged it into an other one.

This is what dmesg printed when I plugged it in:

EXT4-fs (sdc1): bad geometry: block count 29304950 exceeds size of device (29304949 blocks)

Running gparted with the SSD plugged in resulted in a message-box poppig up saying:

Libparted Error Can't have a partition outside the disk!

After that message-box gparted claims that the only partition on the disk start at sector 2048 and ends at sector 234441647, which is a bit off considering that the entire drive has 234441646 total sectors, so there are two sectors in the partition that don't actually exist on the drive.

This is actually the second time I have this exact problem. Although I am not sure if it was an update that corrupted the drive at the first occasion. Anyways, after the first occasion I ended up reinstalling Arch, but I really don't want to do that again.

So why would an update corrupt the partitions of a drive in such a way. Could this mean that the SSD is failing? Is there a way to test if it is really failing? How should I go about fixing the partitions?

xuwenbuwer
  • 285
  • 1
  • 3
  • 10

1 Answers1

3

I will try to extract the core and apply it to your case.

  1. fix part 1 should be

    fsck.ext4 -fy /dev/sdc1

  2. fix part 2 should be

    resize2fs /dev/sdc1

Credit: Taken from this question.

Vlastimil Burián
  • 27,586
  • 56
  • 179
  • 309