Bug 1826370 - Blivet cannot resize the logical volume already present on the device.
Summary: Blivet cannot resize the logical volume already present on the device.
Alias: None
Product: Fedora
Classification: Fedora
Component: blivet-gui
Version: 32
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Vojtech Trefny
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F32FinalBlocker
TreeView+ depends on / blocked
Reported: 2020-04-21 14:19 UTC by Lukas Ruzicka
Modified: 2020-04-23 18:02 UTC (History)
15 users (show)

Fixed In Version: blivet-gui-2.1.13-2.fc32
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-04-23 18:02:47 UTC
Type: Bug

Attachments (Terms of Use)
Error message (62.21 KB, image/png)
2020-04-21 14:19 UTC, Lukas Ruzicka
no flags Details
storage (199.37 KB, text/plain)
2020-04-21 14:19 UTC, Lukas Ruzicka
no flags Details
anaconda log (22.20 KB, text/plain)
2020-04-21 14:20 UTC, Lukas Ruzicka
no flags Details
lvm (176.23 KB, text/plain)
2020-04-21 14:21 UTC, Lukas Ruzicka
no flags Details

Description Lukas Ruzicka 2020-04-21 14:19:09 UTC
Created attachment 1680578 [details]
Error message

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

How reproducible:

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)

Actual results:
LVs can only be resized using custom partitioning

Expected results:
Blivet is able to resize current LVs and make place for more partitions.

Additional info:
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

Comment 1 Lukas Ruzicka 2020-04-21 14:19:59 UTC
Created attachment 1680579 [details]

Comment 2 Lukas Ruzicka 2020-04-21 14:20:19 UTC
Created attachment 1680580 [details]
anaconda log

Comment 3 Lukas Ruzicka 2020-04-21 14:21:27 UTC
Created attachment 1680581 [details]

Comment 4 Fedora Blocker Bugs Application 2020-04-21 14:26:54 UTC
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

Comment 5 Adam Williamson 2020-04-21 16:07:15 UTC
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."

Comment 6 Adam Williamson 2020-04-21 16:34:55 UTC
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).

Comment 8 Adam Williamson 2020-04-21 17:27:19 UTC
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.

Comment 9 Adam Williamson 2020-04-21 17:28:05 UTC
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.

Comment 10 Ben Cotton 2020-04-21 17:47:55 UTC
+1 blocker

Comment 11 Fedora Update System 2020-04-21 18:20:08 UTC
FEDORA-2020-52344cf12a has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-52344cf12a

Comment 12 Mohan Boddu 2020-04-21 18:58:22 UTC
+1 Blocker

Comment 13 Adam Williamson 2020-04-21 19:17:47 UTC
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.

Comment 14 Kamil Páral 2020-04-22 08:55:46 UTC
Resizing in blivet mode works fine for me with RC 1.5. I tried enlarge and shrink ext4 LV, finished installations, both worked fine.

Comment 15 Lukas Ruzicka 2020-04-22 10:54:43 UTC
Yes, I also confirm that I am no longer seeing this issue.

Comment 16 Fedora Update System 2020-04-23 18:02:47 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.