Here’s the deal:
1)You have no time and you want to try the latest Fedora release because it looks pretty darn good.
2) You accept the default disk partitioning scheme which the kind people at Red Hat / Fedora project set up for you, because they only have your best interests at heart, right?
3) While using this cutting-edge release, something nasty happens like, ooh, perhaps a sound driver locks up the entire system and you have to hard-reset the machine (that is, switch it off by the power switch because nothing responds to input).
What next? If, like me (on one occassion) you try to boot up the machine and get no further than the recovery console, you’d feel a bit aggravated. But there is an alternative – do a disk check. You may have read my verbose coverage for How to do a disk check in Linux before. This takes it one step further – how to check your logical volume when it’s encrypted and formatted using the latest ext4 filesystem.
Instead of the method used before, this time I booted from a Live CD. You can find one to download at the Fedora project. Ensure that this CD matches the release of the version you are trying to recover. In this case, that’s Fedora 10.
Once you have booted the offending machine up with the Live CD, open up a terminal by pointing to Applications > System Tools > Terminal. Once in the terminal window, just type:
# su
…to become the root user. This is essential to using all the disk tools.
You may be tempted to check for volume groups first:
# vgscan
.. but this would return nothing.
What’s happening here is that the Volume Group, located on that partition, is itself encrypted. Once unlocked, you can then gain access to both of the Logical Volumes – the swap volume and the root (/) volume.
To unlock the encrypted Volume Group, first you need to establish which partition it resides on:
# fdisk /dev/sda
The number of cylinders for this disk is set to 12161.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Hit p to print the partitions on your primary disk:
Command (m for help): p
Disk /dev/sda: 100.0 GB, 100030242816 bytes
255 heads, 63 sectors/track, 12161 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xb07eb07e
Device Boot Start End Blocks Id System
/dev/sda1 * 1 5377 43190721 7 HPFS/NTFS
/dev/sda2 5378 5402 200812+ 83 Linux
/dev/sda3 5403 12161 54291667+ 8e Linux LVM
So the partiton of type “Linux LVM” (Logical Volume Managed) is the baby we’re after.
To unlock the encrypted Volume Group, use the following:
# cryptsetup luksOpen /dev/sda3 mydisk
This sets up the encryption/decryption kernel subroutines to allow access to device /dev/sda3, mapped to a device node called “mydisk” in /dev/mapper/ . We’ll not actually need to use this device node, but it could be handy to know if you needed to perform further diagnostics.
You will be prompted to enter the encryption key which is stored in one of eight “slots” on the disk. If the key you enter matches a key in any slot, your disk will become unlocked. Assuming that it is, you can then scan once again for Volume Groups:
# vgscan
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
Now we’re getting somewhere. Let’s activate the VG and display the LVs (Logical Volumes) it contains:
# vgchange -a y
2 logical volume(s) in volume group "VolGroup00" now active
# lvdisplay
--- Logical volume ---
LV Name /dev/VolGroup00/LogVol00
VG Name VolGroup00
LV UUID RE7t2h-nIy9-dWZ9-xt26-Fgq4-gFd8-34E3f2
LV Write Access read/write
LV Status available
# open 0
LV Size 47.81 GB
Current LE 1530
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:3
--- Logical volume ---
LV Name /dev/VolGroup00/LogVol01
VG Name VolGroup00
LV UUID B7XJzD-9sS0-3iHx-AWBE-W9qN-TvRb-vCdYZF
LV Write Access read/write
LV Status available
# open 0
LV Size 3.91 GB
Current LE 125
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:4
We can deduce from the sizes of these two volumes that the first of the two is the root (/) volume, and the second is the swap volume.
As the purpose is to FIX the filesystem on it, which may have become corrupt through the hard-reset performed earlier, we do not want to mount this volume. Instead, as we now have a device node for this activated volume, at /dev/VolGroup00/LogVol00, we can simply perform a disk check straight on it.
To check which extn file system checking tools are on the system, you can tab-complete at the command line:
# fsck.
(hit tab)
fsck.cramfs fsck.ext3 fsck.ext4dev fsck.vfat
fsck.ext2 fsck.ext4 fsck.msdos
As this was formatted an ext4 volume, that’s what we use:
# fsck.ext4 /dev/VolGroup00/LogVol00
esfsck 1.41.3 (12-Oct-2008)
/dev/VolGroup00/LogVol00: recovering journal
Clearing orphaned inode 730 (uid=0, gid=500, mode=0100600, size 2263160)
Clearing orphaned inode 187182 (uid=500, gid=500, mode=0100600, size 4096)
... and so on until ...
/dev/VolGroup00/LogVol00: clean, 190926/3137536 files, 2016683/12533760 blocks
Now there are two more steps to perform: de-activate the volume group, and lock the encryption of the drive.
# vgchange -a n
0 logical volume(s) in volume group "VolGroup00" now active
# cryptsetup luksClose mydisk
The second command returns nothing, which means it did not error (the disk is now encrypted and not writable-to without unlocking again).
I hope that helps someone with a sense for adventure but not enough time on their hands for when things go somewhat awry!