1
0
mirror of git://sourceware.org/git/lvm2.git synced 2024-12-28 11:22:15 +03:00
Commit Graph

118 Commits

Author SHA1 Message Date
Zdenek Kabelac
21b215ee63 udev: disable suffix handling
The idea in the patch 6e6d4c62b for handling -suffix as
indication of private device needs to be disabled.

Some problematic cases are currently not resolvable and some
more thinking is needed.

Once fixed, we can revert this patch.
2024-06-25 23:18:07 +02:00
Peter Rajnoha
6e6d4c62b3 udev: ignore private LVM devs in udev and systemd
We automatically ignore these devs, when lvm2 create devs,
whoever when lvm2 database is dropped or someone just
created these devs with such formated UUID, there is no
other informantion then to check DM UUID.
2024-06-03 15:30:05 +02:00
Zdenek Kabelac
6ec84993bd makefiles: avoid using # with awk
Also awk got annoyed by this \# char sequence which is reported
as incorrect, however older rpm builder were failing without this.
So let's just try other variant.
2024-04-08 14:52:23 +02:00
Zdenek Kabelac
88ad83e3d6 makefiles: use SHOW 2024-04-08 14:52:23 +02:00
Peter Rajnoha
f09a992720
udev: create /dev/disk/by-label symlinks for DM devs that have crypto as next layer
We already create /dev/disk/by-uuid symlinks for DM devices which
contain crypto-type as next layer (as identified by blkid).

Also create /dev/disk/by-label symlinks as the labels can be
defined for crypto-type devices too.

Reported and fix suggested by: Patrick Plenefisch <simonpatp@gmail.com>
See also:
https://lore.kernel.org/lvm-devel/CAOCpoWfYjOVNJNt+cnOVXDHiDq2wRogTqBijcUoa7chqOLRa5Q@mail.gmail.com/
2024-03-25 10:30:25 +01:00
Daan De Meyer
eb4f744820 Upstream db_persist udev rule from dracut
Setting db_persist is required for dm devices so that their properties
are carried over on switch-root from the initrd to the rootfs. This
logic has always lived in dracut
(https://github.com/dracutdevs/dracut/blob/master/modules.d/90dm/11-dm.rules).
However, this means that other initramfs generators each have to
implement and maintain the same rule which leads to unnecessary
duplication.

Instead, let's make the rule part of the upstream lvm rules, which
will ensure that generated initramfses will just work if they make
sure the lvm udev rules are installed, without having to figure out
that they have to add an extra rule themselves on top.

Identical rule in Arch Linux's lvm2 package: https://gitlab.archlinux.org/archlinux/packaging/packages/lvm2/-/blob/main/11-dm-initramfs.rules?ref_type=heads
2024-03-25 08:04:00 +00:00
Peter Rajnoha
48188d7181 udev: change action check from ACTION!="add|change" to ACTION=="remove"
For DM devices, the add/change/remove can appear as action for genuine
udev events.

However, there are more action types (bind, unbind, move, online, offline)
which never appear as actions for genuine DM udev events, but they can
still be synthesized (e.g. by writing "<action>" to "/sys/.../uevent" file
or by calling "udevadm trigger --action=<action>").

Let's also process these extra action types so that the udev-related content
is not lost completely, keeping all the symlinks and udev db entries just like
this was a synthetic udev event with "change" action.

Related to https://gitlab.com/lvmteam/lvm2/-/issues/4.
2024-03-25 07:57:33 +00:00
Martin Wilck
038f9254d9 10-dm.rules: bump DM_UDEV_RULES_VSN to 3
Bump the rules version in order to indicate that upper level rules
should consume DM_UDEV_DISABLE_OTHER_RULES_FLAG rather than DM_NOSCAN
and DM_SUSPENDED.

Also update the comments at the top of the file that describe the
exported properties, and add a note about internal device-mapper
properties.

Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Peter Rajnoha <prajnoha@redhat.com>
2024-03-25 07:31:36 +00:00
Martin Wilck
a196752969 dm udev rules: don't export and save DM_NOSCAN
DM_NOSCAN is not an official API any more and doesn't have to be
restored from the udev db. Rename it to .DM_NOSCAN.

Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Peter Rajnoha <prajnoha@redhat.com>
2024-03-25 07:31:36 +00:00
Martin Wilck
21ca92c432 dm udev rules: don't export and save DM_SUSPENDED
DM_SUSPENDED is a device-mapper internal flag, which is not intended to be
used by other rules, and which is determined by 10-dm.rules from sysfs for
every uevent. Rename it to ".DM_SUSPENDED", so that it won't be saved in the
udev database.

Known consumers of DM_SUSPENDED are 66-kpartx.rules (from multipath-tools) and
99-systemd.rules (from systemd). These will have to be adapted.
11-dm-mpath.rules will be changed to use .DM_SUSPENDED.

Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Peter Rajnoha <prajnoha@redhat.com>
2024-03-25 07:31:36 +00:00
Martin Wilck
2b2f11a74c 11-dm-lvm.rules: don't restore DM_UDEV_DISABLE_OTHER_RULES_FLAG from db
DM_UDEV_DISABLE_OTHER_RULES_FLAG is used as the "output" flag of the
device-mapper rules, to be consumed by non-dm rules. It is a logical OR of
several conditions that might make dm devices inaccessible. 10-dm.rules
calculates it for every uevent, whether it's genuine or spurious.

DM_SUBSYSTEM_UDEV_FLAG0 is just another flag that needs to be or'd in. We
don't need to restore the previous state of DM_UDEV_DISABLE_OTHER_RULES_FLAG.
Actually, doing so is wrong if the flag has previously been set because the
device was suspended, and the device isn't suspended anymore.

Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Peter Rajnoha <prajnoha@redhat.com>
2024-03-25 07:31:36 +00:00
Martin Wilck
f98d020ead 10-dm-rules: don't restore DM_UDEV_DISABLE_OTHER_RULES_FLAG from db
We use DM_UDEV_DISABLE_OTHER_RULES_FLAG to tell upper non-DM layers
to keep their hands off the device in question, for any reason.
One possible reason is that the device is supended; another is that
the cookie carries the flag of the same name.

DM_SUSPENDED is not restored from the db, but evaluated anew for every
uevent. Therefore DM_UDEV_DISABLE_OTHER_RULES_FLAG shouldn't be
restored, either. Use a new variable DM_COOKIE_DISABLE_OTHER_RULES_FLAG
to save and restore the original value from the cookie.

Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Peter Rajnoha <prajnoha@redhat.com>
2024-03-25 07:31:36 +00:00
Martin Wilck
0fe2d778aa 10-dm.rules: test DISK_RO after importing properties
DISK_RO is set in the environment of a block-device uevent if and only if
the read-only (ro) attribute of the device just changed (the kernel
function set_disk_ro() was called). It is not synoymous with the "ro" sysfs
attribute; the device could very well be write-protected if DISK_RO is not
set. Device mapper-level probing is possible for DISK_RO events, but it makes
little sense, because the device propreties haven't changed as far as dm is
concerned. But we should import possible previously set device properties
to avoid confusing follow-up rules. We should do this for both DISK_RO=1
and DISK_RO=0 events.

Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Peter Rajnoha <prajnoha@redhat.com>
2024-03-25 07:31:36 +00:00
Martin Wilck
6f44e1093c 13-dm-disk.rules: import ID_FS_TYPE
ID_FS_TYPE is the most important udev property for most follow-up
rules. It must be imported from the udev db if blkid can't be run.

Signed-off-by: Martin Wilck <mwilck@suse.com>
Reviewed-by: Peter Rajnoha <prajnoha@redhat.com>
2024-03-25 07:31:36 +00:00
David Teigland
ee73875ff0 udev: ignore LVs containing PVs
If LVM LVs happen to contain PVs, they are passed to the lvm udev
rule for processing, where they should be ignored.  PVs on LVs
most likely belong to VM images, and don't belong to the host
which sees the LV.  It's unsafe for the host to use these PVs.
Without this change, the LV would be processed by pvscan which
would generally ignore it, either because of the devices file,
or because of the default lvm policy to not consider LVs as
potential PVs.  This change makes the udev rule consistent
with that policy and avoids the unnecessary system messages
produced when pvscan ignores the LV.
2024-02-08 14:51:46 -06:00
Zdenek Kabelac
e0c95f15a7 makefiles: avoid grep
Avoid getting annoyting grep warning and use just awk to get the
value.
2023-02-23 16:46:35 +01:00
Zdenek Kabelac
391138ff30 configure.ac: support systemd-run binary path
Allow users to specify their path to systemd-run binary:

configure --with-systemd-run=/my/path/system-run

By defaults it autodetected in $PATH and fallbacks to:
/usr/bin/systemd-run.
2023-02-10 20:54:05 +01:00
Zdenek Kabelac
042fbd43d2 configure.ac: remove some lvmetad leftovers
Remove unused parts of configure and udev rules since lvmetad is gone.
2023-02-10 17:50:27 +01:00
Yu Watanabe
94f77a4d8d
udev: import previous results of blkid when in suspended state
Follow-up for e10f67e917.

The commit e10f67e917 tries to keep device
node symlinks even if the device is in the suspended state. However,
necessary properties that may previously obtained by the blkid command
were not imported at least in the .rules file. So, unless ID_FS_xyz
properties are imported by another earlier .rules file, the device node
symlinks are still lost when event is processed in the suspended state.

Let's explicitly import the necessary properties.

RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=2158628
GHPR: https://github.com/lvmteam/lvm2/pull/105
2023-02-07 09:37:27 +01:00
Peter Rajnoha
8498874147
udev: remove rule for explicit creation of /dev/mapper/control
We used KERNEL=="device-mapper", NAME="/dev/mapper/control" udev rule to
create the /dev/mapper/control file. The "NAME" rule should be only used
to rename network devices, otherwise udev issues a warning message. The
device-mapper driver has proper DEVNAME=/dev/mapper/control propagated
in the uevent environment when it is loaded so we don't need further
instruction on where to create the node - udev knows already.

Also, these days, it is created directly by kernel inside devtmpfs.
This makes the NAME="/dev/mapper/control" rule completely obsolete.
2023-02-02 15:41:47 +01:00
Peter Rajnoha
e7c8a82506
udev: don't reset SYSTEMD_READY in udev for PVs on MD and loop
Since 67722b3123, we have a new mechanism
to run the autoactivation from udev. With this change, we also replaced
the way the LVM autoactivation service is instantiatiated - instead of
setting the SYSTEM_WANTS udev variable (which systemd read and then
instantiated the service), we're now directly instantiating the
transient 'lvm-activate-<vgname>' service by calling systemd-run.

As such, we don't need to bother with setting the SYSTEMD_READY variable
for foreign devices anymore (in this case, MD and loop devices on top of
which there's a PV).

Before, we set the SYSTEMD_READY variable to make sure that the SYSTEMD_WANTS
is applied correctly - the service instantiation was edge-triggered by
flipping the SYSTEMD_READY from 0 to 1 and at the same time having the
SYSTEMD_WANTS variable set to the service name to instantiate. We're
using systemd-run now so this condition does not apply anymore.

Also, it was not completely correct to set SYSTEMD_READY for foreign
devices because there might be cases where this could cause issues,
see also https://github.com/lvmteam/lvm2/issues/94.
2023-02-01 14:46:52 +01:00
Marian Csontos
49c650423a Revert "makefiles: fix grep warning from make"
This reverts commit 92199ad0b9.

This breaks make rpm.
2023-01-25 09:46:18 +01:00
Zdenek Kabelac
92199ad0b9 makefiles: fix grep warning from make
Remove unnecessary '\'.
2023-01-16 12:37:40 +01:00
Samanta Navarro
aec5e573af doc: fix typos in documentation
Typos found with codespell.
2023-01-03 16:09:58 +01:00
Zdenek Kabelac
6b05d6bd83 gitignore: update 2022-09-07 15:00:15 +02:00
Martin Wilck
e10f67e917 udev: create symlinks and watch even in suspended state
If a dm device is suspended, we can't run blkid on it. But earlier
rules (e.g. 11-dm-parts.rules) might have imported previously scanned
properties from the udev db, in particular if the device had been correctly
set up beforehand (DM_UDEV_PRIMARY_SOURCE_FLAG==1). Symlinks for existing
ID_FS_xyz properties must be preserved in this case. Otherwise lower-priority
devices (such as multipath components) might take over the symlink
temporarily.

Likewise, we should't stop watching a temporarily suspended, but previously
correctly configured dm device.

Signed-off-by: Martin Wilck <mwilck@suse.com>
2022-01-31 14:55:20 +01:00
David Teigland
fbd8b0cf43 udev: remove -r from systemd-run
If the transient service remains after it's done, then
it prevents the same transient service from being run
again later if the PVs are detached and reattached
(although the behavior of a second autoactivation is not
well defined and may only work in limited cases.)
2021-12-14 11:57:13 -06:00
David Teigland
d558b3ad7e vgchange -aay: optimize device scan using pvs_online files
Port the old pvscan -aay scanning optimization to vgchange -aay.
The optimization uses pvs_online files created by pvscan --cache
to derive a list of devices to use when activating a VG.  This
allows autoactivation of a VG to avoid scanning all devices, and
only scan the devices used by the VG itself.  The optimization is
applied internally using the device hints interface.

The new option "--autoactivation event" is given to pvscan and
vgchange commands that are called by event activation.  This
informs the command that it is being used for event activation,
so that it can apply checks and optimizations that are specific
to event activation.  Those include:

- skipping the command if lvm.conf event_activation=0
- checking that a VG is complete before activating it
- using pvs_online files to limit device scanning
2021-11-04 11:08:38 -05:00
Christian Hesse
221e75316f The path is known anyway and should be the bullet proof option.
Signed-off-by: Christian Hesse <mail@eworm.de>
2021-10-21 16:33:23 -05:00
David Teigland
67722b3123 new udev autoactivation
new udev rule 69-dm-lvm.rules replaces
69-dm-lvm-meta.rules and lvm2-pvscan.service

udev rule calls pvscan directly on the added device

pvscan output indicates if a complete VG can be activated

udev env var LVM_VG_NAME_COMPLETE is used to pass complete
VG name from pvscan to the udev rule

udev rule uses systemd-run to run vgchange -aay <vgname>
2021-10-07 12:42:31 -05:00
David Teigland
10a095a58b udev rule: remove lvmetad comments 2020-11-25 16:57:54 -06:00
Peter Rajnoha
125f27ac37 udev: remove unsupported OPTIONS+="event_timeout" rule
The OPTIONS+="event_timeout" is Unsupported since systemd/udev version 216,
that is ~5 years ago.

Since systemd/udev version 243, there's a new message printed if unsupported
OPTIONS value is used:

  Invalid value for OPTIONS key, ignoring: 'event_timeout=180'

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1740666
2019-08-13 15:18:30 +02:00
Peter Rajnoha
fef8e50689 udev: do not overwrite ID_MODEL in 69-dm-lvm-metad.rules
We've been assigning this in 69-dm-lvm-metad.rules:

  ENV{ID_MODEL}="LVM PV $env{ID_FS_UUID_ENC} on /dev/$name"

This was for the description to appear for each systemd device
unit representing this device, for example:

  $systemctl -a | grep "LVM PV"
  dev-block-252:2.device                                                                                         loaded    active   plugged   LVM PV JhxC7B-YTgk-3jIU-5GVo-c4gV-W8t3-UUz06p on /dev/vda2 2
  dev-disk-by\x2did-lvm\x2dpv\x2duuid\x2dJhxC7B\x2dYTgk\x2d3jIU\x2d5GVo\x2dc4gV\x2dW8t3\x2dUUz06p.device         loaded    active   plugged   LVM PV JhxC7B-YTgk-3jIU-5GVo-c4gV-W8t3-UUz06p on /dev/vda2 2
  ...

However, there could be an actual ID_MODEL that people are interested in
more than the fact that this is an LVM PV and so we shouldn't overwrite
the value.

Also, we already have a symlink /dev/disk/by-id/lvm-pv-uuid-<PV_UUID>
created which is then reflected as device unit (all device's symlinks
have systemd device unit representation) so we can still reach this
information in systemd unit listings even without setting the ID_MODEL.

Reported here: https://github.com/lvmteam/lvm2/issues/21
2019-07-04 12:57:55 +02:00
Marian Csontos
21784e94d6 udev: 69-dm-lvm-metad.rules is still needed 2018-12-06 10:50:42 +01:00
Zdenek Kabelac
ceb2f0ad3b makefiles: updates for less verbosity 2018-11-29 23:05:43 +01:00
Martin Wilck
7a7b8a7778 udev: keep systemd vars on change event in 69-dm-lvm-metad.rules for systemd reload
The current logic that avoids setting SYSTEMD_ALIAS and SYSTEMD_WANTS
on "change" events is flawed in the default "systemd background job"
configuration. For systemd, it's important that device properties don't
change spuriously.

If an "add" event starts lvm2-pvscan@.service for a device, and a
"change" event follows, removing SYSTEMD_ALIAS and SYSTEMD_WANTS from the
udev db, information about unit dependencies between the device and the
pvscan service can be lost in systemd, in particular if the daemon
configuration is reloaded.

Steps to reproduce problem:

- create a device with an LVM PV
- remove device
- add device (generates "add" and "change" uevents for the device)
  (at this point SYSTEMD_ALIAS and SYSTEMD_WANTS are clear in udev db)
- systemctl daemon-reload
  (systemd reloads udev db)
- vgchange -a n
- remove device

=> the lvm2-pvscan@.service for the device is still active although the
device is gone.

- add device again

=> the PV is not detected, because systemd sees the lvm2-pvscan@.service
as active and thus doesn't restart it.

The original purpose of this logic was to avoid volumes being scanned
over and over again. With systemd background jobs, that isn't necessary,
because systemd will not restart the job as long as it's active.

Signed-off-by: Martin Wilck <mwilck@suse.com>
2018-04-17 11:38:12 +02:00
Martin Wilck
99bfbbf229 udev: explicit pvscan rule in 69-dm-lvm-metad.rules
Make the distinction between the cases with and without systemd
background jobs explicit in 69-dm-lvm-metad.rules rather than
substituting the rule from the Makefile. At this stage,
this improves only readibility, at the cost of one GOTO statement.

This patch introduces no functional change to the udev rules.

Signed-off-by: Martin Wilck <mwilck@suse.com>
2018-04-17 11:32:52 +02:00
Peter Rajnoha
c48149cf80 udev: also create /dev/disk/by-part{label,uuid} and gpt-auto-root symlinks
The blkid we call in 13-dm-disk.rules also returns identifiers for
partitions based on which the /dev/disk/by-part{uuid,label} and
gpt-auto-root symlinks should be created in the same manner as we
already create symlinks for filesystem labels and uuids.

This is because we handle blkid calls and symlink creation under
/dev/disk ourselves in our 13-dm-disk.rules for device-mapper devices
for us to have more control over this process.

See also https://lists.freedesktop.org/archives/systemd-devel/2017-July/039220.html
and original report http://tracker.ceph.com/issues/19489 for
the exact case where these symlinks were missing.
2017-07-10 12:36:39 +02:00
Zdenek Kabelac
fc0e49297d makefiles: use configure vars
Use binaries found in configure.
2017-02-14 10:24:56 +01:00
Peter Rajnoha
ecae76c713 udev: rules: add comments explaining subsystem-specific rules 2016-04-26 12:57:37 +02:00
Peter Rajnoha
2bb33aaf55 udev: rules: remove mpath from 10-dm.rules, superseded by 11-dm-mpath.rules (mpath>=0.6.0)
Multipath 0.6.0 contains new 11-dm-mpath.rules which supersede the rule
that was in 10-dm.rules. The 11-dm-mpath.rules are also more complete,
fixing several other issues. Using the new 11-dm-mpath.rules from
multipath-tools >= 0.6.0 is strongly recommended for proper
DM multipath functionality!

See also:
  http://christophe.varoqui.free.fr
  http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=multipath/11-dm-mpath.rules
2016-04-25 14:55:54 +02:00
Zdenek Kabelac
86a23b2145 makefiles: avoid using vpath for rules files
Fixing vpath usage as it has been checking for existance of
generated file also in the $(scrdir) e.g.:

No need to remake target '10-dm.rules.in'; using VPATH name '...'

If the $(srcdir) had been also $(builddir) and contained already
generated rules file, it's been used instead generating new
one.

(See: http://make.mad-scientist.net/papers/how-not-to-use-vpath/)
2016-03-10 18:38:53 +01:00
Zdenek Kabelac
fcbef05aae doc: change fsf address
Hmm rpmlint suggest fsf is using a different address these days,
so lets keep it up-to-date
2016-01-21 12:11:37 +01:00
Zdenek Kabelac
0f45aa7f31 udev: fix missing escape for +
Commit 3ea396e9d2 missed to escape +
which is used by 'sed' as separator for 's'.
2015-08-12 19:46:44 +02:00
Thomas Bächler
3ea396e9d2 udev: use += for SYSTEMD_WANTS instead of =
Instead of using = to override SYSTEMD_WANTS, use += to add
the pvscan service.
2015-08-12 09:33:06 +02:00
Alasdair G Kergon
3934ade5a2 gitignore: Update for in-place build. 2015-07-27 13:18:35 +01:00
Zdenek Kabelac
2b748e3118 makefiles: compile files on make
Make install should install already compiled/generated files.
2014-04-18 16:38:49 +02:00
Peter Rajnoha
2c42f60890 udev: run pvscan --cache via systemd-run in udev if the PV label is detected lost
If the PV label is lost (e.g. by doing a dd on the device), call
"systemd-run pvscan --cache <major>:<minor>" in 69-dm-lvm-metad.rules
to inform lvmetad about this state.

The reason for this is that ENV{SYSTEMD_WANTS}="lvm2-pvscan@<major>:<minor>"
logic will not cause the pvscan to be fired in this case since this works
only on proper device addition/removal cycle - the lvm2-pvscan service's
ExecStop is called only on proper REMOVE event - the service is bound to
device existence. Hence we need pvscan call via systemd-run (that
instantiates a quick transient service just to call the command).

See also https://bugzilla.redhat.com/show_bug.cgi?id=1063813.
2014-03-05 14:30:58 +01:00
Peter Rajnoha
417e52c13a 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.
2014-02-18 11:37:20 +01:00
Peter Rajnoha
36a09cf463 udev: drop cryptsetup specific rules from 10-dm.rules
These udev flags are set directly in cryptsetup for some
time now so there's no need to have it in our rules then.

See also:
https://code.google.com/p/cryptsetup/source/detail?spec=svn4f14b43a3d3e7310465005c401f37e19f8cb85e6&r=4f14b43a3d3e7310465005c401f37e19f8cb85e6
2014-01-22 15:18:57 +01:00