The following commit: commit 417e52c13a8156b11c25c411d44bda8b32bf87e4 Author: Peter Rajnoha <prajn...@redhat.com> Date: Tue Feb 18 07:27:21 2014
udev: create /dev/disk/by-id/lvm-pv-uuid-<PV_UUID> symlink for a PV We already have /dev/disk/by-id/dm-uuid-... (which encompasses the VG UUID and LV UUID in case of LVs since the mapping's UUID is VG+LV UUID together) and /dev/disk/by-id/dm-name-... (which encompasses the VG and LV name in case of LVs). This patch addds /dev/disk/by-id/lvm-pv-uuid-<PV_UUID> that completes this scheme and makes navigation a bit easier using PV UUIDs since one can navigate using PV UUIDs only and there's no need to do extra PV UUID <--> kernel name matching (the PV UUID is stable across reboots). This may come in handy in various scripts. Since we already have the PV UUID stored in udev database (as a result of blkid call - returned in ID_FS_UUID blkid's variable), this operation is very cheap indeed, just creating the extra one symlink. diff --git a/WHATS_NEW b/WHATS_NEW index 39e8b886a..5bb37d8ad 100644 --- a/WHATS_NEW +++ b/WHATS_NEW @@ -1,5 +1,6 @@ Version 2.02.106 - ==================================== + Create /dev/disk/by-id/lvm-pv-uuid-<PV_UUID> symlink for each PV via udev. lvcreate computes RAID4/5/6 stripes if not given from # of allocatable PVs. Fix merging of old snapshot into thin volume origin. Use --ignoreskippedcluster in lvm2-monitor initscript/systemd unit. diff --git a/udev/69-dm-lvm-metad.rules.in b/udev/69-dm-lvm-metad.rules.in index e8304b5e0..bd75fc8ef 100644 --- a/udev/69-dm-lvm-metad.rules.in +++ b/udev/69-dm-lvm-metad.rules.in @@ -34,6 +34,9 @@ ENV{DM_MULTIPATH_DEVICE_PATH}=="1", GOTO="lvm_end" # Inform lvmetad about any PV that is gone. ACTION=="remove", GOTO="lvm_scan" +# Create /dev/disk/by-id/lvm-pv-uuid-<PV_UUID> symlink for each PV +ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="disk/by-id/lvm-pv-uuid-$env{ID_FS_UUID_ENC}" + # If the PV is a special device listed below, scan only if the device is # properly activated. These devices are not usable after an ADD event, # but they require an extra setup and they are ready after a CHANGE event. was the one responsible to add the change that causes: /dev/disk/by-id/ to be populated with the LVM volume (not the entire disk), breaking the current installer logic. There are 2 alternatives here: To revert this change for current release, since this rule was added to "make navigation a bit easier using PV UUIDs", as the commit says. We would worry about installer changes in the next release. Another possibility would be to change the logic inside "grub-mkdevicemap.c: make_device_map()->grub_util_iterate_devices()" to ignore all symlinks from /dev/disk/by-id/ containing lvm-pv-uuid-*. We would not have to worry about this in the next release if using debian-installer. I'm choosing this option because ubuntu foundations already faced a similar situation, when grub-mkdevicemap.c file was removed from grub2 code and they re-added it by using a quilt patch, assuming it was the easiest and better to maintain. I'm doing something similar, patching the patch that creates grub-mkdevicemap.c file again. Another option would be to change grub-installer package/logic. Unfortunately, a few days before the full freeze, I don't think messing with the instaler would be a good option to avoid regressions (potential regression item would grow in significance). So I'm going with (2) and providing a MR for Eoan to be reviewed in a few moments. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1838525 Title: LVM setup fails to install grub on virtio storage Status in debian-installer package in Ubuntu: In Progress Status in grub2 package in Ubuntu: In Progress Status in lvm2 package in Ubuntu: In Progress Status in debian-installer package in Debian: New Bug description: Comment #26 has the TL;DR version of the problem. https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1838525/comments/26 [Original Description] The Eoan debian-installer ISO fails to install GRUB on LVM installs with virtio storage, as it runs grub-install with /dev/mapper as a target (a directory), even if instructed to target a device. The following steps to reproduce have been prepared running the 20190730 build, but this has been broken since about June 18, 2019. Steps to reproduce: $ md5sum eoan-server-amd64.iso f591e30485e5f0b5117f6c116e538c42 eoan-server-amd64.iso $ qemu-img create -f raw disk1.img 8G Formatting 'disk1.img', fmt=raw size=8589934592 $ kvm -m 1024 -boot d -cdrom eoan-server-amd64.iso -drive file=disk1.img,if=virtio Proceed with all the defaults. In the "Partition disk" step select "Guided - use entire disk and set up LVM". Go ahead accepting the defaults. At the "Install the GRUB boot loader" step select "/dev/vda" as the target device. The installer will actually run `grub-install --force /dev/mapper` and fail after a while. The wrong command is visible both in the d-i screen and by running `ps` on a different console. Full installer syslog: http://paste.ubuntu.com/p/qtZy86dTp6/ It's interesting how this doesn't happen when not using virtio. If from the commands above the "if=virtio" option is dropped then everything works as expected. In this case the target block device is called /dev/sda instead of /dev/vda. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1838525/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp