summaryrefslogtreecommitdiff
path: root/udev
Commit message (Collapse)AuthorAgeFilesLines
* makefiles: avoid grepZdenek Kabelac2023-02-231-1/+1
| | | | | Avoid getting annoyting grep warning and use just awk to get the value.
* configure.ac: support systemd-run binary pathZdenek Kabelac2023-02-102-4/+4
| | | | | | | | | 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.
* configure.ac: remove some lvmetad leftoversZdenek Kabelac2023-02-102-135/+1
| | | | Remove unused parts of configure and udev rules since lvmetad is gone.
* udev: import previous results of blkid when in suspended stateYu Watanabe2023-02-071-2/+12
| | | | | | | | | | | | | | | | Follow-up for e10f67e91728f1e576803df884049ecbd92874d0. The commit e10f67e91728f1e576803df884049ecbd92874d0 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
* udev: remove rule for explicit creation of /dev/mapper/controlPeter Rajnoha2023-02-021-2/+0
| | | | | | | | | | | | 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.
* udev: don't reset SYSTEMD_READY in udev for PVs on MD and loopPeter Rajnoha2023-02-011-4/+0
| | | | | | | | | | | | | | | | | | | | | | | Since 67722b312390cdab29c076c912e14bd739c5c0f6, 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.
* Revert "makefiles: fix grep warning from make"dev-mcsontos-fix-make-rpmMarian Csontos2023-01-251-1/+1
| | | | | | This reverts commit 92199ad0b98586182a52e2f8cd82c06336e306f1. This breaks make rpm.
* makefiles: fix grep warning from makeZdenek Kabelac2023-01-161-1/+1
| | | | Remove unnecessary '\'.
* doc: fix typos in documentationSamanta Navarro2023-01-031-1/+1
| | | | Typos found with codespell.
* gitignore: updateZdenek Kabelac2022-09-071-0/+1
|
* udev: create symlinks and watch even in suspended stateMartin Wilck2022-01-311-0/+4
| | | | | | | | | | | | | | | 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>
* udev: remove -r from systemd-runDavid Teigland2021-12-141-1/+1
| | | | | | | | 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.)
* vgchange -aay: optimize device scan using pvs_online filesDavid Teigland2021-11-042-3/+3
| | | | | | | | | | | | | | | | | | | 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
* The path is known anyway and should be the bullet proof option.Christian Hesse2021-10-211-1/+1
| | | | Signed-off-by: Christian Hesse <mail@eworm.de>
* new udev autoactivationDavid Teigland2021-10-072-1/+88
| | | | | | | | | | | | | | 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>
* udev rule: remove lvmetad commentsDavid Teigland2020-11-251-12/+3
|
* udev: remove unsupported OPTIONS+="event_timeout" rulePeter Rajnoha2019-08-131-2/+0
| | | | | | | | | | | | 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
* udev: do not overwrite ID_MODEL in 69-dm-lvm-metad.rulesPeter Rajnoha2019-07-041-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* udev: 69-dm-lvm-metad.rules is still neededMarian Csontos2018-12-061-4/+1
|
* makefiles: updates for less verbosityZdenek Kabelac2018-11-291-2/+3
|
* udev: keep systemd vars on change event in 69-dm-lvm-metad.rules for systemd ↵Martin Wilck2018-04-172-15/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* udev: explicit pvscan rule in 69-dm-lvm-metad.rulesMartin Wilck2018-04-172-4/+22
| | | | | | | | | | | 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>
* udev: also create /dev/disk/by-part{label,uuid} and gpt-auto-root symlinksPeter Rajnoha2017-07-101-0/+3
| | | | | | | | | | | | | | | 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.
* makefiles: use configure varsZdenek Kabelac2017-02-141-1/+1
| | | | Use binaries found in configure.
* udev: rules: add comments explaining subsystem-specific rulesPeter Rajnoha2016-04-261-0/+14
|
* udev: rules: remove mpath from 10-dm.rules, superseded by 11-dm-mpath.rules ↵Peter Rajnoha2016-04-251-4/+0
| | | | | | | | | | | | | | (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
* makefiles: avoid using vpath for rules filesZdenek Kabelac2016-03-101-2/+1
| | | | | | | | | | | | | 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/)
* doc: change fsf addressZdenek Kabelac2016-01-211-1/+1
| | | | | Hmm rpmlint suggest fsf is using a different address these days, so lets keep it up-to-date
* udev: fix missing escape for +Zdenek Kabelac2015-08-121-1/+1
| | | | | Commit 3ea396e9d220cec55fd4e139be7ae486cb4ddb91 missed to escape + which is used by 'sed' as separator for 's'.
* udev: use += for SYSTEMD_WANTS instead of =Thomas Bächler2015-08-121-1/+1
| | | | | Instead of using = to override SYSTEMD_WANTS, use += to add the pvscan service.
* gitignore: Update for in-place build.Alasdair G Kergon2015-07-271-0/+5
|
* makefiles: compile files on makeZdenek Kabelac2014-04-181-0/+2
| | | | Make install should install already compiled/generated files.
* udev: run pvscan --cache via systemd-run in udev if the PV label is detected ↵Peter Rajnoha2014-03-051-1/+1
| | | | | | | | | | | | | | | | | 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.
* udev: create /dev/disk/by-id/lvm-pv-uuid-<PV_UUID> symlink for a PVPeter Rajnoha2014-02-181-0/+3
| | | | | | | | | | | | | | | | | 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.
* udev: drop cryptsetup specific rules from 10-dm.rulesPeter Rajnoha2014-01-221-2/+0
| | | | | | | | 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
* udev: clear temporary variable properlyPeter Rajnoha2014-01-201-1/+1
| | | | | | Clear temporary DM_DISABLE_OTHER_RULES_FLAG properly. This did not cause any bug or problem as the temporary variable is overwritten next time it's used again, but we should still clean it properly!
* udev: do not drop SYSTEMD_READY for non-activating eventsPeter Rajnoha2014-01-141-2/+2
| | | | | | | | | | | | Do not drop device's flag to report readiness for systemd processing if there's any event that follows the activatiion event itself. Otherwise, systemd would lost track of this device on any other event that follows the activating event (IOW, we need to make SYSTEMD_READY variable change level-based, not edge-based). This patch applies for MD and loop devices used as PVs. (intra-release fix for commit 4c267c7286145165dfe078f77d18d194a21a2e1c)
* udev: fix SYSTEMD_READY assignment for foreign devices in lvmetad rulesPeter Rajnoha2013-12-111-0/+5
| | | | | | | | | | | | | | Some devices, similarly to us, are not prepared after ADD event, but after an extra CHANGE event when the device is properly set up. This includes MD and loop devices. This patch fixes the SYSTEMD_READY assignment that is crucial for proper functionality of SYSTEMD_WANTS that we use to instantiate a lvm2-pvscan@.service systemd service to activate the VG/LVs (see also bug info). All that extra handling of foreign devices should eventually be moved to rules which process those devices primarily (MD and loop)! We should only check a dedicated variable whether the device is usable or not.
* udev: wrong line in previous commitPeter Rajnoha2013-10-301-1/+1
|
* udev: properly trigger LVM scan for MD partitionsPeter Rajnoha2013-10-301-0/+1
| | | | | | | | | | MD can directly create partition devices without a need to run an extra kpartx or partprobe call. We need to react to this event in a different way as for bare MD devices - we need to handle the ADD event for KERNEL=="md[0-9]*p[0-9]*" kernel name and trigger the LVM scanning to update lvmetad to trigger autoactivation and so on... Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1023250
* udev: no need to check DM_NOSCAN in lvmetad rulesPeter Rajnoha2013-10-291-1/+0
| | | | It's covered by general DM_UDEV_DISABLE_OTHER_RULES_FLAG.
* udev: proper reset of DM_UDEV_DISABLE_OTHER_RULES_FLAG and honour this flag ↵Peter Rajnoha2013-10-292-1/+2
| | | | | | | | | | | | | | | | | | in lvmetad rules Reset the DM_UDEV_OTHER_RULES_FLAG to original value right at the time of dropping the DM_NOSCAN flag. When DM_NOSCAN is set, the DM_UDEV_DISABLE_OTHER_RULES_FLAG is also set to avoid udev processing in "other/foreign" rules. If the noscan flag is dropped, the DM_UDEV_DISABLE_OTHER_RULES_FLAG should be reset to its original value. Also, lvmetad should respect the DM_UDEV_DISABLE_OTHER_RULES_FLAG because if the volume is set with this flag it: - definitely is not a top-level device (so makes no sense for lvmetad scanning) - is not supposed to be scanned further (for any stacking on top of it, including LVM stacking itself and any autoactivation of stacked LVs)
* make: correct sed line in udev's MakefilePeter Rajnoha2013-10-221-3/+1
|
* udev+systemd: refine lvm2-pvscan@.service to better track device existencePeter Rajnoha2013-10-221-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using ENV{SYSTEMD_WANTS}=lvm2-pvscan@... to instantiate a service for lvmetad scan when the new PV appears in the system, the service is started and executed. However, to track device removal, we need to bind it (the "BindsTo" systemd directive) to a certain .device systemd unit. In default systemd setup, the device is tracked by it's name and sysfs path (there's normally a sysfs path .device systemd unit for a device and then the device name .device unit as an alias for it). Neither of these two is useful for lvmetad update as we need to bind it to device's <major>:<minor> pair. The /dev/block/<major>:<minor> is the essential symlink under /dev that exists for each block device (created by default udev rules provided by udev directly). So let's use this as an alias for the device's .device unit as well by means of "ENV{SYSTEMD_ALIAS}" declaration within udev rules which systemd understands (this will create a new alias "dev-block-<major>:<minor>.device". Then we can easily bind the "dev-block-<major>:<minor>" device systemd unit with instantiated lvm2-pvscan@<major>:<minor>.service. So once the device is removed from the systemd, the lvm-pvscan@<major>:<minor>.service executes it's ExecStop action (which in turn notifies lvmetad about the device being gone). This completes the udev-systemd-lvmetad interaction then.
* udev+systemd: make pvscan --cache -aay run as systemd background job from udevPeter Rajnoha2013-10-182-2/+8
| | | | | | | | | | | | | | | | | | | The new lvm2-pvscan@.service is responsible for on-demand execution of "pvscan --cache --activate ay" which causes lvmetad to be updated and LVM activation done if the VG is complete. Also, use udev-systemd mechanism to instantiate the job as the lvm2-pvscan@$devnode.service on each newly appeared PV in the system. This prevents the background job to be killed (that would happen if it was directly forked from udev rule - this behaviour is seen in recent versions of udev with the help of systemd that can track detached processes - the detached process would still be in the same cgroup). To enable this official udev-systemd protocol for instantiating background jobs, use new --enable-udev-systemd-background-jobs configure switch (it's disabled by default). This option is highly recommended wherever systemd is used!
* udev: add support for "NOSCAN" flagPeter Rajnoha2013-10-083-1/+19
| | | | | | | | | | | Recognize DM_SUBSYSTEM_UDEV_FLAG0 which for LVM is the "LVM_NOSCAN" flag that causes the scanning to be skipped (mainly blkid) and also directs all the foreign rules to be skipped as well. Important thing here is that the "watch" udev rules is still set as well as the /dev/disk/by-id content created (which does not require any scanning to be done). Also, the flag is dropped on any subsequent event and scanning done...
* udev: make subsystem rules responsible for importing subsystem flagsPeter Rajnoha2013-09-301-8/+0
| | | | | | | Each subsystem rule that needs to import any of DM_SUBSYSTEM_UDEV_FLAG* flags is responsible for doing so. This simply moves control of these flags from general 10-dm.rules to any subsystem rule using these flags as each subsystem knows better how to handle these flags on its own.
* udev: fix 3min udev timeout so that it is applied for all LVM volumesPeter Rajnoha2013-09-271-2/+2
| | | | The timeout should be set before any volume skipping.
* udev: remove unused line in 69-dm-lvm-metad.rulesPeter Rajnoha2013-09-201-5/+1
| | | | | The explicit check for *_raid_member is not actually needed as this gets filtered out by the ENV{ID_FS_TYPE}!="LVM2_member|LVM1_member" rule.
* udev: keep DM_ACTIVATION and DM_UDEV_PRIMARY_SOURCE_FLAG meaning as before ↵Peter Rajnoha2013-09-122-10/+11
| | | | | | | | | commit 8d1d835 The DM_ACTIVATION and DM_UDEV_PRIMARY_SOURCE_FLAG needs to be kept the way it was for backward compatibility (e.g. the old rules are still in initramfs). This way the check in whether the device should be scanned in 69-dm-lvmetad.rules is even easier.
View Lorry Controller Status