Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ostreecontainer bootc test with reboot #1116

Merged
merged 6 commits into from
Apr 10, 2024

Conversation

rvykydal
Copy link
Contributor

@rvykydal rvykydal commented Mar 27, 2024

This adds a few modifications to the test added by @jikortus in #1096

@rvykydal rvykydal marked this pull request as draft March 27, 2024 13:24
@rvykydal
Copy link
Contributor Author

I'll run the tests on the PR ('/test-platforms') when our runners are back healthy.

@rvykydal
Copy link
Contributor Author

/test-platforms

@rvykydal
Copy link
Contributor Author

rvykydal commented Apr 2, 2024

/test-platforms

@rvykydal rvykydal marked this pull request as ready for review April 2, 2024 10:58
@rvykydal rvykydal requested review from jstodola and jkonecny12 April 2, 2024 11:05
@rvykydal rvykydal changed the title Ostreecontainer bootc update Ostreecontainer bootc test with reboot Apr 2, 2024
@rvykydal
Copy link
Contributor Author

rvykydal commented Apr 2, 2024

Apparently the test is failing on daily-iso (https://github.com/rhinstaller/kickstart-tests/actions/runs/8521608897/job/23340112174). The reboot of installed system fails.
From a local run:
Screenshot from 2024-04-02 14-07-38

kstest.log
virt-install.log

The iso is created for the test in https://github.com/rhinstaller/kickstart-tests/actions/workflows/daily-boot-iso-rawhide.yml. Perhaps there is some unexpected ID o label somewhere breaking some automation/defaults.

@jikortus any idea or hint?

@jikortus
Copy link
Contributor

jikortus commented Apr 2, 2024

No idea right now, @rvykydal, but I'll execute the test with daily ISO and try to investigate what goes wrong.

@jikortus
Copy link
Contributor

jikortus commented Apr 2, 2024

@rvykydal, I found out where the problem is. The fedora-bootc:eln image doesn't (naturally) contain any support for btrfs, which is used as Fedora's default scheme/FS. AFAIK there are only ELN and CentOS container images available (ATM?), so we need to workaround this by using a specific autopart scheme to avoid btrfs, at least until there's a proper Rawhide version of the container image which would include support for btrfs.

You can replace my previous commit containing the new test with jikortus@e45c825.

@rvykydal
Copy link
Contributor Author

rvykydal commented Apr 3, 2024

Great, thank you, indeed we are detecting different profiles for rawhide and daily-iso.

daily-iso:

12:05:22,126 DEBUG anaconda:anaconda: core.configuration.profile: Detecting a profile for ID=fedora, VARIANT_ID=None.
12:05:22,126 INFO anaconda:anaconda: core.configuration.profile: The 'fedora' profile is detected.
12:05:22,126 INFO anaconda:anaconda: core.configuration.anaconda: Load the 'fedora' profile configuration.
[Storage]
default_scheme = BTRFS

rawhide:

12:29:44,050 DEBUG anaconda:anaconda: core.configuration.profile: Detecting a profile for ID=fedora, VARIANT_ID=server.
12:29:44,050 INFO anaconda:anaconda: core.configuration.profile: The 'fedora-server' profile is detected.
12:29:44,050 INFO anaconda:anaconda: core.configuration.anaconda: Load the 'fedora-server' profile configuration.
[Storage]
file_system_type = xfs
default_scheme = LVM
default_partitioning =
    /    (min 2 GiB, max 15 GiB)

I think we should address it separately (#1120) and update this PR to make sure btrfs is not used on Fedora, similar as you suggest.

@rvykydal
Copy link
Contributor Author

rvykydal commented Apr 3, 2024

You can replace my previous commit containing the new test with jikortus@e45c825.

I've added a commit where I rather keep default autopartitioning scheme for rhel and enforce lvm only for Fedora. It is a bit too much of copying but we can improve it here: #1121

@rvykydal rvykydal force-pushed the ostreecontainer-bootc-update branch from b409f3d to d6f7a47 Compare April 3, 2024 08:58
@rvykydal
Copy link
Contributor Author

rvykydal commented Apr 3, 2024

/test-platforms

@jikortus
Copy link
Contributor

jikortus commented Apr 3, 2024

OK, that makes sense 👍. I hope the test will pass now at last.

@@ -3,7 +3,10 @@
# depends on the referenced ostree container being bootable

# Use the default settings.
%ksappend common/common_no_payload.ks
%ksappend common/common_no_storage_and_payload.ks
%ksappend payload/default_packages.ks
Copy link
Contributor

@jikortus jikortus Apr 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Including a %packages section contradicts with a container image payload, at least for now (even though it may just be ignored by Anaconda).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, good catch, thank you!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, another thought - if I understand correctly the system of fragments, the platform-specific ones should apply if they exist and if they don't, a 'shared' one should apply, right? If this assumption is correct, shouldn't we define just one 'shared' and one specific, with LVM scheme for fedora_rawhide, leaving behind the other specific ones (rhelX) that would actually be covered by the 'shared' one?

Copy link
Contributor Author

@rvykydal rvykydal Apr 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, that would be great, let me check

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, thank you, updated.

@rvykydal rvykydal force-pushed the ostreecontainer-bootc-update branch from d6f7a47 to 17c963a Compare April 3, 2024 10:32
@rvykydal
Copy link
Contributor Author

rvykydal commented Apr 3, 2024

/test-platforms

@rvykydal rvykydal requested a review from jikortus April 3, 2024 11:11
@rvykydal rvykydal force-pushed the ostreecontainer-bootc-update branch 2 times, most recently from 3badcf7 to 2268a83 Compare April 3, 2024 11:32
@rvykydal
Copy link
Contributor Author

rvykydal commented Apr 3, 2024

/test-platforms

1 similar comment
@rvykydal
Copy link
Contributor Author

rvykydal commented Apr 3, 2024

/test-platforms

@rvykydal
Copy link
Contributor Author

rvykydal commented Apr 3, 2024

Download of boot.iso fails in test-platfroms for daily-iso. I'll give it a try tomorrow.

@rvykydal
Copy link
Contributor Author

rvykydal commented Apr 4, 2024

/test-platforms

}

get_timeout() {
echo "80"
Copy link
Contributor Author

@rvykydal rvykydal Apr 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my experience this test is pretty fast (not regenerating initramfs), less then 5 minutes. So instead of increasing the value from default 60 (mins) to 80, I'd rather keep it to 60 or even cut it down to 30? What do you think @jikortus ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No problem at all, @rvykydal. The specific value was actually part of the initial work by Vladimir Slavik, so I thought there was a special reason for that. I retested it with get_timeout() removed and the test passed, so it is most likely not needed.

jikortus and others added 6 commits April 4, 2024 10:14
The ostree environments have most of the filesystem read-only
(including /usr), but this can be overcome via an overlay.

In such case the test script intended for run in the system resides
in /var/lib/extensions/kickstart-tests/usr/libexec instead of
the usual location (/usr/libexec).
It tests installation of a bootable container image
(with bootc/bootupd) and boot of the installed system,
as well as --remote and --stateroot parameters of
ostreecontainer kickstart command.

It's based on previous work from Vladimir Slavik.
The same place as is used for rpm payload
… test

Patch created based on hints by jikortus.
The test is actually pretty fast (not generating initramfs) so there is
no need to bigger timeout.
@rvykydal rvykydal force-pushed the ostreecontainer-bootc-update branch from 2268a83 to d7e66d1 Compare April 4, 2024 08:16
@rvykydal
Copy link
Contributor Author

rvykydal commented Apr 4, 2024

/test-platforms

Copy link
Member

@jkonecny12 jkonecny12 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@rvykydal rvykydal merged commit b4d8aa0 into rhinstaller:master Apr 10, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants