Several days ago, I gave you a tutorial on how to recover from a borked glibc, using tools available inside the installed system. We mentioned booting into a live session as the last but always viable option. Derefter, I thought of a little snag that may come your way. What if the installed system uses LVM?
Normally, you would just mount the root partition and then fix files and folders as needed. But what happens when you’re running LVM? The procedure as you know it no longer applies, and we need a new method. Let’s see what gives here.
LVM in action
The first step is to identify the right partition. Hence, fdisk or gdisk, depending on whether you have a classic ms-dos partition table or GPT. Either way, you should be able to get some useful info regarding your disk structure:
Disk /dev/sda: 16 GiB, 17179869184 bytes, 33554432 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8c1fab07
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 1026047 1024000 500M 83 Linux
/dev/sda2 1026048 33554431 32528384 15.5G 8e Linux LVM
Typically, LVM setups will have a small boot partition, which corresponds to /dev/sda1, and the the rest of the root under an LVM, which we can see falls under /dev/sda2 in our example. All right, naively, let’s try to mount it.
mount /dev/sda2 /mnt
mount: unknown filesystem type ‘LVM2_member’
The reason why this won’t work is because you’re trying to mount a container, much like the extended partition. So we will actually need to identify the mapped devices before we can mount them.
The name of the game: vgscan
We will now use LVM tools to manipulate this particular setup. LVM consists of volume groups (VG) and logical volumes (LV). Or first task is then to identify the volume group(s) that correspond to the /dev/sda2 setup. So we need vgscan to achieve that.
This particular utility may not be available on your particular distro, or you may not have the LVM kernel modules loaded into memory to allow you to use LVM. If this is the case, you may need to install the LVM tools first before you can proceed. Typically, vgscan comes as part of the lvm2 package. Derefter, run the following command:
Reading all physical volumes. This may take a while…
Found volume group “fedora” using metadata type lvm2
The tool will scan all physical volumes and then present the groups as new devices under the /dev tree. In our example, we have fedora, and this means that logical volumes that belong to this group will appear under /dev/fedora.
ls -l /dev/fedora/*
lrwxrwxrwx. 1 root root 7 Kan 7 10:26 /dev/fedora/root -> ../dm-4
lrwxrwxrwx. 1 root root 7 Kan 7 10:26 /dev/fedora/swap -> ../dm-3
We have root and swap, which makes sense, and they actually correspond to device mappers (dm) 3 og 4, respectively. In other words, you can mount these filesytems either by reference or directly. Derefter, the mount exercise becomes:
mount /dev/fedora/root /mnt
This will succeed – again, provided your distro supports whatever filesystem you’re using for the LVM root volume. Once mounted, you can manipulate the partition and its objects like you normally would, any which way.
This is a simple, quick tutorial. But it may save you some frustration. If you browse around, you will notice additional suggestions on running pvscan and vgchange, but you do not need those commands, especially if you do not intend to make any changes to the existing LVM setup – only the data stored on its volumes.
The LVM manipulation trick completes the exercise we started with busybox and LD_PRELOAD a while back. It gives you the full range of options to fix your system problems. Knowing that you can always fall back to the live session usage, and work from there, should give you a sense of peace. It means that if you ruin your Linux, well not too stringently, you can use all sorts of tricks to get back in the game. But don’t push your luck. And keep those backups up to date. See ya.