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.

This message is a reminder that Fedora Linux 42 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '42'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 42 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 42 entered end-of-life (EOL) status on 2026-05-27.

Fedora Linux 42 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.