commit 417e52c13a8156b11c25c411d44bda8b32bf87e4
Author: Peter Rajnoha <email address hidden>
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.
The following commit:
commit 417e52c13a8156b 11c25c411d44bda 8b32bf87e4
Author: Peter Rajnoha <email address hidden>
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 by-id/dm- name-.. . (which encompasses
VG UUID and LV UUID in case of LVs since the mapping's UUID is
VG+LV UUID together) and /dev/disk/
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 .5bb37d8ad 100644 ======= ======= ======= ======= == by-id/lvm- pv-uuid- <PV_UUID> symlink for each PV via udev. cluster in lvm2-monitor initscript/systemd unit. 69-dm-lvm- metad.rules. in b/udev/ 69-dm-lvm- metad.rules. in .bd75fc8ef 100644 69-dm-lvm- metad.rules. in 69-dm-lvm- metad.rules. in MULTIPATH_ DEVICE_ PATH}== "1", GOTO="lvm_end"
index 39e8b886a.
--- a/WHATS_NEW
+++ b/WHATS_NEW
@@ -1,5 +1,6 @@
Version 2.02.106 -
======
+ Create /dev/disk/
lvcreate computes RAID4/5/6 stripes if not given from # of allocatable PVs.
Fix merging of old snapshot into thin volume origin.
Use --ignoreskipped
diff --git a/udev/
index e8304b5e0.
--- a/udev/
+++ b/udev/
@@ -34,6 +34,9 @@ ENV{DM_
# 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 FS_UUID_ ENC}==" ?*", SYMLINK+ ="disk/ by-id/lvm- pv-uuid- $env{ID_ FS_UUID_ ENC}"
+ENV{ID_
+
# 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-mkdevicem ap.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.