fscking an encrypted partition
 

Hi all,

I have set up a while back an encrypted reiserfs /home partition which is running just fine using cryptoloop. My only problem is that I am unable to fsck this partition, even if I remount it read-only. Reiserfsck complains that it cannot find the reiserfs superblock. I can understand why this would happen when the partition isn't mounted, but why doesn't it work when the password has been entered either?

I would really like to be able to check the partition, because my computer tends to freeze occasionally (buggy ati driver...) :(

Thanks for your time!

You could try unmounting your /home partition and then use losetup manually to bring it up. When you have /home mounted normally you can use losetup to find out what encryption is being used. Try something like:

# losetup /dev/loopN

For my setup for example the output looks like:

# losetup /dev/loop0
/dev/loop0: [0006]:452 (/dev/hda6) offset 0, AES128 encryption

The loop device may be different for your configuration. I do the following to check my /home:

# losetup -e AES128 /dev/loop0 /dev/hda6
Password:
# fsck.ext3 -f /dev/loop0

I don't mount the loop device on /home because fsck seems to complain when you do that even if it's read-only. Since you're using reiserfs then you'd use "reiserfsck" instead of "fsck.ext3". After you check the filesystem remember to detach the loop device with something like:

# losetup -d /dev/loop0

In my case the reason that "fsck" and even "dump" get confused is because of a trick that my system (Mandrake) uses when it mounts an encrypted filesystem. I found that the information written to /etc/mtab wasn't strictly correct and that filesystem tools seemed to be using that instead of /proc/mounts.

EDIT:
Fixed fsck line to be /dev/loop0.

Thanks for your quick reply.

It worked without a hitch (with the tiny exception that I had to fsck /dev/loop0 not /dev/hda5 or it wouldn't find the superblock there either).

Thanks!

I meant to write "fsck.ext3 -f /dev/loop0" but wrote the partition device instead by mistake. I've fixed it now for future reference.