Created attachment 1680578 [details]
Description of problem:
Blivet is unable to resize LVM partitions that have been created by previous installations of Fedora and reports an error. However, I can resize the partitions using custom partitioning.
Version-Release number of selected component (if applicable):
Fedora 32, RC 1.4
Steps to Reproduce:
1. Install Fedora Workstation and choose automatic partitioning. This way, the partition layout will use the LVM.
2. Run another installation, but this time, choose Blivet as a partitioning method and try to resize the LVs.
3. The action is rejected with "This device cannot be resized." (see screenshot)
LVs can only be resized using custom partitioning
Blivet is able to resize current LVs and make place for more partitions.
In storage.log, some relevant info is shown:
INFO:program:Running... resize2fs -P /dev/mapper/live-base
INFO:program:Couldn't find valid filesystem superblock.
INFO:program:b'resize2fs 1.45.5 (07-Jan-2020)'
INFO:program:b'resize2fs: Operation not permitted while trying to open /dev/mapper/live-base'
DEBUG:program:Return code: 1
WARNING:blivet:Failed to obtain minimum size for device /dev/mapper/live-base: failed to gather info from resize program: 1
Created attachment 1680579 [details]
Created attachment 1680580 [details]
Created attachment 1680581 [details]
Proposed as a Blocker for 32-final by Fedora user lruzicka using the blocker tracking app because:
I am proposing this because in my opinion it violates the release criteria in
"Custom Partitioning", especially for:
When using both the installer-native and the blivet-gui-based custom partitioning flow, the installer must be able to:
Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes, and/or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions
Note, we actually have a specific criterion for resizing (implying it's not covered in the 'generic' partitioning criterion):
"Any installer mechanism for resizing storage volumes must correctly attempt the requested operation."
Huh. I can reproduce this, but somehow it's failing slightly differently for me: I get "dumpe2fs: No such file or directory while trying to open /dev/mapper/fedora_localhost--live-root00". And indeed if I look at a console there are no LV devices under /dev/mapper.
So, a preliminary note: it looks to me like we run this 'dumpe2fs -h /dev/mapper/(pathtolv)' command *during the initial storage scan when anaconda starts up*, and we actually stash the minimum size of the volume at that point:
DEBUG:blivet:padding min size from 6.81 GiB up to 7.3 GiB
it seems to me like on the built-in custom part path, nothing tries to run the command again after that - when we actually go into the spoke and resize the volume, there's no re-run of dumpe2fs. But on the blivet path, it seems blivet tries to re-run the dumpe2fs command when you click the 'Resize' button, and that's when it fails (I think because we've actually intentionally deactivated the volume by that point).
upstream PR: https://github.com/storaged-project/blivet-gui/pull/173
updates image: https://vtrefny.fedorapeople.org/img/rhbz1826370.img
I think I have to be +1 blocker for this on the basis of the criterion. I would be amenable to waiving it as a late blocker that is not a regression compared to F31, if we didn't have a fix for it, but I think the fix is good.
I've tested the fix here and it works. It's at least theoretically possible that it could cause problems on some other path we haven't thought of (where for some reason we really need to update the size info after the storage scan on the installer path), but it doesn't seem too likely.
FEDORA-2020-52344cf12a has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-52344cf12a
That's +3, setting approved. This is a bare quorum, but I'm confident this would be accepted as FE at the very least with a larger vote, and we need to run the next RC now.
Resizing in blivet mode works fine for me with RC 1.5. I tried enlarge and shrink ext4 LV, finished installations, both worked fine.
Yes, I also confirm that I am no longer seeing this issue.
FEDORA-2020-52344cf12a has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.