I'm gonna go ahead and set up the temporary hack for now just to get the tests working again, but leave this ticket open as we need a real fix.

I had to add the F32 desktop image specifically to the createhdds list for aarch64 and ppc64le to back the workaround. Once we fix this properly we'll need to back those changes out.

So, what is the status of this one? Shall this be worked on as a priority?

I think that running this as a follow-up to install_default_upload will not work, as the default installation will be based on btrfs. We will probably have to:

1. install the LVM based Fedora (probably Workstation) - I think there must be (but I am only guessing from top of my head) some tests that provide an LVM installation.
2. perform this resize test and reinstall.

WDYT?

So I have tried to set up the scenario from the above comment and I believe this could work:

• One install test will run and partition the disk using the LVM automatic setup creating the qcow2 image using the STORE_HDD_1 option.
• This will be picked up by a follow up test utilizing the image with HDD_1 variable and the installation will run again.

Problems that my scenario revealed:

• The automatic LVM creation does not create any swap partition that is then required by the resize test and the resize test fails. I suggest remove the swap manipulation from the resize test, because swap partitions will not be needed on future Fedoras anyway.
• In which products should this be running? - if we do not want to use the XFS based ISO in Universal, we might move the tests into Workstation or Everything?

The usefulness of the test is arguably a bit marginal now as the switch to btrfs-by-default makes the case it's testing unusual: we don't deploy resizable-fs-on-LVM as the default in any of our images any more, AFAICS. So there would be an argument for dropping it. (IIRC it doesn't back a validation test, it was added after we encountered a bug and marked it as a blocker).

If we're going to keep it:

• I'd probably run it in the Server DVD flavor. Remember we're mostly killing universal over at #196 anyway.
• Indeed, ditch the swap stuff, since no swap partition is now the default.
• The plan seems reasonable because we actually need to implement the first test anyway, to test https://fedoraproject.org/wiki/QA:Testcase_partitioning_blivet_lvm_ext4 . That's part of #202 .

Note that XFS cannot shrink, so if this resize test is about shrinking, that won't work. You may want to introduce an Ext4-on-LVM condition and test resizing in that case if you want to verify this behavior.

That's already what I was suggesting in the previous comment. Which is why I linked to a test case literally called "blivet_lvm_ext4". :D

We did? I didn't see it specifically mentioned in here. And I wasn't sure whether the resize test was specifically about shrinking or supporting growing filesystems too.

EDIT: Ah, I see, it was indirectly referenced. Whoops!

Just to be more clear about it, I'm saying we should run the first test on Server DVD and have it specifically choose ext4-on-LVM, that way satisfying the requirements of either https://fedoraproject.org/wiki/QA:Testcase_partitioning_blivet_lvm_ext4 or https://fedoraproject.org/wiki/QA:Testcase_partitioning_custom_lvm_ext4 - we need tests for both, so we can just run the resize test after whichever of those we like - and then the resize test runs after that one.

I have opened a PR #206 that uses Server DVD to install Fedora using ext4 LVM (Click here to create them automatically) and moves the LVM resize test to the Server DVD realm as well.

In the nearest future, I will also create the blivet version of the LVM test, however, there will be no need to leave another LVM image, I guess.

Is it ok to proceed with standalone test files for various partitions (easy) or do you require the development of some selection logic, so that one blivet test would cover multiple partitioning strategies? I am in favour of the easy approach, we are not going to edit them so often and both approches require needles for each of the partitions anyway.

So, we never moved the blivet test. I am working on that now, but as part of it, I noticed that the other test has never actually worked right since we moved it :/ It tries to resize the partition to 13GB, but it's only 9GB, so it does nothing. anaconda shows various warnings as the test continues, but none of them actually cause a needle mismatch so the test just proceeds and "succeeds".

I'm kicking the install_lvm_ext4 disk size to 15GB as part of my change, that should hopefully solve things.

OK, I believe this is now fully resolved, and I've taken the F32 desktop image bit out of createhdds too.