[TriLUG] when good filesystems go bad

Dan Somers via TriLUG trilug at trilug.org
Fri Jan 4 14:08:14 EST 2019


Hey TRILUG folks - hoping I might find some ray of hope for recovery here.
I've been banging my head against all the wrong walls.

Here's the situation:

Virtual disk attached to a running centos6 VM - let's call this virtual
disk /dev/vdb

parted:
 select /dev/vdb
 mklabel gpt
 mkpart primary 0% 100%
 print

all looks well - there's a GPT disklabel and a single primary partition on
it.

Then things go sideways.

'mke2fs -t ext4 /dev/vdb' gets run instead of 'mke2fs -t ext4 /dev/vdb1'

'blkid' doesn't show a /dev/vdb at all after this. So without going back
into parted and creating a new partition table and partition on /dev/vdb,
'mke2fs -t ext4 /dev/vdb1' is run. Of course that first mke2fs run without
specifying the partition number should have wiped out the partition and the
disklabel since it laid down an ext4 filesystem on the raw device. There
should have been no /dev/vdb1 on which to lay down an ext4 filesystem when
the second mke2fs was run that correctly included the partition number. But
that second mke2fs ran without complaint.

After this, 'blkid' actually shows a /dev/vdb1 with its own UUID that was
copied and pasted into fstab.

Mounting the volume at the path specified in fstab worked - it was a normal
ext4 filesystem. In fact this normally-behaving ext4 filesystem may have
hypothetically been used for several months and come to accumulate some
data.

Then the VM was rebooted.

When it came back up, the volume did not mount. Trying to mount it manually
shows "special device UUID-blahblahblah does not exist", and 'blkid' no
longer shows that UUID. Instead there is a new UUID shown, as /dev/vdb
instead of /dev/vdb1 .

parted still shows a single partition on /dev/vdb containing an ext4
filesystem, but partition table "loop" and not "gpt".

mount /dev/vdb1 --> "special device /dev/vdb1 does not exist"

mount /dev/vdb --> "wrong fs type, bad option, bad superblock, etc"

mount -o loop,ro,noexec,noload /dev/vdb <mountpoint> --> "stale file handle"

Anybody have any ideas how an attempt at recovery might be made?

TIA for any input!

Best,

-Dan


More information about the TriLUG mailing list