`install_{blivet_}resize_lvm` broken as desktop base disk image isn't an LVM install any more

adamwill commented

2020-11-03 00:03:58 +00:00

Owner

The install_blivet_resize_lvm and install_resize_lvm tests rely on an assumption that the desktop base disk image uses an ext4-on-LVM layout. But, as of Fedora 33, it doesn't. It uses btrfs, the new default.

This means the tests both a) are no longer actually tests of resizing an existing LVM layout, and b) don't work at all any more (because anaconda can't resize btrfs).

We need a solution for this. There isn't an obvious alternative; the Server disk image will still be an LVM layout (xfs-on-LVM) but I don't know if anaconda can resize xfs, and anyway it's too small to have enough space. We may want to run this test after install_default_upload or something instead.

A temporary hack would be to use the F32 desktop base disk image instead, but of course that only buys us time until F32 goes EOL.

The `install_blivet_resize_lvm` and `install_resize_lvm` tests rely on an assumption that the `desktop` base disk image uses an ext4-on-LVM layout. But, as of Fedora 33, it doesn't. It uses btrfs, the new default. This means the tests both a) are no longer actually tests of resizing an existing LVM layout, and b) don't work at all any more (because [anaconda can't resize btrfs](https://bugzilla.redhat.com/show_bug.cgi?id=1855292)). We need a solution for this. There isn't an obvious alternative; the Server disk image will still be an LVM layout (xfs-on-LVM) but I don't know if anaconda can resize xfs, and anyway it's too small to have enough space. We may want to run this test after install_default_upload or something instead. A temporary hack would be to use the F32 desktop base disk image instead, but of course that only buys us time until F32 goes EOL.

adamwill commented

2020-11-03 00:08:40 +00:00

Author

Owner

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.

adamwill commented

2020-11-04 18:13:53 +00:00

Author

Owner

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.

I had to add the F32 desktop image specifically to the createhdds list for [aarch64](https://pagure.io/fedora-qa/createhdds/c/f34ac0c042c3d471f58df470402ded81ef3a47ec?branch=master) and [ppc64le](https://pagure.io/fedora-qa/createhdds/c/79c0317970b23d539d61b11191d94fe2a56ced41?branch=master) to back the workaround. Once we fix this properly we'll need to back those changes out.

lruzicka commented

2020-11-18 09:05:42 +00:00

Owner

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:

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.
perform this resize test and reinstall.

WDYT?

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?

lruzicka commented

2020-11-18 15:03:17 +00:00

Owner

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?

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**?

adamwill commented

2020-11-18 19:27:34 +00:00

Author

Owner

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 .

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 .

ngompa commented

2020-11-19 01:16:59 +00:00

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.

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.

adamwill commented

2020-11-19 02:18:25 +00:00

Author

Owner

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

ngompa commented

2020-11-19 02:20:44 +00:00

~~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!

~~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!

adamwill commented

2020-11-19 02:31:40 +00:00

Author

Owner

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.

lruzicka commented

2020-11-19 11:54:25 +00:00

Owner

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.

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.

adamwill commented

2021-04-30 17:35:13 +00:00

Author

Owner

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.

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.

adamwill commented

2021-04-30 18:42:01 +00:00

Author

Owner

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

adamwill commented

2021-04-30 18:42:02 +00:00

Author

Owner

Metadata Update from @adamwill:

Issue close_status updated to: Fixed
Issue status updated to: Closed (was: Open)

**Metadata Update from @adamwill**: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)

lruzicka was assigned by adamwill

2026-01-23 20:47:49 +00:00

adamwill added the

labels

2026-02-10 02:14:49 +00:00

Rows
Columns

install_{blivet_}resize_lvm broken as desktop base disk image isn't an LVM install any more #201

`install_{blivet_}resize_lvm` broken as desktop base disk image isn't an LVM install any more #201