LVM: How to access a foreign volume group

[Volker Wysk]

Hi

I've used these instructions (in German): 
https://www.thomas-krenn.com/de/wiki/LVM_Caching_mit_SSDs_einrichten

I've worked it out, although there were some issues, which needed fixing. It works now, in a virtual machine.

What you've described in you mail, below, looks familiar to me:


Am Samstag, 9. Dezember 2017, 21:32:40 CET schrieb Xen:
> Volker Wysk schreef op 04-12-2017 2:03:
> 
> > I'm about to set up an LVM cache (for my encrypted root file system).
> 
> I suggest the following in /etc/initramfs-tools/hooks/dmcache:
> 
> -----------
> #!/bin/sh
> 
> if [ "$1" = "prereqs" ]; then
>      exit 0
> fi
> 
> . /usr/share/initramfs-tools/hook-functions
> 
> # pdata_tools is the cache_check executable
> copy_exec /usr/sbin/pdata_tools
> 
> # you have to use relative symlinks here:
> for f in /usr/sbin/cache*; do ln -sr ${DESTDIR}/usr/sbin/pdata_tools 
> ${DESTDIR}$f; done
> 
> # safest is just to copy all of the device mapper modules:
> copy_modules_dir kernel/drivers/md
> -----------
> 
> But I assume you have already done this?

The procedure, which I've followed, involves something similar. See above.

 
> > It would be bad, if I had to restore it from a backup, because I have
> > installed and configured a lot of things.
> 
> The greatest risk is that the logical volume for root is not activated 
> because of a missing module or executable in your initrd.

Precisely. That's what I've encountered.


> > How to instruct LVM to operate on another installation? When I start
> > the rescue system, which I've installed on an USB stick, I can access
> > only the native LVM installation, like it should be.
> 
> That's because your main system is encrypted.
> 
> Otherwise LVM would start destroying your system (maybe).
> 
> > Also, both volume groups have the same name.
> 
> Yes you won't be able to activate both volume groups very well until you 
> rename the one in the rescue system.
> 
> This isn't very hard.
> 
> BEFORE you do any cryptsetup open on the main system, run:
> 
> vgrename kubuntu-vg rescue-vg
> 
> Then you must verify that /etc/fstab in the RESCUE system contains no 
> references to "kubuntu-vg" and you might also have to rerun 
> "update-grub" if you want to keep it this way.
> 
> That is all you need to do to rename the volume group.
> 
> After that you can open the crypt and it won't conflict.

Yes, that's what I was looking for. However, for now I'll use a non-encrypted, non-LVM rescue system.

 
> > Because I installed both
> > from the Kubuntu 16.04 install ISO (from an USB stick), and this
> > assigns "kubuntu-vg" to the VG name.
> 
> You are wise to say so, the LVM of 16.04 is not very good with 
> conflicts.
> 
> (16.10 is better).
> 
> 
> Make sure /etc/initramfs-tools/hooks/dmcache is executable:
> 
> chmod +x /etc/initramfs-tools/hooks/dmcache
> 
> Also rerun update-initramfs -u.
> 
> After, verify that the initramfs contains everything you need:
> 
> lsinitramfs /boot/initrd* | grep "pdata\|cache"
> 
> It has to contain at least:
> 
> usr/sbin/cache_restore
> usr/sbin/cache_repair
> usr/sbin/cache_metadata_size
> usr/sbin/cache_dump
> usr/sbin/cache_check
> usr/sbin/pdata_tools
> lib/modules/4.10.0-40-generic/kernel/drivers/md/dm-cache-cleaner.ko
> lib/modules/4.10.0-40-generic/kernel/drivers/md/dm-cache-smq.ko
> lib/modules/4.10.0-40-generic/kernel/drivers/md/dm-cache.ko
> 
> Or similar.
> 
> I assume you will be running this from your installed system. So you 
> have only one chance to get it right before you need to reboot into the 
> live or rescue environment.

Yeah. That's what I've encountered...

> 
> If you end up on an initrd prompt (busybox) because your system doesn't 
> boot, try to run:
> 
>    vgchange -ay
>    vgchange -ay
> 
>    exit
> 
> To continue booting.


Volker