1

While running Linux Mint 19 Cinnamon normally, the drive went into lockdown mode preventing disk writes indicating possible corruption. Upon shutdown and reboot I was met with ACPI errors.

Following this thread, I booted from the installation disc to run a fsck check on the filesystem. I received the following error:

fsck.ext4: Bad magic number in super-block while trying to open /dev/sda5

The superblock could not be read or does not describe a correct ext4
filesystem.  If the device is valid and it really contains an ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 / 32768 <device>
/dev/sda5 contains a crypto_LUKS file system

Following this thread, I tried using backup superblocks and received the same exact error. Now, I thought my drive was dead, but when I open file explorer I can browse through the filesystem like normal and see my files (I haven't tried opening or copying them yet). I don't know if this is normal but it doesn't seem very dead to me. Although the laptop/hdd is 13 years old with intermittent use the last 7 years, so I'm kind of asking for a failure at this point.

Following this thread in this forum and the answers by Gilles, I realized that my partition sectors are also mismatched.

sudo fdisk -l
/dev/sda2 1501182 156301311 154800130 73.8G Extended
/dev/sda5 1501184 156301311 154800128 73.8G Linux

However unlike the other user, when I run sudo tail -c +512 /dev/sda2 | file - I just get /dev/stdin: data.

How do I use GParted to modify the partition boundary? Or recreate it with fdisk, and will this delete my data? I don't have very much on there so I'll try to back it up if it's going to be wiped but it's not a big deal if I lose it.

zolt56
  • 13
  • 2

1 Answers1

2

Don't panic.

Note the message /dev/sda5 contains a crypto_LUKS file system.

If that's true, then you cannot directly run e2fsck on /dev/sda5, because it's encrypted. Everything on a LUKS-encrypted disk is encrypted, including superblocks and other filesystem metadata, so e2fsck cannot understand it at all.

You must first run cryptsetup luksOpen /dev/sda5 rescue, which will create /dev/mapper/rescue for accessing the contents of /dev/sda5 in decrypted form. It will prompt you for the encryption passphrase.

Only after cryptsetup luksOpen is successful, you can run e2fsck on it - not on the encrypted /dev/sda5, but on /dev/mapper/rescue instead.

If the filesystem check is successful, you can mount /dev/mapper/rescue to anywhere you want and then access it like a normal filesystem.

telcoM
  • 87,318
  • 3
  • 112
  • 232
  • +1, this looks like user error... and if there's any doubt regarding read errors, `ddrescue` to a new drive first – frostschutz Sep 22 '19 at 08:35
  • Thanks... I thought about LUKS briefly but should have payed more attention to that factor instead of just googling the first part or the error. This is all pretty new to me. Now I have another small problem: when I try to run fsck on /dev/mapper/rescue, it says "/dev/mapper/rescue is in use. Cannot continue, aborting". Umount says it's not mounted so not sure why this is happening. – zolt56 Sep 22 '19 at 09:20
  • @zolt56 there might be LVM in the mix too, or it might be mounted if you have some automount magic going on – frostschutz Sep 22 '19 at 11:33
  • @zolt56 indeed, try running `vgscan` then `pvs` to see if LVM has auto-detected anything on `/dev/mapper/rescue`. If it has, then `vgchange -ay` and the LVs should be mountable (see `lvs` for their names). If that is not it, `fuser -m /dev/mapper/rescue` should tell you which process is grabbing the device. – telcoM Sep 22 '19 at 11:36
  • Desktop environments might auto-mount any disks that they see appearing to `/media//` or similar, on the assumption that they might be USB or other removable disks. – telcoM Sep 22 '19 at 11:37