after bootup there is an inactive vg: lvscan inactive '/dev/lvm/home' [185.22 GiB] inherit ACTIVE '/dev/vg0/com' [<465.76 GiB] inherit ACTIVE '/dev/vg0/tm3k-release' [238.47 GiB] inherit I can make it active using: vgchange --sysinit -ay Comparing openrc and systemd I note that there is no vgchange -ay in systedm like there is in openrc To get thing working I just added: cat /etc/systemd/system/lvm2-monitor.service.d/override.conf [Service] ExecStart= ExecStart=/sbin/lvm vgchange --sysinit -ay ExecStart=/sbin/lvm vgchange --monitor y but this is perhaps not the right place Note, this only happen when you have several VGs like above.
Is /dev/lvm/home configure to be mounted anywhere at boot (via fstab)?
It looks like the volume group should be activated by /lib/udev/rules.d/69-dm-lvm-rules once all PVs have been activated via udev.
(In reply to Mike Gilbert from comment #1) > Is /dev/lvm/home configure to be mounted anywhere at boot (via fstab)? yes LABEL=HOME /home auto defaults,nofail,x-systemd.device-timeout=0 0 0
(In reply to Mike Gilbert from comment #2) > It looks like the volume group should be activated by > /lib/udev/rules.d/69-dm-lvm-rules once all PVs have been activated via udev. I don't have that file, which pkg should install it ?
(In reply to Joakim Tjernlund from comment #4) > (In reply to Mike Gilbert from comment #2) > > It looks like the volume group should be activated by > > /lib/udev/rules.d/69-dm-lvm-rules once all PVs have been activated via udev. > > I don't have that file, which pkg should install it ? ah, you meant 69-dm-lvm.rules
from 69-dm-lvm.rules: /sbin/lvm pvscan --cache --listvg --checkcomplete --vgonline --autoactivation event Command does not accept option: --autoactivation event. Command does not accept option: --listvg. Command does not accept option: --checkcomplete. Command does not accept option: --vgonline. Somewhat odd
What USE flags are enabled for sys-fs/lvm2? I wonder if you disabled udev.
(In reply to Joakim Tjernlund from comment #6) You need to pass a device node as the final parameter, which changes the behavior of the command.
(In reply to Mike Gilbert from comment #7) > What USE flags are enabled for sys-fs/lvm2? I wonder if you disabled udev. sys-fs/lvm2: USE=lvm readline systemd thin udev one data point, apparently this worked about a month ago, then the machine got an full update and now it does not.
how can I see what udev rules are triggered and the outcome of such rule?
Try this: udevadm test --action=add /dev/sda1 Replace /dev/sda1 with a block device on which an LVM PV resides.
(In reply to Mike Gilbert from comment #11) > Try this: > > udevadm test --action=add /dev/sda1 > > Replace /dev/sda1 with a block device on which an LVM PV resides. .... ID_FS_TYPE=crypto_LUKS ID_FS_USAGE=crypto .... That is different from "LVM2_member" which is used by udev rules: ENV{ID_FS_TYPE}!="LVM2_member", GOTO="lvm_end" ENV{DM_MULTIPATH_DEVICE_PATH}=="1", GOTO="lvm_end" ACTION=="remove", GOTO="lvm_end" I think this has always been so for our encrypted machines
Full env from udevadm test --action=add /dev/nvme0n1p4 DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:01:00.0/nvme/nvme0/nvme0n1/nvme0n1p4 DEVNAME=/dev/nvme0n1p4 DEVTYPE=partition DISKSEQ=10 PARTN=4 MAJOR=259 MINOR=6 SUBSYSTEM=block ACTION=add TAGS=:systemd: ID_SERIAL_SHORT=S41GNE0K744737 ID_WWN=eui.0025388781036ee0 ID_MODEL=SAMSUNG MZVLB256HAHQ-000L7 ID_REVISION=0L2QEXD7 ID_NSID=1 ID_SERIAL=SAMSUNG_MZVLB256HAHQ-000L7_S41GNE0K744737_1 ID_PATH=pci-0000:01:00.0-nvme-1 ID_PATH_TAG=pci-0000_01_00_0-nvme-1 ID_PART_TABLE_UUID=8795b439 ID_PART_TABLE_TYPE=dos .PART_SUFFIX=-part4 DEVLINKS=/dev/disk/by-id/nvme-SAMSUNG_MZVLB256HAHQ-000L7_S41GNE0K744737_1-part4 /dev/disk/by-uuid/6c1fe893-61b8-4f32-9790-466d1ccea306 /dev/disk/by-path/pci-0000:01:00.0-nvme-1-part4 /dev/disk/by-diskseq/10-part4 /dev/disk/by-id/nvme-eui.0025388781036ee0-part4 /dev/disk/by-id/nvme-SAMSUNG_MZVLB256HAHQ-000L7_S41GNE0K744737-part4 /dev/disk/by-partuuid/8795b439-04 ID_FS_VERSION=2 ID_FS_UUID=6c1fe893-61b8-4f32-9790-466d1ccea306 ID_FS_UUID_ENC=6c1fe893-61b8-4f32-9790-466d1ccea306 ID_FS_TYPE=crypto_LUKS ID_FS_USAGE=crypto ID_PART_ENTRY_SCHEME=dos ID_PART_ENTRY_UUID=8795b439-04 ID_PART_ENTRY_TYPE=0x8e ID_PART_ENTRY_NUMBER=4 ID_PART_ENTRY_OFFSET=111675392 ID_PART_ENTRY_SIZE=388442800 ID_PART_ENTRY_DISK=259:0 UDISKS_IGNORE=1 CURRENT_TAGS=:systemd: USEC_INITIALIZED=2764951 There is nothing in there that indicates lvm2. What/who controls these env vars? Seems to my some variable needs to be added that indicate LVM
If you are using lvm on top of luks, pass the crypt dm device to udevadm test.
(In reply to Mike Gilbert from comment #14) > If you are using lvm on top of luks, pass the crypt dm device to udevadm > test. udevadm test --action=add /dev/dm-0 ... m-0: /usr/lib/udev/rules.d/10-dm.rules:133 Added SYMLINK 'mapper/lvm-home' dm-0: /usr/lib/udev/rules.d/11-dm-lvm.rules:21 Importing properties from results of '/sbin/dmsetup splitname --nameprefixes --noheadings --rows lvm-home' dm-0: Starting '/sbin/dmsetup splitname --nameprefixes --noheadings --rows lvm-home' Successfully forked off '(spawn)' as PID 2029109. dm-0: '/sbin/dmsetup splitname --nameprefixes --noheadings --rows lvm-home'(out) 'DM_VG_NAME='lvm'' dm-0: '/sbin/dmsetup splitname --nameprefixes --noheadings --rows lvm-home'(out) 'DM_LV_NAME='home'' dm-0: '/sbin/dmsetup splitname --nameprefixes --noheadings --rows lvm-home'(out) 'DM_LV_LAYER=''' dm-0: Process '/sbin/dmsetup splitname --nameprefixes --noheadings --rows lvm-home' succeeded. dm-0: /usr/lib/udev/rules.d/11-dm-lvm.rules:45 Added SYMLINK 'lvm/home' dm-0: /usr/lib/udev/rules.d/13-dm-disk.rules:17 Added SYMLINK 'disk/by-id/dm-name-lvm-home' dm-0: /usr/lib/udev/rules.d/13-dm-disk.rules:18 Added SYMLINK 'disk/by-id/dm-uuid-LVM-PcyL0BuL2BxGfPVEJo05RIQrJIWDCqssaCnb0QgyeRjDTZs2rKiTFnrbfRL459n8' dm-0: /usr/lib/udev/rules.d/13-dm-disk.rules:25 Importing properties from results of builtin command 'blkid' dm-0: Probe /dev/dm-0 with raid and offset=0 dm-0: /usr/lib/udev/rules.d/13-dm-disk.rules:39 Added SYMLINK 'disk/by-uuid/3288f706-a9cd-4d95-911c-7d6150ac8ee1' dm-0: /usr/lib/udev/rules.d/13-dm-disk.rules:40 Added SYMLINK 'disk/by-label/HOME' dm-0: /usr/lib/udev/rules.d/50-udev-default.rules:88 GROUP 6 dm-0: Preserve permissions of /dev/dm-0, uid=0, gid=6, mode=0660 dm-0: Successfully created symlink '/dev/block/252:0' to '/dev/dm-0' dm-0: sd-device: Created db file '/run/udev/data/b252:0' for '/devices/virtual/block/dm-0' DEVPATH=/devices/virtual/block/dm-0 DEVNAME=/dev/dm-0 DEVTYPE=disk DISKSEQ=15 MAJOR=252 MINOR=0 SUBSYSTEM=block ACTION=add TAGS=:systemd: DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1 DM_UDEV_PRIMARY_SOURCE_FLAG=1 DM_UDEV_RULES_VSN=2 DM_ACTIVATION=1 DM_NAME=lvm-home DM_UUID=LVM-PcyL0BuL2BxGfPVEJo05RIQrJIWDCqssaCnb0QgyeRjDTZs2rKiTFnrbfRL459n8 DM_SUSPENDED=0 DEVLINKS=/dev/disk/by-id/dm-uuid-LVM-PcyL0BuL2BxGfPVEJo05RIQrJIWDCqssaCnb0QgyeRjDTZs2rKiTFnrbfRL459n8 /dev/mapper/lvm-home /dev/disk/by-label/HOME /dev/disk/by-uuid/3288f706-a9cd-4d95-911c-7d6150ac8ee1 /dev/lvm/home /dev/disk/by-id/dm-name-lvm-home DM_VG_NAME=lvm DM_LV_NAME=home DM_LV_LAYER= ID_FS_LABEL=HOME ID_FS_LABEL_ENC=HOME ID_FS_UUID=3288f706-a9cd-4d95-911c-7d6150ac8ee1 ID_FS_UUID_ENC=3288f706-a9cd-4d95-911c-7d6150ac8ee1 ID_FS_SIZE=198857035776 ID_FS_LASTBLOCK=48555008 ID_FS_BLOCKSIZE=4096 ID_FS_TYPE=xfs ID_FS_USAGE=filesystem CURRENT_TAGS=:systemd: SYSTEMD_READY=1 Something odd here, it is marked as LUKS but the the partion is not actually encrypted
I'm not sure /dev/dm-0 is the device we care about either. However, I don't know enough about LUKS and LVM to point you to the right place.
Could you run "blkid" as root so I can see what your devices actually look like?
(In reply to Mike Gilbert from comment #17) > Could you run "blkid" as root so I can see what your devices actually look > like? blkid /dev/nvme0n1p4 /dev/nvme0n1p4: UUID="6c1fe893-61b8-4f32-9790-466d1ccea306" TYPE="crypto_LUKS" PARTUUID="8795b439-04"
(In reply to Mike Gilbert from comment #16) > I'm not sure /dev/dm-0 is the device we care about either. However, I don't > know enough about LUKS and LVM to point you to the right place. Not sure what comes first either byt I guess /dev/nvme0n1p4 is before /dev/dm-0 ? To me it seems like 69-dm-lvm.rules is using the wrong test(ID_FS_TYPE), that is not an reliable test to see if there is an LVM there.
I wanted you to run blkid without arguments so I could see all block devices on the system.
(In reply to Mike Gilbert from comment #20) > I wanted you to run blkid without arguments so I could see all block devices > on the system. blkid /dev/nvme0n1p3: LABEL="ROOT" UUID="08681133-4481-4df9-9df8-57d10da000c5" BLOCK_SIZE="512" TYPE="xfs" PARTUUID="8795b439-03" /dev/nvme0n1p1: LABEL="BOOT" UUID="c60e5544-5602-404f-939d-c2c9ab0ae6d6" BLOCK_SIZE="1024" TYPE="ext4" PARTUUID="8795b439-01" /dev/nvme0n1p4: UUID="6c1fe893-61b8-4f32-9790-466d1ccea306" TYPE="crypto_LUKS" PARTUUID="8795b439-04" /dev/nvme0n1p2: LABEL="SWAP" UUID="c4d13076-0445-4c59-9dfc-7626a8123474" TYPE="swap" PARTUUID="8795b439-02" /dev/mapper/lvm-home: LABEL="HOME" UUID="3288f706-a9cd-4d95-911c-7d6150ac8ee1" BLOCK_SIZE="512" TYPE="xfs" /dev/nvme1n1p1: UUID="rwVyiv-d86z-4AvV-5ZvA-svM9-oPEM-FlunOP" TYPE="LVM2_member" PARTUUID="ed71a7bf-01" /dev/sda1: UUID="XMTRk2-exhy-0Cfv-NsrS-oft0-rdy4-NAE37X" TYPE="LVM2_member" PARTUUID="f965a86d-01" /dev/mapper/vg0-com: UUID="18ba6508-d73d-4873-96fd-f61f6703231c" BLOCK_SIZE="4096" TYPE="ext4" /dev/mapper/vg0-tm3k--release: UUID="b4f9e4ef-50a3-4394-9759-77b00e8a2390" BLOCK_SIZE="4096" TYPE="ext4" Is it possible to change TYPE="crypto_LUKS" back to TYPE="LVM2_member" ?
comparing with another computer: blkid /dev/nvme0n1p3: LABEL="ROOT" UUID="76ce31f5-d9ba-473a-ba58-f64d88bd89c6" BLOCK_SIZE="512" TYPE="xfs" PARTLABEL="ROOT" PARTUUID="1aaca76a-bfdb-4170-828e-bcf7a2028e67" /dev/nvme0n1p1: LABEL_FATBOOT="BOOT" LABEL="BOOT" UUID="D212-0360" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="BOOT" PARTUUID="414a848f-e35d-4ef1-a21f-40c976827089" /dev/nvme0n1p4: UUID="ea28b6ef-867a-490f-be9a-1dd9b1807460" TYPE="crypto_LUKS" PARTLABEL="LVM" PARTUUID="33d5ee1a-fb51-45b1-bce1-93c1c1c41236" /dev/nvme0n1p2: LABEL="SWAP" UUID="b9ef0cfd-dfb1-4ff7-8179-5f80d91db1ac" TYPE="swap" PARTLABEL="SWAP" PARTUUID="1ebabf5b-41c2-4f33-8b17-49142a1bbf55" /dev/mapper/lvm-home: LABEL="HOME" UUID="0c5b9b87-f455-4c2f-88fd-2c33f3b2e775" BLOCK_SIZE="512" TYPE="xfs" /dev/mapper/crypt-lvm: UUID="uuFW7y-N4jH-Jpmg-Teu5-Wfc0-2eLN-WdF6Iu" TYPE="LVM2_member" So my problem machine has an half way LUK conversion where TYPE="crypto_LUKS" but no /dev/mapper/crypt-lvm: UUID="uuFW7y-N4jH-Jpmg-Teu5-Wfc0-2eLN-WdF6Iu" TYPE="LVM2_member" Not ideal, lvm works anyway but the udev detection does not
(In reply to Joakim Tjernlund from comment #22) > So my problem machine has an half way LUK conversion What does that mean? Did you set /dev/nvme0n1p4 as a LUKS volume and then switch it to be an unencrypted LVM PV? If so, this seems like a problem specific to your system. You will need to figure out how to remove the LUKS metadata from /dev/nvme0n1p4. The "wipefs" command should be helpful for that.
(In reply to Mike Gilbert from comment #23) > (In reply to Joakim Tjernlund from comment #22) > > So my problem machine has an half way LUK conversion > > What does that mean? Did you set /dev/nvme0n1p4 as a LUKS volume and then > switch it to be an unencrypted LVM PV? I am guessing, this is not my system and the guy having it does not known either :( > > If so, this seems like a problem specific to your system. You will need to > figure out how to remove the LUKS metadata from /dev/nvme0n1p4. The "wipefs" > command should be helpful for that. wipefs /dev/nvme0n1p4 DEVICE OFFSET TYPE UUID LABEL nvme0n1p4 0x4000 crypto_LUKS 6c1fe893-61b8-4f32-9790-466d1ccea306 nvme0n1p4 0x218 LVM2_member bGdJom-zjz2-rT21-I0X0-hw7B-4iWy-JMxWzG wipefs /dev/nvme0n1p4 -n -o 0x4000 -f /dev/nvme0n1p4: 6 bytes were erased at offset 0x00004000 (crypto_LUKS): 53 4b 55 4c ba be Does that look OK to you(the -n is a dry-run option) ? Then I should have the LVM2_member left I think
(In reply to Joakim Tjernlund from comment #24) > wipefs /dev/nvme0n1p4 -n -o 0x4000 -f > /dev/nvme0n1p4: 6 bytes were erased at offset 0x00004000 (crypto_LUKS): 53 > 4b 55 4c ba be > > Does that look OK to you(the -n is a dry-run option) ? > > Then I should have the LVM2_member left I think Looks good to me. Note that I take no legal responsibility for any data loss that may occur. I think it's safe, but don't sue me if I'm wrong.
Not sure I would call this issue invalid. The dynamic udev rules does not handle all combos and could possibly be improved. Running vgchange --sysinit -ay finds the missing VG
(In reply to Joakim Tjernlund from comment #26) From perspective, the storage setup was erroneous. If you feel differently, please raise the issue upstream to lvm2 or util-linux. It's nothing we are going to fix at a distro level.
(In reply to Mike Gilbert from comment #27) > (In reply to Joakim Tjernlund from comment #26) > > From perspective, the storage setup was erroneous. If you feel differently, > please raise the issue upstream to lvm2 or util-linux. It's nothing we are > going to fix at a distro level. FYI, upstream ticket: https://gitlab.com/lvmteam/lvm2/-/issues/11
Stable needs patch https://github.com/util-linux/util-linux/commit/93ba7961779789217a1f814ce3110ff8c040c8c3 See https://gitlab.com/lvmteam/lvm2/-/issues/11#note_1817139956 for details.
(In reply to Joakim Tjernlund from comment #29) > Stable needs patch > https://github.com/util-linux/util-linux/commit/ > 93ba7961779789217a1f814ce3110ff8c040c8c3 > > See https://gitlab.com/lvmteam/lvm2/-/issues/11#note_1817139956 for > details. Oh, forgot: The patch is for util-linux:
Ah, thanks for following up!
The linked revert should appear in util-linux-2.40.
(In reply to Mike Gilbert from comment #32) > The linked revert should appear in util-linux-2.40. Yes, but considering the consequences of this bug(non booting systems) I would apply it to current 2.39.3 and stable that.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5f364406d48c2e886059080044c3259a14d4bb5a commit 5f364406d48c2e886059080044c3259a14d4bb5a Author: Sam James <sam@gentoo.org> AuthorDate: 2024-03-18 13:34:04 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-03-18 13:42:49 +0000 sys-apps/util-linux: backport fix for LVM2 metadata parsing, basename w/ musl-1.2.5 Closes: https://bugs.gentoo.org/926293 Closes: https://bugs.gentoo.org/926950 Signed-off-by: Sam James <sam@gentoo.org> .../files/util-linux-2.39.3-libblkid-luks.patch | 40 ++ .../util-linux-2.39.3-musl-1.2.5-basename.patch | 56 +++ sys-apps/util-linux/util-linux-2.39.3-r4.ebuild | 413 +++++++++++++++++++++ 3 files changed, 509 insertions(+)
