Re: [OS-BUILD PATCHv3 0/6] secure boot signing updates
From: Gerd Hoffmann on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2849#note_1878749882 only rhel and fedora have a new (15.8) shim, centos stream not yet ... -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: kernel leftovers in /boot/efi/EFI/Linux/
On Tue, Mar 19, 2024 at 11:56:20AM +0100, Germano Massullo wrote: > the patch worked, thank you > https://germano.fedorapeople.org/bugreport/kernel_leftovers/kernel_leftovers_fixed.txt Landed upstream: https://github.com/systemd/systemd/commit/3037616d8ed68f3263746e3c6399d4a05242068b take care, Gerd -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: kernel leftovers in /boot/efi/EFI/Linux/
> > https://github.com/kraxel/systemd/commit/6eed67a291bf896befb4d407dc57f9a7fca9c332 > > can't comment on the function, but there is a typo in the commit > message IMO > > and *not* exist early -> and *not* exit early Thanks, fixed. take care, Gerd -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: kernel leftovers in /boot/efi/EFI/Linux/
On Tue, Mar 19, 2024 at 01:46:54AM +0100, Germano Massullo wrote: > I created a Copr repository with the patch > https://copr.fedorainfracloud.org/coprs/germano/systemd_fix_uki-copy_deinstall_patch/ Oh, I was thinking about just patching the file directly on the installed system (90-uki-copy.install is simply copied on install, so the patch should apply just fine) instead of doing a full systemd package update ... take care, Gerd -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: kernel leftovers in /boot/efi/EFI/Linux/
On Sun, Mar 17, 2024 at 01:20:06PM +0100, Germano Massullo wrote: > I was not able to remove such kernel entries from /boot/efi/EFI/Linux/ by > using the command. > Output here > https://germano.fedorapeople.org/bugreport/kernel_leftovers/kernel_leftovers.txt > > I also tried to enter the full name of the files, but I had no success :-( Think I've nailed it: https://github.com/kraxel/systemd/commit/6eed67a291bf896befb4d407dc57f9a7fca9c332 Can you try apply the patch to /usr/lib/kernel/install.d/90-uki-copy.install and see if that helps? thanks, Gerd -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: kernel leftovers in /boot/efi/EFI/Linux/
On Wed, Mar 13, 2024 at 10:00:45AM +0100, Germano Massullo wrote: > Hello Gerd, by following your instruction, I searched in my build folder one > of the kernels that have not been successfully erased, and then I retrieved > the scripts of the kernel-core package, (uploaded at > https://paste.centos.org/view/ac440ce5 ) > Should I proceed with just the command > /bin/kernel-install remove 6.6.4-100.fc39.1.x86_64 || exit $? > or with the complete block from 11 to 15 line? Just the kernel-install line, with '-v' or '--verbose' added for verbose output, i.e. ... /bin/kernel-install --verbose add 6.6.4-100.fc39.1.x86_64 /lib/modules/6.6.4-100.fc39.1.x86_64/vmlinuz /bin/kernel-install --verbose remove 6.6.4-100.fc39.1.x86_64 ... for install and uninstall take care, Gerd -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCH] uki: use systemd-pcrphase dracut module
From: Gerd Hoffmann uki: use systemd-pcrphase dracut module dracut in Fedora 39 ships a systemd-pcrphase module. Use that instead of copying over files manually via install_items+="..." Signed-off-by: Gerd Hoffmann diff --git a/redhat/dracut-virt.conf b/redhat/dracut-virt.conf index blahblah..blahblah 100644 --- a/redhat/dracut-virt.conf +++ b/redhat/dracut-virt.conf @@ -12,7 +12,7 @@ dracutmodules+=" base systemd systemd-initrd dracut-systemd dbus dbus-broker usr dracutmodules+=" dm lvm rootfs-block fs-lib " # modules: tpm and crypto -dracutmodules+=" crypt crypt-loop tpm2-tss " +dracutmodules+=" crypt crypt-loop tpm2-tss systemd-pcrphase " # modules: support root on virtiofs dracutmodules+=" virtiofs " @@ -36,6 +36,3 @@ drivers+=" dm_crypt " # filesystems filesystems+=" vfat ext4 xfs overlay " - -# systemd-pcrphase -install_items+=" /lib/systemd/system/systemd-pcrphase-initrd.service /usr/lib/systemd/systemd-pcrphase /usr/lib/systemd/system/initrd.target.wants/systemd-pcrphase-initrd.service " -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2955 -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: kernel leftovers in /boot/efi/EFI/Linux/
On Wed, Feb 21, 2024 at 07:10:11PM +0100, Germano Massullo wrote: > Thank you for your support. > Perhaps I am missing something in the kernel-install commands > > root@machine:/home/user# rpm -q --scripts kernel-uki-virt > package kernel-uki-virt not installed Hmm. I'm really wondering how you end up having anything in /boot/efi/EFI/Linux if the kernel-uki-virt sub-rpm is not installed. Non-UKI kernels should never ever be copied to that location. > root@machine:/home/user# kernel-install -v add The command is longer than that, with kernel version and image, best cut+paste the complete line from the rpm install scripts, then add '-v' for verbose output. If kernel-uki-virt is not installed try 'rpm -q --scripts kernel-core' take care, Gerd -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: kernel leftovers in /boot/efi/EFI/Linux/
On Sun, Feb 18, 2024 at 10:48:32AM +0100, Germano Massullo wrote: > Hello, during a dnf update I noticed that /boot/efi was full and the system > was not able to update. > So I found out in /boot/efi/EFI/Linux/ there are many files belonging to > kernel RPMs no longer installed on the system. > I am wondering why there are these leftovers. Some of the kernel with > .fc39.1 in their name are from RPMs I created to test kernel patches, but > they don't have anything special compared to regular Fedora kernel RPMs, > since I just rebuilt the package after having added a patch. The kernel-install plugins /usr/lib/kernel/install.d/90-uki-copy.install and (in case uki-direct is installed) /usr/lib/kernel/install.d/99-uki-uefi-setup.install should handle both installing and removing the kernel images. Apparently there is a bug on one of these two scripts ... Try 'rpm -q --scripts kernel-uki-virt' and run the 'kernel-install add' and 'kernel-install remove' commands manually, with '-v' option added for verbose output. That should give a clue where things are failing. take care, Gerd -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv2 0/2] uki-virt: add virtiofs dracut module
From: Gerd Hoffmann on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2817#note_1696083562 If you boot with an initrd it will be the initrd not the kernel which handles the root= command line. So maybe mkosi has built-in support for virtiofs, or it passes control back to the kernel for cases it can't handle. dracut initrd's will error out without the virtiofs module. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv2 0/2] uki-virt: add virtiofs dracut module
From: Gerd Hoffmann on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2817#note_1694811799 We need the dracut module included nevertheless, to make root=virtiofs: work when booting with an initrd. Independent from that we can consider switching virtiofs.ko to built-in, to also allow booting without initrd. No objections from my side, but it should IMHO be an independent MR. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv2] aarch64: enable uki
From: Gerd Hoffmann on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818#note_1641304014 Fixed now. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCHv2] aarch64: enable uki
From: Gerd Hoffmann
aarch64: enable uki
Now, with CONFIG_EFI_ZBOOT enabled and aarch64 kernels being
self-unpacking efi binaries instead of gzipped images, building
aarch64 UKIs actually works.
Flip the switch and enable them.
Also add descriptions and scripts for the 16k and 64k kernel
variants.
Signed-off-by: Gerd Hoffmann
diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index blahblah..blahblah 100644
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -285,7 +285,7 @@ Summary: The Linux kernel
# Want to build a vanilla kernel build without any non-upstream patches?
%define with_vanilla %{?_with_vanilla: 1} %{?!_with_vanilla: 0}
-%ifarch x86_64
+%ifarch x86_64 aarch64
%define with_efiuki %{?_without_efiuki: 0} %{?!_without_efiuki: 1}
%else
%define with_efiuki 0
@@ -1656,6 +1656,26 @@ Prebuilt debug unified kernel image for virtual machines.
Prebuilt default unified kernel image for virtual machines.
%endif
+%if %{with_arm64_16k} && %{with_debug} && %{with_efiuki}
+%description 16k-debug-uki-virt
+Prebuilt 16k debug unified kernel image for virtual machines.
+%endif
+
+%if %{with_arm64_16k_base} && %{with_efiuki}
+%description 16k-uki-virt
+Prebuilt 16k unified kernel image for virtual machines.
+%endif
+
+%if %{with_arm64_64k} && %{with_debug} && %{with_efiuki}
+%description 64k-debug-uki-virt
+Prebuilt 64k debug unified kernel image for virtual machines.
+%endif
+
+%if %{with_arm64_64k_base} && %{with_efiuki}
+%description 64k-uki-virt
+Prebuilt 64k unified kernel image for virtual machines.
+%endif
+
%if %{with_ipaclones}
%kernel_ipaclones_package
%endif
@@ -3353,6 +3373,16 @@ fi\
%kernel_variant_post -v 16k-debug
%endif
+%if %{with_arm64_16k} && %{with_debug} && %{with_efiuki}
+%kernel_variant_posttrans -v 16k-debug -u virt
+%kernel_variant_preun -v 16k-debug -u virt
+%endif
+
+%if %{with_arm64_16k_base} && %{with_efiuki}
+%kernel_variant_posttrans -v 16k -u virt
+%kernel_variant_preun -v 16k -u virt
+%endif
+
%if %{with_arm64_64k_base}
%kernel_variant_preun -v 64k
%kernel_variant_post -v 64k
@@ -3363,6 +3393,16 @@ fi\
%kernel_variant_post -v 64k-debug
%endif
+%if %{with_arm64_64k} && %{with_debug} && %{with_efiuki}
+%kernel_variant_posttrans -v 64k-debug -u virt
+%kernel_variant_preun -v 64k-debug -u virt
+%endif
+
+%if %{with_arm64_64k_base} && %{with_efiuki}
+%kernel_variant_posttrans -v 64k -u virt
+%kernel_variant_preun -v 64k -u virt
+%endif
+
%if %{with_realtime_base}
%kernel_variant_preun -v rt
%kernel_variant_post -v rt -r (kernel|kernel-smp)
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH] aarch64: enable uki
From: Gerd Hoffmann on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818#note_1639217733 https://gitlab.com/cki-project/containers/-/issues/48 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH] aarch64: enable uki
From: Gerd Hoffmann on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818#note_1639095391 Yes, that is expected. I see you've created a MR for the build container meanwile. Thanks. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCH] aarch64: enable uki
From: Gerd Hoffmann
aarch64: enable uki
Now, with CONFIG_EFI_ZBOOT enabled and aarch64 kernels being
self-unpacking efi binaries instead of gzipped images, building
aarch64 UKIs actually works.
Flip the switch and enable them.
Signed-off-by: Gerd Hoffmann
diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index blahblah..blahblah 100644
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -285,7 +285,7 @@ Summary: The Linux kernel
# Want to build a vanilla kernel build without any non-upstream patches?
%define with_vanilla %{?_with_vanilla: 1} %{?!_with_vanilla: 0}
-%ifarch x86_64
+%ifarch x86_64 aarch64
%define with_efiuki %{?_without_efiuki: 0} %{?!_without_efiuki: 1}
%else
%define with_efiuki 0
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCHv2 2/2] uki-virt: add systemd-sysext dracut module
From: Gerd Hoffmann uki-virt: add systemd-sysext dracut module Allows the initrd being extended using sysext. Signed-off-by: Gerd Hoffmann diff --git a/redhat/dracut-virt.conf b/redhat/dracut-virt.conf index blahblah..blahblah 100644 --- a/redhat/dracut-virt.conf +++ b/redhat/dracut-virt.conf @@ -17,6 +17,9 @@ dracutmodules+=" crypt crypt-loop tpm2-tss " # modules: support root on virtiofs dracutmodules+=" virtiofs " +# modules: use sysext images (see 'man systemd-sysext') +dracutmodules+=" systemd-sysext " + # drivers: virtual buses, pci drivers+=" virtio-pci virtio-mmio " # qemu-kvm drivers+=" hv-vmbus pci-hyperv " # hyperv -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2817 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCHv2 1/2] uki-virt: add virtiofs dracut module
From: Gerd Hoffmann uki-virt: add virtiofs dracut module Need to support root filesystem on virtiofs. Signed-off-by: Gerd Hoffmann diff --git a/redhat/dracut-virt.conf b/redhat/dracut-virt.conf index blahblah..blahblah 100644 --- a/redhat/dracut-virt.conf +++ b/redhat/dracut-virt.conf @@ -14,6 +14,9 @@ dracutmodules+=" dm lvm rootfs-block fs-lib " # modules: tpm and crypto dracutmodules+=" crypt crypt-loop tpm2-tss " +# modules: support root on virtiofs +dracutmodules+=" virtiofs " + # drivers: virtual buses, pci drivers+=" virtio-pci virtio-mmio " # qemu-kvm drivers+=" hv-vmbus pci-hyperv " # hyperv -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2817 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCHv2 0/2] uki-virt: add virtiofs dracut module
From: Gerd Hoffmann on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2817 Need to support root filesystem on virtiofs. Signed-off-by: Gerd Hoffmann --- redhat/dracut-virt.conf | 6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCH 0/0] uki-virt: add virtiofs dracut module
From: Gerd Hoffmann on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2817 NOTE: Truncated patchset due to missing public @redhat.com email address on your GitLab profile at https://gitlab.com/-/profile. Once that is fixed, close and reopen the merge request to retrigger sending the emails. Need to support root filesystem on virtiofs. Signed-off-by: Gerd Hoffmann --- redhat/dracut-virt.conf | 6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCHv3] aarch64: enable zboot
From: Gerd Hoffmann
aarch64: enable zboot
Enable CONFIG_EFI_ZBOOT.
Also adapt %make_target and %kernel_image for zboot.
With the kernel self-uncompressing itself the bootloader or the
systemd-stub doesn't need to handle the uncompressing (and doesn't need
to know how the kernel is compressed, i.e. whenever it is .gz or .xz).
Some more background: https://github.com/systemd/systemd/issues/23788
It also makes aarch64 work more like x86_64 where the kernel
decompresses itself too.
Signed-off-by: Gerd Hoffmann
diff --git a/redhat/configs/ark/generic/CONFIG_EFI_ZBOOT
b/redhat/configs/ark/generic/CONFIG_EFI_ZBOOT
index blahblah..blahblah 100644
--- a/redhat/configs/ark/generic/CONFIG_EFI_ZBOOT
+++ b/redhat/configs/ark/generic/CONFIG_EFI_ZBOOT
@@ -1 +1 @@
-# CONFIG_EFI_ZBOOT is not set
+CONFIG_EFI_ZBOOT=y
diff --git a/redhat/configs/fedora/generic/CONFIG_EFI_ZBOOT
b/redhat/configs/fedora/generic/CONFIG_EFI_ZBOOT
index blahblah..blahblah 100644
--- a/redhat/configs/fedora/generic/CONFIG_EFI_ZBOOT
+++ b/redhat/configs/fedora/generic/CONFIG_EFI_ZBOOT
@@ -1 +1 @@
-# CONFIG_EFI_ZBOOT is not set
+CONFIG_EFI_ZBOOT=y
diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index blahblah..blahblah 100755
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -484,8 +484,8 @@ Summary: The Linux kernel
%define all_arch_configs kernel-%{version}-aarch64*.config
%define asmarch arm64
%define hdrarch arm64
-%define make_target Image.gz
-%define kernel_image arch/arm64/boot/Image.gz
+%define make_target vmlinuz.efi
+%define kernel_image arch/arm64/boot/vmlinuz.efi
%endif
# Should make listnewconfig fail if there's config options
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2283
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv2] aarch64: enable zboot
From: Gerd Hoffmann on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2283#note_1271782893 Committed as 731c4eac848ff9dd42776da8ed3407b257e3abf0 and landed in 6.2-rc1 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCHv2] aarch64: enable zboot
From: Gerd Hoffmann
aarch64: enable zboot
Enable CONFIG_EFI_ZBOOT.
Also adapt %make_target and %kernel_image for zboot.
With the kernel self-uncompressing itself the bootloader or the
systemd-stub doesn't need to handle the uncompressing (and doesn't need
to know how the kernel is compressed, i.e. whenever it is .gz or .xz).
Some more background: https://github.com/systemd/systemd/issues/23788
It also makes aarch64 work more like x86_64 where the kernel
decompresses itself too.
Signed-off-by: Gerd Hoffmann
diff --git a/redhat/configs/fedora/generic/CONFIG_EFI_ZBOOT
b/redhat/configs/fedora/generic/CONFIG_EFI_ZBOOT
index blahblah..blahblah 100644
--- a/redhat/configs/fedora/generic/CONFIG_EFI_ZBOOT
+++ b/redhat/configs/fedora/generic/CONFIG_EFI_ZBOOT
@@ -1 +1 @@
-# CONFIG_EFI_ZBOOT is not set
+CONFIG_EFI_ZBOOT=y
diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index blahblah..blahblah 100755
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -484,8 +484,8 @@ Summary: The Linux kernel
%define all_arch_configs kernel-%{version}-aarch64*.config
%define asmarch arm64
%define hdrarch arm64
-%define make_target Image.gz
-%define kernel_image arch/arm64/boot/Image.gz
+%define make_target vmlinuz.efi
+%define kernel_image arch/arm64/boot/vmlinuz.efi
%endif
# Should make listnewconfig fail if there's config options
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2283
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCH] aarch64: enable zboot
From: Gerd Hoffmann
aarch64: enable zboot
Enable CONFIG_EFI_ZBOOT.
Also adapt %make_target and %kernel_image for zboot.
Signed-off-by: Gerd Hoffmann
diff --git a/redhat/configs/fedora/generic/CONFIG_EFI_ZBOOT
b/redhat/configs/fedora/generic/CONFIG_EFI_ZBOOT
index blahblah..blahblah 100644
--- a/redhat/configs/fedora/generic/CONFIG_EFI_ZBOOT
+++ b/redhat/configs/fedora/generic/CONFIG_EFI_ZBOOT
@@ -1 +1 @@
-# CONFIG_EFI_ZBOOT is not set
+CONFIG_EFI_ZBOOT=y
diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index blahblah..blahblah 100755
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -484,8 +484,8 @@ Summary: The Linux kernel
%define all_arch_configs kernel-%{version}-aarch64*.config
%define asmarch arm64
%define hdrarch arm64
-%define make_target Image.gz
-%define kernel_image arch/arm64/boot/Image.gz
+%define make_target vmlinuz.efi
+%define kernel_image arch/arm64/boot/vmlinuz.efi
%endif
# Should make listnewconfig fail if there's config options
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2283
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv3] redhat: Add sub-RPM with a EFI unified kernel image for virtual machines
From: Gerd Hoffmann on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2175#note_1247136188 Tested, works fine indeed. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv3] redhat: Add sub-RPM with a EFI unified kernel image for virtual machines
From: Gerd Hoffmann on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2175#note_1246079266 Yes, kernel-core should continue to be the default, unless you explicitly ask for something else. But it should be possible to ask for something else and drop kernel-core in that case. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv2] redhat: Add sub-RPM with a EFI unified kernel image for virtual machines
From: Gerd Hoffmann on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2175#note_1245908862 Well, at the end of the days we want kernel-uki-virt be able to replace kernel-core, so kernel images using the UKI don't end up having two kernels installed. But maybe it's better to introduce a new virtual package (say kernel-image) for that, so it is possible to specify whenever you want kernel-core specifically or whenever any kernel image is fine and you don't care whenever that is kernel-core or kernel-uki-* ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCHv6 1/2] split sub-rpm kernel-modules-core from kernel-core
From: Gerd Hoffmann
split sub-rpm kernel-modules-core from kernel-core
All kernel modules plus support files (such as the files generated
by depmod) are moved to the new kernel-modules-core sub-rpm.
The kernel binary plus support files stay in the kernel-core sub-rpm.
This essentially includes the files which are copied over to /boot by
the kernel-install utility (vmlinuz, System.map, ...).
With this in place we have a strict separation between sub-rpms carrying
a kernel image and sub-rpms carrying kernel modules. This should make it
easier to use alternative kernel image packages, for example an unified
kernel.
Signed-off-by: Gerd Hoffmann
diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index blahblah..blahblah 100755
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -571,6 +571,7 @@ ExclusiveOS: Linux
%ifnarch %{nobuildarches}
Requires: kernel-core-uname-r = %{KVERREL}
Requires: kernel-modules-uname-r = %{KVERREL}
+Requires: kernel-modules-core-uname-r = %{KVERREL}
%endif
@@ -886,6 +887,7 @@ Provides: kernel = %{specversion}-%{pkg_release}\
%endif\
Provides: kernel-%{_target_cpu} = %{specversion}-%{pkg_release}%{?1:+%{1}}\
Provides: kernel-uname-r = %{KVERREL}%{?1:+%{1}}\
+Requires: kernel%{?1:-%{1}}-modules-core-uname-r = %{KVERREL}%{?1:+%{1}}\
Requires(pre): %{kernel_prereq}\
Requires(pre): %{initrd_prereq}\
Requires(pre): ((linux-firmware >= 20150904-56.git6ebf5d57) if linux-firmware)\
@@ -1208,6 +1210,7 @@ Provides: installonlypkg(kernel-module)\
Provides: kernel%{?1:-%{1}}-modules-internal-uname-r = %{KVERREL}%{?1:+%{1}}\
Requires: kernel-uname-r = %{KVERREL}%{?1:+%{1}}\
Requires: kernel%{?1:-%{1}}-modules-uname-r = %{KVERREL}%{?1:+%{1}}\
+Requires: kernel%{?1:-%{1}}-modules-core-uname-r = %{KVERREL}%{?1:+%{1}}\
AutoReq: no\
AutoProv: yes\
%description %{?1:%{1}-}modules-internal\
@@ -1228,6 +1231,7 @@ Provides: installonlypkg(kernel-module)\
Provides: kernel%{?1:-%{1}}-modules-extra-uname-r = %{KVERREL}%{?1:+%{1}}\
Requires: kernel-uname-r = %{KVERREL}%{?1:+%{1}}\
Requires: kernel%{?1:-%{1}}-modules-uname-r = %{KVERREL}%{?1:+%{1}}\
+Requires: kernel%{?1:-%{1}}-modules-core-uname-r = %{KVERREL}%{?1:+%{1}}\
%if %{-m:1}%{!-m:0}\
Requires: kernel-modules-extra-uname-r = %{KVERREL}\
%endif\
@@ -1250,6 +1254,7 @@ Provides: kernel-modules =
%{version}-%{release}%{?1:+%{1}}\
Provides: installonlypkg(kernel-module)\
Provides: kernel%{?1:-%{1}}-modules-uname-r = %{KVERREL}%{?1:+%{1}}\
Requires: kernel-uname-r = %{KVERREL}%{?1:+%{1}}\
+Requires: kernel%{?1:-%{1}}-modules-core-uname-r = %{KVERREL}%{?1:+%{1}}\
%if %{-m:1}%{!-m:0}\
Requires: kernel-modules-uname-r = %{KVERREL}\
%endif\
@@ -1259,6 +1264,28 @@ AutoProv: yes\
This package provides commonly used kernel modules for the %{?2:%{2}-}core
kernel package.\
%{nil}
+#
+# This macro creates a kernel--modules-core package.
+# %%kernel_modules_core_package [-m]
+#
+%define kernel_modules_core_package(m) \
+%package %{?1:%{1}-}modules-core\
+Summary: Core kernel modules to match the %{?2:%{2}-}core kernel\
+Provides: kernel%{?1:-%{1}}-modules-core-%{_target_cpu} =
%{version}-%{release}\
+Provides: kernel-modules-core-%{_target_cpu} =
%{version}-%{release}%{?1:+%{1}}\
+Provides: kernel-modules-core = %{version}-%{release}%{?1:+%{1}}\
+Provides: installonlypkg(kernel-module)\
+Provides: kernel%{?1:-%{1}}-modules-core-uname-r = %{KVERREL}%{?1:+%{1}}\
+Requires: kernel-uname-r = %{KVERREL}%{?1:+%{1}}\
+%if %{-m:1}%{!-m:0}\
+Requires: kernel-modules-core-uname-r = %{KVERREL}\
+%endif\
+AutoReq: no\
+AutoProv: yes\
+%description %{?1:%{1}-}modules-core\
+This package provides essential kernel modules for the %{?2:%{2}-}core kernel
package.\
+%{nil}
+
#
# this macro creates a kernel- meta package.
# %%kernel_meta_package
@@ -1268,6 +1295,7 @@ This package provides commonly used kernel modules for
the %{?2:%{2}-}core kerne
summary: kernel meta-package for the %{1} kernel\
Requires: kernel-%{1}-core-uname-r = %{KVERREL}+%{1}\
Requires: kernel-%{1}-modules-uname-r = %{KVERREL}+%{1}\
+Requires: kernel-%{1}-modules-core-uname-r = %{KVERREL}+%{1}\
Provides: installonlypkg(kernel)\
%description %{1}\
The meta-package for the %{1} kernel\
@@ -1285,6 +1313,7 @@ Provides: kernel-%{?1:%{1}-}core-uname-r =
%{KVERREL}%{?1:+%{1}}\
Provides: installonlypkg(kernel)\
%if %{-m:1}%{!-m:0}\
Requires: kernel-core-uname-r = %{KVERREL}\
+Requires: kernel-%{?1:%{1}-}-modules-core-uname-r = %{KVERREL}%{?1:+%{1}}\
%endif\
%{expand:%%kernel_reqprovconf %{?1:%{1}} %{-o:%{-o}}}\
%if %{?1:1} %{!?1:0} \
@@ -1293,6 +1322,7 @@ Requires: kernel-core-uname-r = %{KVERREL}\
%{expand:%%kernel_devel_package %{?1:%{1}} %{!?{-n}:%{1}}%{?{-n}:%{-n*}}
%{-m:%{-m}}}\
%{expand:%%kernel_devel_matched_package %{?1:%{1}}
%{!?{-n}:%{1}}%{?{-n}:%{-n*}} %{-m:%{-m}}}\
%{expand:%%kernel_modules_package %{?1:%{1}} %{!?{-n}:%{1}}%{?{-n}:%{-n*}}
%{-m:%{-m}}}\
+%{exp
[OS-BUILD PATCHv6 2/2] modules-core: use %posttrans
From: Gerd Hoffmann
modules-core: use %posttrans
Otherwise depmod might not be present yet.
Signed-off-by: Gerd Hoffmann
diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index blahblah..blahblah 100755
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -2874,7 +2874,7 @@ fi\
# %%kernel_modules_core_post []
#
%define kernel_modules_core_post() \
-%{expand:%%post %{?1:%{1}-}modules-core}\
+%{expand:%%posttrans %{?1:%{1}-}modules-core}\
/sbin/depmod -a %{KVERREL}%{?1:+%{1}}\
%{nil}\
%{expand:%%postun %{?1:%{1}-}modules-core}\
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2179
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCHv6 0/2] split sub-rpm kernel-modules-core from kernel-core
From: Gerd Hoffmann on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2179 All kernel modules plus support files (such as the files generated by depmod) are moved to the new kernel-modules-core sub-rpm. The kernel binary plus support files stay in the kernel-core sub-rpm. This essentially includes the files which are copied over to /boot by the kernel-install utility (vmlinuz, System.map, ...). With this in place we have a strict separation between sub-rpms carrying a kernel image and sub-rpms carrying kernel modules. This should make it easier to use alternative kernel image packages, for example an unified kernel. --- redhat/kernel.spec.template | 53 ++-- 1 files changed, 50 insertions(+), 3 deletions(-) ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCHv5 0/0] split sub-rpm kernel-modules-core from kernel-core
From: Gerd Hoffmann on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2179 NOTE: Truncated patchset since committer email 'kernel-t...@fedoraproject.org' does not match the submitter's GitLab public email address 'kra...@redhat.com'. All kernel modules plus support files (such as the files generated by depmod) are moved to the new kernel-modules-core sub-rpm. The kernel binary plus support files stay in the kernel-core sub-rpm. This essentially includes the files which are copied over to /boot by the kernel-install utility (vmlinuz, System.map, ...). With this in place we have a strict separation between sub-rpms carrying a kernel image and sub-rpms carrying kernel modules. This should make it easier to use alternative kernel image packages, for example an unified kernel. --- redhat/kernel.changelog-9.99 | 4 +++ redhat/kernel.spec.template | 55 --- Makefile.rhelver | 2 +- 3 files changed, 56 insertions(+), 5 deletions(-) ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv4 0/0] split sub-rpm kernel-modules-core from kernel-core
From: Gerd Hoffmann on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2179#note_1236168298 Oops, didn't notice they sneaked in on rebase. Will fix. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCHv4 0/0] split sub-rpm kernel-modules-core from kernel-core
From: Gerd Hoffmann on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2179 NOTE: Truncated patchset since committer email 'kernel-t...@fedoraproject.org' does not match the submitter's GitLab public email address 'kra...@redhat.com'. All kernel modules plus support files (such as the files generated by depmod) are moved to the new kernel-modules-core sub-rpm. The kernel binary plus support files stay in the kernel-core sub-rpm. This essentially includes the files which are copied over to /boot by the kernel-install utility (vmlinuz, System.map, ...). With this in place we have a strict separation between sub-rpms carrying a kernel image and sub-rpms carrying kernel modules. This should make it easier to use alternative kernel image packages, for example an unified kernel. --- redhat/kernel.changelog-9.99 | 5 redhat/kernel.spec.template | 55 --- scripts/head-object-list.txt | 1 + Makefile.rhelver | 2 +- 4 files changed, 58 insertions(+), 5 deletions(-) ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCHv3 0/0] split sub-rpm kernel-modules-core from kernel-core
From: Gerd Hoffmann on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2179 NOTE: Truncated patchset since committer email 'kernel-t...@fedoraproject.org' does not match the submitter's GitLab public email address 'kra...@redhat.com'. All kernel modules plus support files (such as the files generated by depmod) are moved to the new kernel-modules-core sub-rpm. The kernel binary plus support files stay in the kernel-core sub-rpm. This essentially includes the files which are copied over to /boot by the kernel-install utility (vmlinuz, System.map, ...). With this in place we have a strict separation between sub-rpms carrying a kernel image and sub-rpms carrying kernel modules. This should make it easier to use alternative kernel image packages, for example an unified kernel. --- redhat/kernel.changelog-9.99 | 5 redhat/kernel.spec.template | 55 --- scripts/head-object-list.txt | 1 + Makefile.rhelver | 2 +- 4 files changed, 58 insertions(+), 5 deletions(-) ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCHv2 0/0] split sub-rpm kernel-modules-core from kernel-core
From: Gerd Hoffmann on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2179 NOTE: Truncated patchset since committer email 'kernel-t...@fedoraproject.org' does not match the submitter's GitLab public email address 'kra...@redhat.com'. All kernel modules plus support files (such as the files generated by depmod) are moved to the new kernel-modules-core sub-rpm. The kernel binary plus support files stay in the kernel-core sub-rpm. This essentially includes the files which are copied over to /boot by the kernel-install utility (vmlinuz, System.map, ...). With this in place we have a strict separation between sub-rpms carrying a kernel image and sub-rpms carrying kernel modules. This should make it easier to use alternative kernel image packages, for example an unified kernel. --- redhat/kernel.changelog-9.99 | 5 redhat/kernel.spec.template | 55 --- scripts/head-object-list.txt | 1 + Makefile.rhelver | 2 +- 4 files changed, 58 insertions(+), 5 deletions(-) ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCH] split sub-rpm kernel-modules-core from kernel-core
From: Gerd Hoffmann
split sub-rpm kernel-modules-core from kernel-core
All kernel modules plus support files (such as the files generated
by depmod) are moved to the new kernel-modules-core sub-rpm.
The kernel binary plus support files stay in the kernel-core sub-rpm.
This essentially includes the files which are copied over to /boot by
the kernel-install utility (vmlinuz, System.map, ...).
With this in place we have a strict separation between sub-rpms carrying
a kernel image and sub-rpms carrying kernel modules. This should make it
easier to use alternative kernel image packages, for example an unified
kernel.
Signed-off-by: Gerd Hoffmann
diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index blahblah..blahblah 100755
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -571,6 +571,7 @@ ExclusiveOS: Linux
%ifnarch %{nobuildarches}
Requires: kernel-core-uname-r = %{KVERREL}
Requires: kernel-modules-uname-r = %{KVERREL}
+Requires: kernel-modules-core-uname-r = %{KVERREL}
%endif
@@ -885,6 +886,7 @@ Provides: kernel = %{specversion}-%{pkg_release}\
%endif\
Provides: kernel-%{_target_cpu} = %{specversion}-%{pkg_release}%{?1:+%{1}}\
Provides: kernel-uname-r = %{KVERREL}%{?1:+%{1}}\
+Requires: kernel%{?1:-%{1}}-modules-core-uname-r = %{KVERREL}%{?1:+%{1}}\
Requires(pre): %{kernel_prereq}\
Requires(pre): %{initrd_prereq}\
Requires(pre): ((linux-firmware >= 20150904-56.git6ebf5d57) if linux-firmware)\
@@ -1207,6 +1209,7 @@ Provides: installonlypkg(kernel-module)\
Provides: kernel%{?1:-%{1}}-modules-internal-uname-r = %{KVERREL}%{?1:+%{1}}\
Requires: kernel-uname-r = %{KVERREL}%{?1:+%{1}}\
Requires: kernel%{?1:-%{1}}-modules-uname-r = %{KVERREL}%{?1:+%{1}}\
+Requires: kernel%{?1:-%{1}}-modules-core-uname-r = %{KVERREL}%{?1:+%{1}}\
AutoReq: no\
AutoProv: yes\
%description %{?1:%{1}-}modules-internal\
@@ -1227,6 +1230,7 @@ Provides: installonlypkg(kernel-module)\
Provides: kernel%{?1:-%{1}}-modules-extra-uname-r = %{KVERREL}%{?1:+%{1}}\
Requires: kernel-uname-r = %{KVERREL}%{?1:+%{1}}\
Requires: kernel%{?1:-%{1}}-modules-uname-r = %{KVERREL}%{?1:+%{1}}\
+Requires: kernel%{?1:-%{1}}-modules-core-uname-r = %{KVERREL}%{?1:+%{1}}\
%if %{-m:1}%{!-m:0}\
Requires: kernel-modules-extra-uname-r = %{KVERREL}\
%endif\
@@ -1249,6 +1253,7 @@ Provides: kernel-modules =
%{version}-%{release}%{?1:+%{1}}\
Provides: installonlypkg(kernel-module)\
Provides: kernel%{?1:-%{1}}-modules-uname-r = %{KVERREL}%{?1:+%{1}}\
Requires: kernel-uname-r = %{KVERREL}%{?1:+%{1}}\
+Requires: kernel%{?1:-%{1}}-modules-core-uname-r = %{KVERREL}%{?1:+%{1}}\
%if %{-m:1}%{!-m:0}\
Requires: kernel-modules-uname-r = %{KVERREL}\
%endif\
@@ -1258,6 +1263,28 @@ AutoProv: yes\
This package provides commonly used kernel modules for the %{?2:%{2}-}core
kernel package.\
%{nil}
+#
+# This macro creates a kernel--modules-core package.
+# %%kernel_modules_core_package [-m]
+#
+%define kernel_modules_core_package(m) \
+%package %{?1:%{1}-}modules-core\
+Summary: Core kernel modules to match the %{?2:%{2}-}core kernel\
+Provides: kernel%{?1:-%{1}}-modules-core-%{_target_cpu} =
%{version}-%{release}\
+Provides: kernel-modules-core-%{_target_cpu} =
%{version}-%{release}%{?1:+%{1}}\
+Provides: kernel-modules-core = %{version}-%{release}%{?1:+%{1}}\
+Provides: installonlypkg(kernel-module)\
+Provides: kernel%{?1:-%{1}}-modules-core-uname-r = %{KVERREL}%{?1:+%{1}}\
+Requires: kernel-uname-r = %{KVERREL}%{?1:+%{1}}\
+%if %{-m:1}%{!-m:0}\
+Requires: kernel-modules-core-uname-r = %{KVERREL}\
+%endif\
+AutoReq: no\
+AutoProv: yes\
+%description %{?1:%{1}-}modules-core\
+This package provides essential kernel modules for the %{?2:%{2}-}core kernel
package.\
+%{nil}
+
#
# this macro creates a kernel- meta package.
# %%kernel_meta_package
@@ -1267,6 +1294,7 @@ This package provides commonly used kernel modules for
the %{?2:%{2}-}core kerne
summary: kernel meta-package for the %{1} kernel\
Requires: kernel-%{1}-core-uname-r = %{KVERREL}+%{1}\
Requires: kernel-%{1}-modules-uname-r = %{KVERREL}+%{1}\
+Requires: kernel-%{1}-modules-core-uname-r = %{KVERREL}+%{1}\
Provides: installonlypkg(kernel)\
%description %{1}\
The meta-package for the %{1} kernel\
@@ -1284,6 +1312,7 @@ Provides: kernel-%{?1:%{1}-}core-uname-r =
%{KVERREL}%{?1:+%{1}}\
Provides: installonlypkg(kernel)\
%if %{-m:1}%{!-m:0}\
Requires: kernel-core-uname-r = %{KVERREL}\
+Requires: kernel-%{?1:%{1}-}-modules-core-uname-r = %{KVERREL}%{?1:+%{1}}\
%endif\
%{expand:%%kernel_reqprovconf %{?1:%{1}} %{-o:%{-o}}}\
%if %{?1:1} %{!?1:0} \
@@ -1292,6 +1321,7 @@ Requires: kernel-core-uname-r = %{KVERREL}\
%{expand:%%kernel_devel_package %{?1:%{1}} %{!?{-n}:%{1}}%{?{-n}:%{-n*}}
%{-m:%{-m}}}\
%{expand:%%kernel_devel_matched_package %{?1:%{1}}
%{!?{-n}:%{1}}%{?{-n}:%{-n*}} %{-m:%{-m}}}\
%{expand:%%kernel_modules_package %{?1:%{1}} %{!?{-n}:%{1}}%{?{-n}:%{-n*}}
%{-m:%{-m}}}\
+%{exp
Re: Small rant: installer environment size
On Thu, Dec 08, 2022 at 11:49:16AM -0800, Adam Williamson wrote: > On Thu, 2022-12-08 at 20:23 +0100, drago01 wrote: > > The problem I see here is not the presence of the firmware on the > > image, > > but the fact that it seems to be loaded into memory despite not being > > used. > > This is the direction Daniel was thinking down. I'm waiting for someone > with more expertise to reply, but I suspect the reply is going to be > along the lines of "yes, we *can* do that, but it's somewhat tricky > work that involves thinking about lots of paths that aren't obvious, > and somebody would need to dedicate their time to working on that". Split install.img into install.img + firmware.img? I think we already have support for multiple images (I see requests for updates.img when watching httpd logs while doing network installs), so the split should be easy. The somewhat more tricky part is probably to figure whenever we need the firmware or not. take care, Gerd ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH 0/3] pre-generated initrd and unified kernels
> > So how about splitting 'kernel-core' into a modules and a kernel binary
> > package? Like this:
> >
> > kernel-modules-core - the modules from current 'kernel-core'
> > kernel-modules-standard - current 'kernel-modules' renamed (maybe
> > skip rename, but I think it'll be less
> > confusing that way).
> > kernel-modules-{extra,internal} - no changes
> >
> > kernel-binary-bare - the kernel binary from current 'kernel-core'
> > kernel-binary-uki-virt - unified kernel (same as 'kernel-unified-virt'
> > in the test package repo).
> > kernel-{doc,tools*,headers,...} - no changes
>
> Yes, please! Such a split would be very welcome.
https://src.fedoraproject.org/fork/kraxel/rpms/kernel/commits/f37.newsplit
https://copr.fedorainfracloud.org/coprs/kraxel/kernel.testbuilds/
Did not (yet?) rename the kernel package to kernel-binary-bare. So the
kernel-modules -> kernel-modules-standard rename is there, and moving
the modules into kernel-modules-core. That opens up the question what
we should do with all the (non-module) files in /lib/modules//.
The modules.* files (generated by depmod) clearly belong into the
modules package.
The files copied over to /boot by the kernel-install grub plugin should
stay in the kernel binary package.
Not so sure about the other files (vdso for example). Leaving them in
kernel-modules-core should work fine as that package will continue to
be installed even when we replace the traditional kernel package with a
unified kernel package. But maybe it makes sense to move them into a
separate package?
My current split looks like this:
# rpm -ql kernel-core-6.0.9-300.newsplit.4.fc37.x86_64
/boot/.vmlinuz-6.0.9-300.newsplit.4.fc37.x86_64.hmac
/boot/System.map-6.0.9-300.newsplit.4.fc37.x86_64
/boot/config-6.0.9-300.newsplit.4.fc37.x86_64
/boot/initramfs-6.0.9-300.newsplit.4.fc37.x86_64.img
/boot/symvers-6.0.9-300.newsplit.4.fc37.x86_64.gz
/boot/vmlinuz-6.0.9-300.newsplit.4.fc37.x86_64
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/.vmlinuz.hmac
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/System.map
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/config
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/symvers.gz
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/vmlinuz
/usr/share/licenses/kernel-core
/usr/share/licenses/kernel-core/COPYING-6.0.9-300.newsplit.4.fc37
# rpm -ql kernel-modules-core-6.0.9-300.newsplit.4.fc37.x86_64 | grep -v
/kernel/
/lib/modules
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/build
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/kernel
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/modules.block
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/modules.builtin
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/modules.builtin.modinfo
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/modules.drm
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/modules.modesetting
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/modules.networking
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/modules.order
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/source
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/systemtap
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/updates
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/vdso
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/vdso/vdso32.so
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/vdso/vdso64.so
/lib/modules/6.0.9-300.newsplit.4.fc37.x86_64/weak-updates
/usr/share/doc/kernel-keys/6.0.9-300.newsplit.4.fc37.x86_64
/usr/share/doc/kernel-keys/6.0.9-300.newsplit.4.fc37.x86_64/kernel-signing-ca-20140212.cer
/usr/share/doc/kernel-keys/6.0.9-300.newsplit.4.fc37.x86_64/kernel-signing-ca-20200609.cer
/usr/share/doc/kernel-keys/6.0.9-300.newsplit.4.fc37.x86_64/kernel-signing-ca.cer
comments?
take care,
Gerd
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH 0/3] pre-generated initrd and unified kernels
Hi,
> > > Sure. Having a feature page drawing that big picture would be helpful
> > > for these discussions I think ...
> >
> > Definitely a system wide change. While there are some logistics to
> > work out on the kernel side, most of the work is packaging. I would
> > guess timelines will need to be defined by the teams where code is
> > needed.
>
> https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
Resuming that discussion. State of affairs:
Test packages are available:
https://copr.fedorainfracloud.org/coprs/kraxel/unified.kernel/
Kickstart install files and helper scripts:
https://gitlab.com/kraxel/fedora-uki
Prebuilt qemu VM test images:
https://www.kraxel.org/fedora-uki/
Right now I'm trying to figure how to handle kernel installs best.
Currently the kickstart files use ...
touch /etc/kernel/install.d/20-grub.install
touch /etc/kernel/install.d/50-dracut.install
.. to avoid kernel-core post-install creating a loader/entries/*.conf
snippet and dracut creating an (unused) initrd. Which is ok for a
Proof-of-Concept, but clearly a non-starter as long-term solution.
I've played around a bit with kernel-install script plugins trying to
detect the presence of a unified kernel image and change behavior then.
That feels a bit hackish though, and I suspect making that robust and
covering all corner cases (like switching between unified and
non-unified kernels) will be next to impossible.
I think a better way forward is to have strictly separate rpms for
kernels and modules. Today 'kernel-core' has both the (non-unified)
kernel binary and the essential modules. Due to the modules being in
there it must be installed even if we don't want use the kernel binary.
So how about splitting 'kernel-core' into a modules and a kernel binary
package? Like this:
kernel-modules-core - the modules from current 'kernel-core'
kernel-modules-standard - current 'kernel-modules' renamed (maybe
skip rename, but I think it'll be less
confusing that way).
kernel-modules-{extra,internal} - no changes
kernel-binary-bare - the kernel binary from current 'kernel-core'
kernel-binary-uki-virt - unified kernel (same as 'kernel-unified-virt'
in the test package repo).
kernel-{doc,tools*,headers,...} - no changes
With that in place kernel-binary-* packages are self-contained. They
just install/remove the kernel from /boot and/or ESP on install/remove.
No need to check whenever *other* packages are present and change
behavior based on that.
Comments?
take care,
Gerd
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH 0/3] pre-generated initrd and unified kernels
Hi, > > > It would likely > > > touch kernel, anaconda, systemd and cloud images, so there's some > > > coordination & discussion needed to agree on the big picture. > > > > Sure. Having a feature page drawing that big picture would be helpful > > for these discussions I think ... > > Definitely a system wide change. While there are some logistics to > work out on the kernel side, most of the work is packaging. I would > guess timelines will need to be defined by the teams where code is > needed. https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 Comments? Something important missing? (First time I do a change page ...) take care, Gerd ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH 0/3] pre-generated initrd and unified kernels
Hi, > > Should we have a Fedora feature page for unified kernel support? > > I'm not sure we especially want to publicise unified kernel images as > a standalone thing to users, as it is more of just a building block. > > If we're going to show any "feature", I think it probably ought to be > oriented around a higher level user solution, of which unified kernel > images are just one piece of the puzzle. Yes. Just the kernel package updates are not enough. The bare minimum which I think makes sense as feature is: (1) adding the unified kernel sub-rpm discussed here, and (2) bootloader support (be that sd-boot or grub or both), and (3) kernel install script support (so 'dnf update' kernel updates work). With that in place it should be possible to install VMs using the unified kernel sub-rpm and everything works as it did before, even when it requires some hacks here and there, such as tagging partitions manually or in kickstart %post for https://systemd.io/DISCOVERABLE_PARTITIONS/ The above will already plug the initrd hole. > eg I would see "Trusted boot for cloud images" as a feature, by which > I mean publishing cloud images capable of using SecureBoot and vTPM, > to do attestable boot on UEFI, without the unsigned initrd hole present > as today. > > So, this would mean uing unified kernel images, either directly launched > from shim, or with sd-boot in there to provide a UI selection. Either > way not grub, since it is impractical to do attestation with grub's use > of PCRs. Also likely mean use of discoverable partitions. Yep, that all makes sense, but I'd tend to not add that as 'required' to the feature page. My list of nice-to-have optional stuff: (4) attestable boot (i.e. no grub b/c PCR mess). (5) provide pre-calculated PCRs (could be published as kernel-pcrs sub-rpm). (6) add discoverable partitions to anaconda (so we don't need %post hacks). (7) add discoverable partitions to image builder (and whatever else generates cloud images). (8) switch cloud images to unified kernels. I think I've seen fedora feature pages with optional sub-goals before, even though I can't find one right now, so I think it should be possible to handle things that way. > I know there's been some desire to move Fedora cloud images to be UEFI > only, so it might dovetail with that to some degree. Hack grub so it can pull out kernel + initrd out of a unified kernel image and boot unified kernel images in bios mode that way should be possible. Would allow to migrate cloud images to unified kernels without requiring UEFI. > It would likely > touch kernel, anaconda, systemd and cloud images, so there's some > coordination & discussion needed to agree on the big picture. Sure. Having a feature page drawing that big picture would be helpful for these discussions I think ... take care, Gerd ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH 0/3] pre-generated initrd and unified kernels
On Fri, Sep 02, 2022 at 12:07:38PM +0100, Daniel P. Berrangé wrote: > On Fri, Sep 02, 2022 at 11:21:03AM +0200, Gerd Hoffmann wrote: > > Hi, > > > > > Thus my patch proposed two images, to be distributed in the same > > > 'kernel-virt-unified' sub-RPM. > > > > > > * vmlinuz-virt.efi created using dracut arg > > > > > > --kernel-cmdline 'console=ttyS0 console=tty0 quiet rhgb' > > > > > > * vmlinuz-virt-verbose.efi created using dracut arg > > > > > > --kernel-cmdline 'console=ttyS0 console=tty0' > > > > Hmm, I think we should look for a more elegant solution to this problem > > than having two large, 99% identical images. > > > > One option could be to have systemd-stub support multiple .cmdline > > sections and allowing the user to pick one of them. > > > > Another option could be to have a whitelist of options the user is > > allowed to add/remove which then could include stuff like 'console=' > > and 'quiet'. > > FYI, I filed an RFE with systemd to get their opinion on the idea > of alternative cmdline entries, and/or validated option lists: > > https://github.com/systemd/systemd/issues/24539 So, how move forward with this best? Drop the verbose variant for now, add support for that once systemd-stub support for multiple command lines is sorted upstream? Should we have a Fedora feature page for unified kernel support? take care, Gerd ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH 0/3] pre-generated initrd and unified kernels
Hi, > > (3) Support /boot being vfat (depending on #2, sd-boot needs this). > > Technically in the cloud image scenario we don't need to especially > care about /boot being a dedicated partition. We could do everything > exclusively in the /boot/efi partition which is already vfat, and not > bother creating any /boot partition, since we can ensure /boot/efi is > large enough. > > If we forsee the unified EFI kenrels being useful for bare metal, > however, then use of /boot as vfat becomes more important, as we > can't assume the hardware vendor's pre-created /boot/efi is > sufficiently large. Didn't want to open that discussion right now. My impression is that Gedora & RHEL settled on the approach to have both /boot and /boot/efi everywhere because some cases require this and having only a single scheme simplifies development + testing. Changing this looks not that easy to me, we have RPMs dropping files into /boot/efi/EFI and I suspect this is hard-wired in various places in anaconda and elsewhere. So, yes, for cloud images we don't really need this as we can make the ESP as large as we want, but I have my doubts that deriving from the standard way fedora handles things gives us enough benefits to be worth the trouble. > Thus my patch proposed two images, to be distributed in the same > 'kernel-virt-unified' sub-RPM. > > * vmlinuz-virt.efi created using dracut arg > > --kernel-cmdline 'console=ttyS0 console=tty0 quiet rhgb' > > * vmlinuz-virt-verbose.efi created using dracut arg > > --kernel-cmdline 'console=ttyS0 console=tty0' Hmm, I think we should look for a more elegant solution to this problem than having two large, 99% identical images. One option could be to have systemd-stub support multiple .cmdline sections and allowing the user to pick one of them. Another option could be to have a whitelist of options the user is allowed to add/remove which then could include stuff like 'console=' and 'quiet'. take care, Gerd ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH 0/3] pre-generated initrd and unified kernels
On Wed, Aug 31, 2022 at 06:12:19AM -0700, stan via kernel wrote: > On Wed, 31 Aug 2022 14:46:15 +0200 > Gerd Hoffmann wrote: > > > Here is a little patch series to kick off a discussion on > > pre-generated initrd images and unified kernels. Lets start with a > > description of the patches: > > > > Patch #1 adds a dracut config file, targeting virtual machines. > > Given that most physical machines have either sata or nvme disks > > these days it probably boots most physical systems too. > > > > Patch #2 adds a sub-package with an initrd image. > > > > Patch #3 adds a sub-package with an unified kernel. > > > > The goal is to move away from initrd images being generated on the > > installed machine. They are generated while building the kernel > > package instead. Main motivation for this move is to make the distro > > more robust and more secure. > > A worthy goal. > > > Comments? Reviews? Suggestions? > > How will this impact people who build a custom kernel locally? Will > it still be possible? Wouldn't be different than local builds today, unified kernels are not special and the signing process will work the same way it works for non-unified kernels. Essentially you have the options to either sign your custom kernel with your own keys (and add them to the uefi/shim key database) or turn off secure boot. take care, Gerd ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[PATCH 2/3] [testing] add a kernel-initrd-virt sub-RPM
Signed-off-by: Gerd Hoffmann
---
kernel.spec | 21 +
1 file changed, 21 insertions(+)
diff --git a/kernel.spec b/kernel.spec
index 3a45243c0442..197846f4f834 100755
--- a/kernel.spec
+++ b/kernel.spec
@@ -817,6 +817,7 @@ Source82: update_scripts.sh
Source84: mod-internal.list
Source85: mod-partner.list
+Source86: dracut-virt.conf
Source100: rheldup3.x509
Source101: rhelkpatch1.x509
@@ -1296,6 +1297,9 @@ Requires: kernel-core-uname-r = %{KVERREL}\
%endif\
%{expand:%%kernel_debuginfo_package %{?1:%{1}}}\
%endif\
+%package %{?1:%{1}-}initrd-virt\
+Summary: %{variant_summary} initrd for VMs\
+Provides: installonlypkg(kernel)\
%{nil}
#
@@ -1364,6 +1368,12 @@ Linux operating system. The kernel handles the basic
functions
of the operating system: memory allocation, process allocation, device
input and output, etc.
+%description debug-initrd-virt
+Prebuilt debug kernel initrd for VMs.
+
+%description initrd-virt
+Prebuilt default kernel initrd for VMs.
+
%if %{with_ipaclones}
%kernel_ipaclones_package
%endif
@@ -2131,6 +2141,15 @@ BuildKernel() {
touch lib/modules/$KernelVer/modules.builtin
fi
+# pre-generate initrd
+dracut --conf=%{SOURCE86} \
+ --confdir=$(mktemp -d) \
+ --verbose \
+ --kver "$KernelVer" \
+ --kmoddir lib/modules/$KernelVer \
+ lib/modules/$KernelVer/initrd
+lsinitrd lib/modules/$KernelVer/initrd
+
remove_depmod_files
# Go back and find all of the various directories in the tree. We use this
@@ -3101,6 +3120,8 @@ fi
%{expand:%%files -f debuginfo%{?3}.list %{?3:%{3}-}debuginfo}\
%endif\
%endif\
+%{expand:%%files %{?3:%{3}-}initrd-virt}\
+/lib/modules/%{KVERREL}%{?3:+%{3}}/initrd\
%if %{?3:1} %{!?3:0}\
%{expand:%%files %{3}}\
%endif\
--
2.37.2
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[PATCH 3/3] [testing] add a kernel-unified-virt sub-RPM
From: Daniel P. Berrangé
This sub package contains a unified kernel/initrd/cmdline
image as an EFI binary, targetting booting of virtual
machines.
Signed-off-by: Daniel P. Berrangé
---
kernel.spec | 44
1 file changed, 44 insertions(+)
diff --git a/kernel.spec b/kernel.spec
index 197846f4f834..a7129a9b98c5 100755
--- a/kernel.spec
+++ b/kernel.spec
@@ -88,6 +88,12 @@ Summary: The Linux kernel
%global zipmodules 1
%endif
+%ifarch x86_64
+%global efiunified 1
+%else
+%global efiunified 0
+%endif
+
%if %{zipmodules}
%global zipsed -e 's/\.ko$/\.ko.xz/'
# for parallel xz processes, replace with 1 to go back to single process
@@ -690,6 +696,14 @@ BuildRequires: llvm
BuildRequires: lld
%endif
+%if %{efiunified}
+BuildRequires: dracut
+# For dracut UEFI unified binaries
+BuildRequires: binutils
+# For the initrd
+BuildRequires: lvm2
+%endif
+
# Because this is the kernel, it's hard to get a single upstream URL
# to represent the base without needing to do a bunch of patching. This
# tarball is generated from a src-git tree. If you want to see the
@@ -1300,6 +1314,11 @@ Requires: kernel-core-uname-r = %{KVERREL}\
%package %{?1:%{1}-}initrd-virt\
Summary: %{variant_summary} initrd for VMs\
Provides: installonlypkg(kernel)\
+%if %{efiunified}\
+%package %{?1:%{1}-}unified-virt\
+Summary: %{variant_summary} unified kernel/initrd for VMs\
+Provides: installonlypkg(kernel)\
+%endif\
%{nil}
#
@@ -1374,6 +1393,14 @@ Prebuilt debug kernel initrd for VMs.
%description initrd-virt
Prebuilt default kernel initrd for VMs.
+%if %{efiunified}
+%description debug-unified-virt
+Prebuilt debug unified kernel/initrd for VMs.
+
+%description unified-virt
+Prebuilt default unified kernel/initrd for VMs.
+%endif
+
%if %{with_ipaclones}
%kernel_ipaclones_package
%endif
@@ -2150,6 +2177,19 @@ BuildKernel() {
lib/modules/$KernelVer/initrd
lsinitrd lib/modules/$KernelVer/initrd
+%if %{efiunified}
+# pre-generate unified kernel/initrd
+dracut --conf=%{SOURCE86} \
+ --confdir=$(mktemp -d) \
+ --verbose \
+ --uefi \
+ --kernel-image `pwd`/lib/modules/$KernelVer/vmlinuz \
+ --kernel-cmdline 'console=ttyS0 console=tty0' \
+ --kver "$KernelVer" \
+ --kmoddir lib/modules/$KernelVer \
+ lib/modules/$KernelVer/vmlinuz.efi
+%endif
+
remove_depmod_files
# Go back and find all of the various directories in the tree. We use this
@@ -3122,6 +3162,10 @@ fi
%endif\
%{expand:%%files %{?3:%{3}-}initrd-virt}\
/lib/modules/%{KVERREL}%{?3:+%{3}}/initrd\
+%if %{efiunified}\
+%{expand:%%files %{?3:%{3}-}unified-virt}\
+/lib/modules/%{KVERREL}%{?3:+%{3}}/%{?-k:%{-k*}}%{!?-k:vmlinuz.efi}\
+%endif\
%if %{?3:1} %{!?3:0}\
%{expand:%%files %{3}}\
%endif\
--
2.37.2
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[PATCH 1/3] [testing] virtual machine dracut config
Signed-off-by: Gerd Hoffmann --- dracut-virt.conf | 26 ++ 1 file changed, 26 insertions(+) create mode 100644 dracut-virt.conf diff --git a/dracut-virt.conf b/dracut-virt.conf new file mode 100644 index ..98b565349743 --- /dev/null +++ b/dracut-virt.conf @@ -0,0 +1,26 @@ +# generic + compressed please +hostonly="no" +compress="xz" + +# VMs can't update microcode anyway +early_microcode="no" + +# modules: basics +dracutmodules+=" base systemd systemd-initrd dracut-systemd dbus dbus-broker usrmount shutdown " + +# modules: storage support +dracutmodules+=" dm lvm rootfs-block fs-lib " + +# drivers: virtual buses, pci +drivers+=" virtio-pci virtio-mmio "# qemu-kvm +drivers+=" hv-vmbus pci-hyperv " # hyperv +drivers+=" xen-pcifront " # xen + +# drivers: storage +drivers+=" ahci nvme scsi-hd scsi-cd " # generic +drivers+=" virtio-blk virtio-scsi "# qemu-kvm +drivers+=" hv-storvsc "# hyperv +drivers+=" xen-blkfront " # xen + +# filesystems +filesystems+=" vfat ext4 xfs btrfs overlay " -- 2.37.2 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[PATCH 0/3] pre-generated initrd and unified kernels
Hi,
Here is a little patch series to kick off a discussion on pre-generated
initrd images and unified kernels. Lets start with a description of the
patches:
Patch #1 adds a dracut config file, targeting virtual machines. Given
that most physical machines have either sata or nvme disks these days
it probably boots most physical systems too.
Patch #2 adds a sub-package with an initrd image.
Patch #3 adds a sub-package with an unified kernel.
The goal is to move away from initrd images being generated on the
installed machine. They are generated while building the kernel package
instead. Main motivation for this move is to make the distro more
robust and more secure.
When shipping the initrd as rpm it is possible to check it with the
usual tools ('rpm --verify' for example). TPM measurements are much
more useful because it is possible to pre-calculate the PCR values for a
given kernel version.
When shipping a unified kernel image (containing kernel, initrd, cmdline
and signature) we get the additional benefit that the initrd is covered
by the signature so secure boot will actually be secure.
So, while unified kernels are clearly the better approach it is also the
one which needs some changes in various packages. For an initrd image
the hooks needed are in place thanks to CoreOS shipping initrd images
today. Opt-in by install the sub-rpm and everything JustWorks[tm].
To make unified kernels work smoothly a number of changes are needed
(beside the kernel rpm changes):
(1) Add support for unified kernels to the kernel update scripts.
(/usr/lib/kernel/install.d/*).
(2) Add boot loader support for unified kernel images:
(a) either switch to sd-boot which already supports this.
(b) or add support to grub2 (improve blscfg downstream patch).
(3) Support /boot being vfat (depending on #2, sd-boot needs this).
(4) Remove configuration information (and secrets) from initrd images
and kernel command line.
Most important item here is root the filesystem location, which
should be doable using https://systemd.io/DISCOVERABLE_PARTITIONS/
for many use cases.
Can initially be handled in anaconda kickstart %post scripts.
Long-term we need proper support in anaconda (and any other tool
used to install or generate cloud images), especially if we want
make unified kernel images the default some day.
(5) There might be more ...
I think the best way forward is to skip the initrd image interim step
and try go straight to unified kernel image support, starting with
virtual machines & cloud images, when things are working smoothly there
go expand to cover more use cases. I think it makes sense to start with
the kernel changes.
Comments? Reviews? Suggestions?
thanks & take care,
Gerd
Daniel P. Berrangé (1):
[testing] add a kernel-unified-virt sub-RPM
Gerd Hoffmann (2):
[testing] virtual machine dracut config
[testing] add a kernel-initrd-virt sub-RPM
dracut-virt.conf | 26 +++
kernel.spec | 65
2 files changed, 91 insertions(+)
create mode 100644 dracut-virt.conf
--
2.37.2
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Enabling btusb autosuspend by default
On Tue, Nov 14, 2017 at 11:32:12AM -0700, Chris Murphy wrote: > > I find it ironic that this misbehaving hardware is Intel's USB stuff, > in their NUC, and powertop is an Intel managed project. I'd guess the > powertop folks would already know better than to apply autosuspend to > Intel USB hardware. Well, typically the problem is the usb device (i.e. the keyboard), not the host adapter (xhci these days). Intel building keyboards is news to me ... cheers, Gerd ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Re: Enabling btusb autosuspend by default
Hi, > This is really useful work. I'm already seeing ~20% battery > improvement with Fedora 27 + 4.14.0-0.rc8.git3.1.fc28.x86_64 on an HP > Spectre, and so far no regressions. I get better battery life with > this combination than running Windows 10 with all the HP specific > drivers for this model. > > Some tips on how regressions might manifest and what information to > include in a good bug report would be useful. e.g. on an Intel NUC > when I run powertop --auto-tune, and walk away (it's a server so it > might be days) and come back the keyboard won't work. I've never done > any troubleshooting other than just disable the powertop systemd unit, > I'm vaguely suspicious of usb autosuspend and it not waking up when > keys are pressed. autosuspend has a high chance to be the root cause for this one. Yes, its very messy, mostly due to bad hardware. In qemu it took us quite some effort to get autosuspend working. It's very useful there too, usb hostadapter power consumtion on a laptop translates to cpu cycles for usb hostadapter emulation for a virtual machine. The fundamental problem is that hardware exists claiming to support autosuspend, but it's not working properly. Effect is exactly what you see: device stops working. Result is that operating systems don't enable autosuspend by default, to avoid disturbing users. udev has a whitelist of known-good hid devices (/lib/udev/rules.d/42-usb-hid-pm.rules) to deal with that. qemu hid devices are listed there, that way qemu has automatic autosuspend for linux guests. Microsoft created some "os-specific" usb descriptors which devices can define. One of the things you can do with that is set registry entries for the device. Qemu uses that to automatically enable autosuspend on windows guests, by setting SelectiveSuspendEnabled to 1. Microsoft specs: https://msdn.microsoft.com/en-us/library/windows/hardware/ff537430.aspx Qemu code: https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/desc-msos.c;h=3652919815777d637ed4f716772f9c1ce2d0b819;hb=HEAD Possibly this can be used on linux too, to figure which devices are known-good, without having to maintain a whitelist ... cheers, Gerd ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Re: x86 Architecture SIG
On Wed, 2017-10-04 at 10:47 +, Jia Yuan Lo wrote: > > * We have decided to drop support for PAE, so please feel free to > > disable it on the next > > build > > I suppose people who wants to use more than 4GB of RAM (and all the > other x64 benefits) should just use 64bit altogether... Indeed, if you have > 4G of physical address space to handle you certainly want a 64bit kernel these days. The only reason for keeping PAE for 32bit kernels would be NX support (which requires 64bit page table entries so it works in PAE mode only). cheers, Gerd ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Re: Adding out-of-tree wifi drivers to the Fedora kernel pkg
Hi, > > Currently we're crippling our user experience by refusing > > to ship drivers support this hardware even though there are > > fully open drivers to support these. > And that's the problem. This happens all the time with kernel > drivers, everyone wants the end result of a driver but the > work to actually make it sustainable never gets done. Unless > a driver is actually merged in the upstream kernel, it's not > going to work in the long term. I'd say it is fine to include out-of-tree drivers in case there is (a) is someone maintaining the patches (which Hans promised to do here), and (b) there is a plan for upstream supporting the hardware, so we don't end up maintaining these patches forever. And IMO both "someone actively works on upstreaming the driver" and "support for this hardware will be added to another driver (such as rtl8xxxu)" are good as upstream plan. cheers, Gerd ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Re: Modular Kernel Packaging for Cloud
Hi, I'm not overly thrilled with having multi-tiered driver packages. That leads to major headaches when we start shuffling things around from one driver package to another. The current solution I have prototyped is a kernel-core/kernel-drivers split. Here core could be analogous to cloud, but I imagine it will be useful for other things. People wanting to do PCI passthrough can just install the kernel-drivers package. Agree, I don't think it makes much sense to split things into many small pieces. - Do you need/want a firewall (requires iptables, etc)? I'd say yes by default, but being able to remove it might be useful (kernel-netfilter subpackage)? - Do you need/want NFS or other cloudy storage things (for gluster?)? I'm personally using NFS for host/guest filesystem sharing, so I'd vote yes. - Do you need/want openvswitch? I think no. That's a host side thing and this is about the guest kernel, right? The list of modules I have in my local rawhide KVM guest is below. The snd_* related drivers probably aren't necessary. The btrfs and things it depends on can be ignored (unless you plan on switching from ext4). Depends on what is targeted. Strictly cloud? Or also someone running Fedora as a guest in virt-manager / boxes? I'd tend to include drivers for pretty much everything qemu can emulate. uinput 17708 1 spice guest agent uses this. bluetooth 445507 5 bnep cfg80211 583354 0 bluetooth+wireless are not needed, dunno why they are loaded. snd_hda_codec_generic66943 1 snd_hda_intel 56588 4 For the qemu HDA soundcard. Should be included if desktop usecase should be covered too. qxl74078 2 gpu driver. There are also cirrus + bochs-drm for qemu. vmware vga has a drm driver too. They should be included. ata_generic12910 0 pata_acpi 13038 0 IDE. Needed. Qemu can emulate AHCI too, should be included (but I think that is =y anyway). Qemu can emulate a bunch of SCSI HBAs. Don't think we need the drivers for them (except virtio-scsi). vmware emulates SCSI HBAs too. pvscsi should be included. Dunno about the older ones, there was for example some buslogic emulation in older vmware workstation versions ... USB: Qemu can also emulate uhci + ehci + xhci, should be included. Also usb-storage and generic hid support (for the usb tablet). IIRC most of this is =y anyway. NIC: e1000, rtl8139 (qemu), tulip (hyperv), dunno about vmware. qemu can also emulate a bunch of other nics such as ne2k, but I think those are not relevant in practice and not needed. Of course all paravirtual drivers should be included too, i.e. * all virtio (for qemu) * all xen frontend (for xen, the backend drivers are for the host side and are not needed in the guest). * all hyperv (for hyperv) HTH, Gerd ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Modular Kernel Packaging for Cloud
Hi, Agree, I don't think it makes much sense to split things into many small pieces. - Do you need/want a firewall (requires iptables, etc)? I'd say yes by default, but being able to remove it might be useful (kernel-netfilter subpackage)? So you agree multi-tiered subpackages is a bad idea, On the hardware support side it is a bad idea I think. Too many different use cases and lines between them are blurry, so I suspect it becomes messy quickly if you try to split it fine-grained. but then you propose a netfilter specific subpackage? ... Probably not. They'll likely just be in kernel-core. all netfilter modules is pretty clear and so is the use case (=want firewall). But maybe not worth the trouble, didn't check what size they sum up to. cheers, Gerd ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: CONFIG_USB_UAS
Hi, If you want to be responsible for dealing with any bugs we get against it, and work on improving it upstream, we'll be happy to enable it. Patches went upstream last merge window. Can we try flip the switch for 3.6-rc1+ and see how it goes? thanks, Gerd ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
CONFIG_USB_UAS
Hi, Any specific reason why CONFIG_USB_UAS is not enabled? If not, can it be enabled please (rawhide f17)? thanks, Gerd ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
