Bug 2338735

dnf config:

# see `man dnf.conf` for defaults and possible options

[main]
gpgcheck=True
installonly_limit=3
clean_requirements_on_remove=True
best=False
skip_if_unavailable=True
#exclude=lvm2*

I managed to work around most of my issue's, i suspect most stem from a lack of devicefiles, i'll investigate the failure to mount to mount the luks volume next weekend but it's probably unrelaated to lvm proper

did some more tests updating thesew packages render my /home unmountable'

Total download size: 3.0 M
Is this ok [y/N]: y
Downloading Packages:
(1/7): device-mapper-event-1.02.199-1.fc40.x86_ 212 kB/s |  33 kB     00:00    
(2/7): device-mapper-event-libs-1.02.199-1.fc40 182 kB/s |  31 kB     00:00    
(3/7): device-mapper-1.02.199-1.fc40.x86_64.rpm 701 kB/s | 136 kB     00:00    
(4/7): device-mapper-libs-1.02.199-1.fc40.x86_6 1.9 MB/s | 176 kB     00:00    
(5/7): lvm2-2.03.25-1.fc40.x86_64.rpm           6.0 MB/s | 1.5 MB     00:00    
(6/7): lvm2-dbusd-2.03.25-1.fc40.noarch.rpm     687 kB/s | 168 kB     00:00    
(7/7): lvm2-libs-2.03.25-1.fc40.x86_64.rpm      1.5 MB/s | 998 kB     00:00    
--------------------------------------------------------------------------------
Total                                           2.9 MB/s | 3.0 MB     00:01     

if i reboot after these updates i'm dropped into emergency mode and asked for my root password
doing vgchange -ay proerly activates my volume group and i can continue my boot process

If you require more information, let me know

Hi, could you please upload/post `lvmdump -su`

The lvmdump is here: https://we.tl/t-eI6GFYqE9J

The thing to check - is the use of 'devicesfile'

If such file '/etc/lvm/devices/system.devices'
(and lvm.conf   use_devicesfile  is 1)

then this file needs to have listed devices used by system.

Unsure how your upgrade was made - there was the idea if the 'file' does NOT exist and you have lvm.conf  which now defaults to 1 for Fedora builds,  lvm2 will still go with 'filters'.

However if the upgrade process has created  'devicesfile'  and BUT  has NOT imported all currently visible  PVs  (with lvmdevices/vgimportdevices) - then you may possibly end with a system which will not see a PV  ( as it's not enlisted in  devicesfile).

Number of solutions -  remove devicesfile and set use_devicesfile=0 
Or simply import visible PV to your devicesfile.

(In reply to Zdenek Kabelac from comment #6)
> The thing to check - is the use of 'devicesfile'
> 
> If such file '/etc/lvm/devices/system.devices'
> (and lvm.conf   use_devicesfile  is 1)
> 
> then this file needs to have listed devices used by system.
> 
> Unsure how your upgrade was made - there was the idea if the 'file' does NOT
> exist and you have lvm.conf  which now defaults to 1 for Fedora builds, 
> lvm2 will still go with 'filters'.
> 
> However if the upgrade process has created  'devicesfile'  and BUT  has NOT
> imported all currently visible  PVs  (with lvmdevices/vgimportdevices) -
> then you may possibly end with a system which will not see a PV  ( as it's
> not enlisted in  devicesfile).
> 
> Number of solutions -  remove devicesfile and set use_devicesfile=0 
> Or simply import visible PV to your devicesfile.

This tracks with what I observed with the f40 installer I did notice this in lvm.conf:
 # Allow LVM LVs to be used as PVs. When enabled, LVM commands will
        # scan active LVs to look for other PVs. Caution is required to
        # avoid using PVs that belong to guest images stored on LVs.
        # When enabled, the LVs scanned should be restricted using the
        # devices file or the filter. This option does not enable autoactivation
        # of layered VGs, which requires editing LVM udev rules (see LVM_PVSCAN_ON_LVS.)
        # This configuration option has an automatic default value.
        # scan_lvs = 0


How do i work with layered VG's? I recall having done that years ago to work with with a mirroreed cache? googling LVM_PVSCAN_ON_LVS didn't provide more information

This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle.
Changing version to 42.