Solution to issues with moving disks between Linux systems
Recently, I had to attach the disk from another Linux system because my user had lost its ‘sudo’ permission. When trying to mount the root partition, I got the not-too-helpful error message:
mount: unknown filesystem type 'LVM2_member'
The reason for this is that a standard Linux installation uses LVM for the partitions, and surprisingly-stupid-enough gives every installation the same name of the volume group, “ubuntu-vg”, so it will collide with the running sysems VG with the same name.
The procedure
Shut down the computer you are going to transfer the disk from, then remove the disk.
(for a virtual one, you just have to keep it shut down during this operation)
Shut down (not needed for virtual) the computer which will have the disk connected and connect the disk.
Start up or reboot the computer with the disks (now with the same VG name)
(a virtual server/computer might not need to be rebooted at all, check with ‘dmesg’ if the other disk was found)
This is usually the first thing one would try for getting access to a disk from another computer. This will fail (with the error message this post is all about):
root@ubu-04:~# fdisk -l /dev/xvdb ... Device Start End Sectors Size Type /dev/xvdb1 2048 4095 2048 1M BIOS boot /dev/xvdb2 4096 2101247 2097152 1G Linux filesystem /dev/xvdb3 2101248 33552383 31451136 15G Linux filesystem ..
The partition that will be mounted on /boot is directly mountable and accessible now:
root@ubu-04:~# mkdir disk root@ubu-04:~# mount /dev/xvdb2 disk root@ubu-04:~# ls disk/ config-5.4.0-176-generic initrd.img-5.4.0-182-generic vmlinuz config-5.4.0-182-generic initrd.img.old vmlinuz-5.4.0-176-generic grub lost+found vmlinuz-5.4.0-182-generic initrd.img System.map-5.4.0-176-generic vmlinuz.old initrd.img-5.4.0-176-generic System.map-5.4.0-182-generic
The partition with the rest of the content will give the not-so-useful error message:
root@ubu-04:~# mount /dev/xvdb3 disk mount: /root/disk: unknown filesystem type 'LVM2_member'. root@ubu-04:~#
lvscan identifies there is a problem:
root@ubu-04:~# lvscan inactive '/dev/ubuntu-vg/ubuntu-lv' [<15.00 GiB] inherit ACTIVE '/dev/ubuntu-vg/ubuntu-lv' [10.00 GiB] inherit root@ubu-04:~#
Fix by renaming the VG
The solution I used to access the content on the attached disk was to give the VG a non-conflicting name. This can be whatever you choose, but I simply added the hostname which this disk belongs to:
Be sure to rename the correct one:
Getting the VG UUID of the one to rename can be done a couple of ways. If you do this before removing the disk you want to access on the other computer, just use the command 'vgdisplay' show the ID:
root@test-1:~# vgdisplay --- Volume group --- VG Name ubuntu-vg System ID Format lvm2 ... VG UUID 90blAq-ggmA-rmsf-mBqU-3mRH-oxoS-lys4ih
or, if you found this post after stumbling on the same problem that I did, you can find the ID by using 'lvscan' on the computer with the two identical VG names:
root@ubu-04:~# lvscan -v Cache: Duplicate VG name ubuntu-vg: Prefer existing fSauMy-cW75-PFje-cx8s-rpUR-zYgd-PL9Bef vs new 90blAq-ggmA-rmsf-mBqU-3mRH-oxoS-lys4ih inactive '/dev/ubuntu-vg/ubuntu-lv' [<15.00 GiB] inherit ACTIVE '/dev/ubuntu-vg/ubuntu-lv' [10.00 GiB] inherit root@ubu-04:~#
Rename VG and rescan
root@ubu-04:~# vgrename 90blAq-ggmA-rmsf-mBqU-3mRH-oxoS-lys4ih ubuntu-vg-test-1 Processing VG ubuntu-vg-test-2 because of matching UUID 90blAq-ggmA-rmsf-mBqU-3mRH-oxoS-lys4ih Volume group "90blAq-ggmA-rmsf-mBqU-3mRH-oxoS-lys4ih" successfully renamed to "ubuntu-vg-test-1" root@ubu-04:~# modprobe dm-mod root@ubu-04:~# vgchange -ay 1 logical volume(s) in volume group "ubuntu-vg-test-1" now active 1 logical volume(s) in volume group "ubuntu-vg" now active root@ubu-04:~# lvscan ACTIVE '/dev/ubuntu-vg-test-1/ubuntu-lv' [<15.00 GiB] inherit ACTIVE '/dev/ubuntu-vg/ubuntu-lv' [10.00 GiB] inherit root@ubu-04:~#
Now the partition should be mountable:
root@ubu-04:~# mount /dev/ubuntu-vg-test-1/ubuntu-lv disk/ root@ubu-04:~# ls disk/ bin dev lib libx32 mnt root snap sys var boot etc lib32 lost+found opt run srv tmp cdrom home lib64 media proc sbin swap.img usr root@ubu-04:~#
Do whatever you need to do with that partition mounted (in my case, repairing sudo access for my user by adding it on the 'sudo' entry in the /etc/group file), then shut down the computer with the two disks, detacht the disk and reattach it to the computer it came from (or simply start the virtual machine which the disk came from).
Making the system bootable when the disk is put back where it belongs
Now that the VG was renamed, the system on that disk will no longer boot because it cannot mount the root partition. If you try, you will get dumped into the very limited busybox shell.
In the busybox shell, do this to make the system boot:
cd /dev/mapper mv ubuntu--vg--test--1-ubuntu--lv ubuntu--vg-ubuntu--lv exit
The system will now boot up. To make the new VG name permanent (so this 'rename' thing in busybox will not be needed on every reboot), change the old VG name to the new name in '/boot/grub/grub.cfg'
sed -i s/ubuntu--vg/ubuntu--vg--test--1/g grub.cfg
The easiest method creating a (per machine) unique VG name
If the system you are taking the disk from is still in working condition, and you are able to make yourself root using 'sudo' (which I lost on one machine for some unexplained reason, probably caused by a normal update Google search for 'lost+sudo+after+update' ), change the VG name and adjust grub.cfg while everything works..
root@test-2:~# vgdisplay |grep UUID VG UUID 8jzFk6-QlL8-xXL9-LJth-Qo1r-ACve-2KUmxP root@test-2:~# vgrename 8jzFk6-QlL8-xXL9-LJth-Qo1r-ACve-2KUmxP ubuntu-vg-$(hostname) root@test-2:~# sed -i s/ubuntu--vg/ubuntu--vg--$(hostname|sed s/-/--/g)/g grub.cfg