-
Notifications
You must be signed in to change notification settings - Fork 291
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
Make UKI naming configurable #1638
Comments
I think the easiest possibility right now would be to rename the file in the finalize script. |
UKIs only get generated after the finalize script. Running finalize after the UKI generation would break verity or imply that the finalize script cannot change the image anymore. |
Isn't this something to fix in systemd-sysupdate? I'm not really following the issue here, can you give an example of why this currently doesn't work properly? |
sysupdate could be the better place to fix this. Mkosi generates UKI in my case to Alternatively I could leave out the kernel release at least in the update, but keep it in So the easiest solution for me would be to leave out the kernel release entirely or rename the kernel release to something I can control. Example sysupdate.conf:
|
The problem is also that even with kernel version supported as patterns in sysupdate, there are still scenarios where this is not sufficient. For example there could be updates to the UKI without a change in the kernel version, and being unable to influence the UKI name forces one to adopt to the naming convention used by mkosi. In our case, however, our naming is simply Also relevant for #2024 |
This comment was marked as outdated.
This comment was marked as outdated.
I also wonder why the roothash is appended. This is not something which is usually done by This is another thing where it is desirable to be able to turn it off. |
My goal here is that we make kernel-install do what we need and replace all our homegrown logic with kernel-install. We would then add the option to configure the UKI name to kernel-install. |
@DaanDeMeyer What exactly do you imagine by "do what we need"? Which logic exactly? What advantage does Or are you proposing replacing the whole pipeline, like the calls to |
Indeed I would prefer to have kernel-install manage the whole thing. Its the same tool all rpm based distros use to install their kernels so using it in mkosi as well will help ensure our kernels, ukis and such are installed in the same places as kernel-install will place them. It also means we dont have to duplicate every kernel install setting in mkosi but instead just allow configuring kernel-install via the package manager trees. This would include UKI naming among other things. |
Also the current naming scheme ( My rootfs label is following the scheme The current scheme makes it really hard. |
So I'm back again. The only issue I'm running into this time is UKI naming and how it affects systemd-sysupdate. This one is a bit long I'm afraid. I've followed the git history back to see what has changed around the output file naming for UKIs and also the move to putting more into /boot. The decision to add the kernel version to the UKI name was done in #1633 by @MariusSchiffer to fix #1631 and it makes enough sense. If you build an image and there are multiple kernel versions (kvers) in the image then you need a separate file name for each kver. This is independent of the image version set ( Later on the image version was completely removed from the UKI file name in #2154 by @DaanDeMeyer to cater more towards package managers (at least that's what I gather). Again this makes sense too since package managers want the kernel version in the file name since that is what they use to denote a version change. The downside to using kernel versions as mentioned above is that it doesn't play well with systemd-sysupdate. IMHO we need an option for mkosi that enforces using the image version and configures everything to play nicely with systemd-sysupdate. The rest from here is my opinionated view:
I don't know if having mkosi assume Remember that systemd-sysupdate is designed to be quite simple. The "standard" way of using it means:
I'm happy to write an integration test that:
Do we need a new issue? Should we rename this one? |
I have to retract part of my statement, the split artifacts output is not broken. If I configure |
I think I should add that all we should need to change is:
|
Yes, I added the kernel version to the name and then noticed a little bit later that I shot myself in the foot, as I also use sysupdate. I'm currently using a patched version as there was no elegant path forward yet. |
Hey @bluca, @DaanDeMeyer and @behrmann, can one of you weigh in here on making the changes above, adding some sort of I want sysupdate mode and adding tests? I'm happy to do the work, but I don't want to start on something that won't get traction. |
I haven't yet used sysupdate, so I can't really speak to the needs here and I can't say I fully grasp the problem:
Does that mean there is a way to configure your image such that it already works fine as is—then this is a documentation problem—, or do we need something like a switch to enforce sysupdate-compatible output? |
We need a change made for UKI file names, and I'd highly recommend a change to the main output file name (i.e.: image.raw) so that they include the image version and do not include any other version information. The main file is highly recommended but not a hard requirement while the UKI file names do need changing. Like I said, happy to write an integration test and make the appropriate changes. The test should provide a canonical example. |
As far as I can tell
still stands. There's just no way to influence the naming of the UKI on the disk to make it match a given repart.d/sysupdate.d schema, its schema is static. So I can use
AFAICT it's also not possible to do the rename in |
The part which needs changes is this: Lines 2315 to 2319 in 87c900f
This results in files like
Potential changes to
Potential changes to
Potential changes to
|
@septatrix The root hash change was introduced in #923 by @DaanDeMeyer but I can't see in the PR why. I'm curious to know the answer to that one too. |
@mcassaniti We had it before that as well. I was originally introduced by @poettering and I simply kept it intact. Maybe @poettering can tell us whether it's OK to remove the roothash from the UKI name? |
I am unsure what exactly you mean with this. The output files by default do include the version in the name if its set, but if you specify a custom Lines 691 to 697 in 87c900f
|
@NekkoDroid That will output something like |
That is if you use But this is neither here nor there, since the version is still included. |
I've tested #2731 and can confirm it works using the partial snippet of configuration below. The output controls the UKI output while [Output]
ImageId = ...
ImageVersion = ...
Output = %i_%v
[Content]
UnifiedKernelImageName = %i_%v |
I'd like to update the UKIs with systemd-sysupdate at a later point. Including the kernel version in the UKI name makes this tasks harder, as sysupdate does not support (actual asterisk) wildcards and its kernel version specifier is rather limited.
Alternatively, support for kernel "flavours" could be useful.
I do not yet have an idea for an elegant configuration option for this though.
If there is an easier option to rename generated UKIs after the fact, please tell me.
The text was updated successfully, but these errors were encountered: