Bug 1826370

Created attachment 1680579 [details]
storage

Created attachment 1680580 [details]
anaconda log

Created attachment 1680581 [details]
lvm

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.

+1 blocker

FEDORA-2020-52344cf12a has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-52344cf12a

+1 Blocker

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.