On Thu, 2023-11-16 at 09:10 -0600, David Teigland wrote: > On Thu, Nov 16, 2023 at 02:37:13PM +0100, Zdenek Kabelac wrote: > > > and restore define DEFAULT_USE_DEVICES_FILE 1. > > > > There is no problem with configuring DEFAULT_USE_DEVICES_FILE with > > 'configure --with-default-use-devices-file= 0/1' and thus no need > > to change > > anything here. > > > > Current upstream has set this default value as 0 (in configure.ac) > > I didn't realize you'd changed the default, please set it back to 1. > (Even better put back DEFAULT_USE_DEVICES_FILE; configured settings > are a pain to deal with, and the complexity causes real problems.) The problem I see with using system.devices by default is that it requires installer support, as discussed previously. pvcreate will create the file if it doesn't find existing VGs or PVs, which means that the way LVM behaves depends on the system's history: - If it was updated from an earlier LVM version, VGs are likely to exist, and system.devices will not be created. - If VGs were created by the installer without copying system.devices into the installed system, system.device won't be created, either. - If the users installs without LVM and uses pvcreate later on, LVM will create system.devices, and switch to system.devices mode - Not sure what happens if the system is running in "legacy" filtering / multipath component detection mode and something goes wrong during boot, causing the PVs and VGs not to show up. If pvcreate is run in a situation like that, would it also create system.devices and switch modes? Distributions can of of course flip the default, but unless I'm mistaken RHEL9 (and possibly Fedora) are the only distros that fully support system.devices mode just yet. Thus I vote for leaving it off by default just now. Regards Martin
