In today's Rawhide, openQA's installer LVM resize test failed: https://openqa.fedoraproject.org/tests/1904073 . anaconda is failing on an error in lvm:
pyanaconda.modules.common.errors.general.AnacondaError: Failed to call the 'Resize' method on the '/com/redhat/lvmdbus1/Lv/0' object: GDBus.Error:org.freedesktop.DBus.Python.dbus.exceptions.DBusException: ('com.redhat.lvmdbus1.Lv', 'Exit code 5, stderr = The LV must be active to safely reduce (see --fs options.)')
Steps to Reproduce:
1.Using Fedora-Rawhide-20230422.n.0, attempt an install during which an existing LVM LV is reduced in size to make space for the new installation.
The installer crashes early in the install process with a dialog "An unknown error has occurred". anaconda.log shows the error above.
The install should succeed.
lvm2 went from lvm2-2.03.20-3.fc39 to lvm2-2.03.21-1.fc39 in the affected compose. The constraint itself is not new in 2.03.21, I checked - it was already present in 2.03.20. So presumably some other change in 2.03.21 causes the constraint to be hit (the LV to be considered not "active") when before it was not.
CCing vtrefny for the anaconda/blivet side of this.
This is a new feature in LVM -- inactive LVs cannot be resized to prevent people accidentally shrinking inactive LVs with XFS and destroying their data in the process. This is not an issue in the installer, blivet takes care of resizing the filesystem first when needed/applicable. We have a fix for this in upstream, I need to backport it to Fedora. I am not sure why this didn't show in openQA before, the feature should be present in LVM 2.03.19 which was build in rawhide 2 months ago.
Any news on that backport? This is still failing every day.
I am sorry, I completely forgot about this. I built a new version of libblockdev for rawhide with the patch included, hopefully it will fix this issue.
The 'install_resize_lvm' job passed with the latest rawhide build so I am closign this as fixed. Sorry again for taking that long.
Yeah, I think we're good, thanks. The blivet test is actually a better reproducer - the regular custom partitioning one only failed *sometimes* on this, for some reason, the blivet one seemed to fail every time. But both passed today, so looks good. thanks!