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.

Sign up for GitHub

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

Jump to bottom

feat: Auto build sysext overlay for standard UKI images #2941

Open
bencorrado opened this issue Oct 14, 2024 · 3 comments
Open

feat: Auto build sysext overlay for standard UKI images #2941

bencorrado opened this issue Oct 14, 2024 · 3 comments
Labels
enhancement New feature or request triage Add this label to issues that should be triaged and prioretized in the next planning call

Comments

@bencorrado
Copy link
Contributor

bencorrado commented Oct 14, 2024 •
edited
Loading

Is your feature request related to a problem? Please describe.

When building a UKI image the firmware of devices can regularly limit the total UKI image size causing a malloc issue that prevents the system from booting. On many firmware packages this appears to not directly be linked to system resources where adding more RAM/disk does not fix the issue.

This creates an issue when creating large UKI files that contain a full rootfs as the system will not boot on some systems. Even jus enabling standard over core variant can cause issues for a lot of hardware.

Right now packaging the sysext and adding it to a UKI ISO build is a manual process.

Describe the solution you'd like

We should attempt to load things into sysext instead of into the rootfs. for standard packaging. Prepackaging a standard variant sysext and having the build process know that when there is a VARIANT=standard and BOOTLOADER=systemd-boot it should not build this into the rootfs like the other standard images, but instead at the osbuilder/enki stage layer on the right sysext as an overlay.

Describe alternatives you've considered

Additional context

Recovery and reset do NOT load sysext by default. If the software placed into the sysext is expected to be used here we should alert the user in docs.
We should make sure installer runs the sysext as much of the standard variant needs this (might be there, I have not verified)
@bencorrado bencorrado added enhancement New feature or request triage Add this label to issues that should be triaged and prioretized in the next planning call labels Oct 14, 2024
@bencorrado
Copy link
Contributor Author

Completion of this could revert #2940

@Itxaka
Copy link
Member

Itxaka commented Oct 15, 2024

This is a good point but I think the changes migth be part of the earthly file maybe?

Like we could do an extra target that its for developers only that does:

  • Build base image or get it from remote
  • Build and sign whatever sysexts we use on standard (k3s, k9s, provider-kairos)
  • Build the uki iso with the iso-overlay pointing to our built+signed sysext

That way we mainly reuse everything in there with the keys and such and it would be really simple to implement (a few lines of earthly).

We are still experimenting with UKI and sysexts thought, but for example I set an automated service that builds and pushes sysext-ready docker images: https://github.com/Itxaka/sysext-examples

This is bumping and pushing them to several repos, i.e.:

and so on.

Those can be easily consumed by the enki sysext command to build signed sysext ready for kairos. So we could use those to build the core uki + standard extras easily.

We also wanted to leverage the sysext in non-uki formats as well (except alpine :() in order to have a more cohesive release process, i.e. Build just core, provide sysexts or commands to easily build sysexts for both types (uki and non-uki)

@jimmykarily
Copy link
Contributor

We did this: https://github.com/kairos-io/kairos/pull/2929/files but it needs a release to get something built.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request triage Add this label to issues that should be triaged and prioretized in the next planning call
Projects
🧙Issue tracking board
Status: No status
Milestone
No milestone
Development

No branches or pull requests
3 participants
@Itxaka @jimmykarily @bencorrado