The latest Fedora build of lvm is installing: /usr/lib/systemd/system/lvm-devices-import.path /usr/lib/systemd/system/lvm-devices-import.service These are intended to run on first boot to create a new /etc/lvm/devices/system.devices file for a system that does not have one. The devices used by the root VG will be included in the new system.devices. The device entries in system.devices are specific to the system's hardware, e.g. wwid or serial numbers of disks. This is needed when the OS is installed via an image, rather than directly by anaconda. When anaconda installs a new system, it runs vgimportdevices to create a new system.devices file for the new system. More background info can be found in bug 2247872. Answering other questions I've seen in bugs for recently added presets: * Does the service require post-rpm-installation configuration in order to be useful (for example, does it need manual edits to a configuration file)? No * Does the service listen on a network socket for connections originating on a separate physical or virtual machine? No * Is the service non-persistent (i.e. run once at startup and exit)? Yes * What is the exact name (or names) of the systemd unit files to be enabled? /usr/lib/systemd/system/lvm-devices-import.path /usr/lib/systemd/system/lvm-devices-import.service * Is this request for all Fedora deliverables or only for some Editions (list them)? rawhide, Fedora server Reproducible: Always
> * Is this request for all Fedora deliverables or only for some Editions > (list them)? > > rawhide, Fedora server Just to clarify: this question is asking whether it should be limited to just some of the Editions/Spins or it's applicable to all deliverables. I suspect you don't mean to limit it to Fedora Server Edition here, but I need to ask since that's what you wrote.
It applies when lvm is used for the root fs, but I'm not sure if that's a complete answer or not. i.e. is "root fs on lvm" a property of a fedora edition, or maybe it depends?
LVM is the default configuration on Fedora Server, whereas btrfs is the default configuration on Workstation and others. However, the user can set up any filesystem layout they want in the custom partitioning stage of anaconda, so it could be used anywhere.
I wonder if limiting to Server might be close enough. If anaconda is doing the install, it creates system.devices, so this feature isn't needed in that case. This is mainly addressing cases where a system is installed from an image, i.e. anaconda isn't doing the install on the end system. Is there a way to enable this based on whether it's an OS image or not?
Let me flip that question around: is the service harmful if it's run on a system that already has system.devices? Looking at the service, it has `ConditionPathExists=!/etc/lvm/devices/system.devices` which means it should effectively do nothing at all if it's installed on a system that already has these devices. Is there a problem if it's installed on a system without LVM? Will it run every time and do nothing (or worse, something harmful) if it's on bare partitions or btrfs?
Right, nothing should happen if system.devices already exists, so enabling the path and service should have no effect. I've just been hesitant to broadly enable anything unnecessary for the large majority of cases. I actually forgot to include another detail which narrows this further: lvm-devices-import.path is only triggered if the system has been pre-populated with an empty file /etc/lvm/devices/auto-import-rootvg. Some unknown OS image preparation step would need to do this to enable the auto creation. I'd originally thought that enabling the service might be done in the same preparation step as creating this empty file (perhaps that's still an option once I learn more about how that image prep works.) The entire flow is described in the commit header: https://sourceware.org/git/?p=lvm2.git;a=commit;h=c609dedc2f035f770b5f645c4695924abf15c2ca But, enabling these widely should not have any unwanted impact, if there's no downside to enabling an unused service (which I don't know.)
You didn't answer the question about what happens if the service tries to run on a system with no LVM configuration. (For example, one with btrfs partitions). It will presumably never have a /etc/lvm/devices/system.devices file.
If lvm-devices-import.service runs, it runs "vgimportdevices --rootvg --auto" which will look for an lvm root LV, and will do nothing when it finds none.
(In reply to David Teigland from comment #8) > If lvm-devices-import.service runs, it runs "vgimportdevices --rootvg > --auto" which will look for an lvm root LV, and will do nothing when it > finds none. OK, and if the service is "enabled", the result is that it will run and do nothing on every boot? That seems slightly wasteful, but not on its own worth disabling the service. I can see a possible situation where we might actually want this to run on a new boot if someone were to add a new drive with existing partitions on it. I'm coming down on the side of enabling this for all installs, so I'm just trying to figure out what it will do in various situations.
OK, even if enabled it will not usually run on boot because: lvm-devices-import.service is triggered by lvm-devices-import.path which is triggered by the creation of /run/lvm/lvm-devices-import which is created by "vgchange -aay --autoactivation event <rootvg>" which is triggered by udev rules which are triggered by an LVM root device being attached. That chain of causation will not even begin if there is no device attached with an LVM root. For systems that *do* have LVM root, that chain will usually be broken because either - /etc/lvm/devices/system.devices already exists, or - the system is likely not pre-populated with the file /etc/lvm/device/auto-import-rootvg.
Yeah, I think enabling for all installs should be ok.
Merge request: https://src.fedoraproject.org/rpms/fedora-release/pull-request/338