From: Vitaly Kuznetsov on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1807239692
I think it would make sense to make it possible for an addon to target
'standard' UKI / 'debug' UKI / both in the infrastructure which Emanuele is
trying to create. Personally, I
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805849597
Thanks for the pointer
--
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805835205
@berrange I find not having any debug addon way too restrictive. We do need
ways to debug problems that will occur and we really should avoid asking users
to install and maintain their
From: Vitaly Kuznetsov on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805661115
Exactly: we may want to have an infrastructure for 'external' addons and these
should likely be global, but everything built from kernel srpm can just be
versioned.
--
From: Daniel P. Berrangé on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805650848
One could ask what benefit "global" addons actually provide ? Addons are
tiny, so the saving from only having 1 copy is lost in the noise. Possibly the
only real advantage of
From: Vitaly Kuznetsov on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805638306
What I'm afraid of with "-common" addons is that at some point we will realize
that the particular addon is not really "-common" and we want to update it
only for new ukis but not
From: Daniel P. Berrangé on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805632218
That said, have a separate srpm is not an inherently bad idea. For that matter
there's a potential case to be made that the UKI itself could also be in a
separate srpm, since if
From: Daniel P. Berrangé on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805628801
> Note, creating "-common" sub-package still doesn't give us a way to create
kernel-version-independent addons, we will have to introduce a new srpm for
that.
No we don't. It
From: Vitaly Kuznetsov on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805606318
@eesposit @berrange personally, I'd suggest we don't over-complicate stuff
**now**. Namely, we have only one UKI and only one signing SB key for it
(which, in case of Fedora, is
From: Daniel P. Berrangé on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805563273
> kernel-uki-virt
> kernel-addons-virt-common
> kernel-addons-virt
> kernel-uki-virt-debug
My only thought is around naming to be a common name prefix:
* kernel-uki-virt
*
From: Emanuele Giuseppe Esposito on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805489153
Ok so to make a summary, this could be a possible solution. We want to create
sub-rpms so that:
* `kernel-uki-virt-$uname.$distro.$arch` has the UKI. This is already
From: Emanuele Giuseppe Esposito on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1803395027
I mean being ready to scale without having to create a lot of SourceNNN does
not seem bad IMHO.
Also we need to figure whether to ship unsigned addons too. I think it
From: Emanuele Giuseppe Esposito on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1803387158
Or we might ship unsigned debug addons directly?
--
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe
From: Daniel P. Berrangé on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1803375698
> I agree, that handling them here is easier. But I doubt that there will only
be a few addons. There are a ton of debug parameters that at some point in
time will be needed.
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1803294332
> Regarding why we are doing this here and not in a separate rpm, @vkuznets
might have a more detailed answer but the main point is that it would be
easier to do it here, because
From: Daniel P. Berrangé on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1801367682
Consider if in future we have multiple UKIs created, each with their own
SecureBoot signing key. We might need to have the same addon for different
UKIs.
One option is that we
From: Daniel P. Berrangé on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1801355205
> Regarding why we are doing this here and not in a separate rpm, @vkuznets
might have a more detailed answer but the main point is that it would be
easier to do it here, because
From: Daniel P. Berrangé on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1801354323
> * Global add-ons are not specific to the virt UKI. If other UKIs are created
in future, they should be able to use the same addons.
That said, the signing key we're using was
From: Daniel P. Berrangé on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1801314869
This is packaging non-versioned (ie global) addons, in the versioned sub-RPM
for the virt UKI. IMHO this is undesirable for a few reasons
* It should be possible to install
From: Daniel P. Berrangé on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1801301944
I don't really see the benefit is going via a tarball for addons. Right now it
only contains a single file, and even down the road the number of addons
doesn't seem likely to
From: Emanuele Giuseppe Esposito on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1801117746
Hi Philipp,
Regarding why we are doing this here and not in a separate rpm, @vkuznets
might have a more detailed answer but the main point is that it would be
easier to
From: Emanuele Giuseppe Esposito on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1801106136
You're right, I thought it was merged but it's still there:
https://github.com/uapi-group/specifications/pull/91
Anyways I don't think this will change anytime soon.
--
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1789653760
Hi Emanuele,
your implementation is different to what I originally suggested. But I must
admit that your implementation is better. With my suggestion it would have
been hard to get a
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1789653682
What spec are you referring to? I couldn't find the two paths you are
mentioning neither in the uki spec nor any of the related systemd man pages.
--
From: pmendezh on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1776264104
Maybe remove the reference to `yum` here?
--
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Emanuele Giuseppe Esposito on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1776187331
I would like some opinion here. The place where I store the addons rn is
wrong. According to the spec, they will need to go in either
/usr/lib/linux/extra.d/ for
From: Emanuele Giuseppe Esposito on gitlab.com
Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917
We want to enable kernel.spec to optionally ship UKI addons defined in a
common config file in redhat folder.
The folder redhat/addons will contain all addons configs
27 matches
Mail list logo
