Am 08.08.24 um 13:18 schrieb Vitaly Kuznetsov:
Julian Sikorski <belegdol@xxxxxxxxx> writes:
Am 07.08.24 um 14:32 schrieb Julian Sikorski:
Am 06.08.24 um 10:15 schrieb Julian Sikorski:
Am 06.08.24 um 09:37 schrieb Vitaly Kuznetsov:
Julian Sikorski <belegdol@xxxxxxxxx> writes:
Am 05.08.24 um 11:07 schrieb Vitaly Kuznetsov:
Julian Sikorski <belegdol@xxxxxxxxx> writes:
Hi list,
I recently got curious about unified kernel images and what they
bring
to the table. While informing myself about these, the following
questions came to mind:
- ESP partition size: my laptop has it set at 260 MB by the laptop
vendor, my desktop has it at 100 MB. Recommendation is 200 to 500 MB
[0]. This seems too little, given that now the /boot partition on my
desktop is 512 MB full with 3 kernels installed. Or are the UKIs
packed
more efficiently? Moreover, resizing ESP is somewhat challenging
due to
a parted bug [1][2]. Are there plans to make this more user-friendly
once UKIs become more prevalent?
Hey Julian,
are you trying 'kernel-uki-virt' package or building your own UKI?
With
'kernel-uki-virt' we're mostly targeting virtualized and cloud
environments but bare metal can certainly be tried too! The size of
the
packaged vmlinuz-virt.efi is 68Mb now so if you keep three of them in
your ESP, you need 210Mb or so. 256 MB feels limiting but I don't
think
anything prevents from creating a bigger ESP. I'm not sure about
resizing partitions but if you're ready to wipe out your hard drive
completely, it should work.
Hi Vitaly,
I was referring to trying out `kernel-uki-virt`. I have now bit the
bullet and installed it on my laptop with 260 MiB ESP. System has
booted
normally, except that there was a lot more console output than with
grub. I guess this make sense if cloud images are the primary target
here.
Yes, the kernel command line we have is 'console=tty0 console=ttyS0'
and we don't do boot splash.
With one UKI kernel I am already at 100 MiB full, meaning that trying
that on my desktop is out of question for the moment as I do not have
the spare capacity to wipe out the entire drive. On my desktop I have
actually already increased the partition to 500 MiB, but due to the bug
mentioned earlier the filesystem is still at 100 MiB. Looks like it
might need to be looked into if the UKI is ever considered default for
Workstation. 100 MiB is lower than current Microsoft default, but I
guess it was the default for 512 byte sector drives back when I
installed it. I am guessing nobody cared for the parted bug until now
because except for the ESP, dealing with tiny FAT16 partitions is
hardly
a frequent use case.
- does UKI work with third-party kernel modules like nvidia?
Yes, there's no difference between the traditional kernel layout
and UKI
if you want to use third party modules. The only issue (not
specific to
UKI) is SecureBoot. If you want to keep it on, you may need to either
enroll your key into SecureBoot 'db' (possible on virtualized and
cloud
environments) or deal with 'MOK' (the only sane option for bare
metal).
I am already doing it for my desktop machine for nvidia and xone
modules
so I am happy to hear it should keep working as expected. Does mokutil
enroll MOKs in a way that they are also usable by the direct boot
option? I could never see my MOK key listed in the UEFI setup yet
it was
working as expected.
If by 'direct boot' you mean 'shim -> UKI' then yes, MOK should work the
exact same way. You won't see MOK keys in the UEFI setup as MOK is a
feature of shim, not your firmware's. In case you do 'direct' boot of
the UKI from the firmware, MOK won't work.
To be honest, I am not sure if I am using shim. I followed the
instructions from the feature wiki page:
https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_2#Switch_an_existing_install_to_use_UKIs.
I then booted the UKI kernel from the UEFI boot entry which got created
Is there a way of enrolling a key into the firmware?
Also, I'm not sure how you're managing your UEFI variables, but we now
have 'kernel-bootcfg' tool ('python3-virt-firmware' package) which makes
it really convenient. In particular, it can automate A/B booting (the
new UKI is tried once and becomes the default if it boots successfully).
It worked to some extent here: BootNext booted UKI kernel as expected,
but for some reason it is still at the end of the BootOrder with grub
entry remaining the default. Maybe I messed something up, I will check
again once next kernel update arrives.
Make sure 'kernel-bootcfg-boot-successful' service is enabled and check
what's its status after a successful boot into the new kernel.
Service is enabled and active. These are the journal entries after the
successful BootNext:
Aug 07 14:29:56 kernel-bootcfg[900]: INFO: No update needed, BootCurrent
is already in BootOrder.
Aug 07 14:29:56 kernel-bootcfg[900]: INFO: Updating
/boot/efi/EFI/fedora/BOOTX64.CSV
Aug 07 14:29:54 systemd[1]: Starting
kernel-bootcfg-boot-successful.service - UKI Successful Boot...
Aug 07 14:29:55 systemd[1]: Finished
kernel-bootcfg-boot-successful.service - UKI Successful Boot.
Aug 07 14:40:55 systemd[1]: kernel-bootcfg-boot-successful.service:
Deactivated successfully.
Aug 07 14:40:55 systemd[1]: Stopped
kernel-bootcfg-boot-successful.service - UKI Successful Boot.
I posted more data in the bug I filed.
Something seems to indeed be off with setting up the BootOrder. This is
how it looks like after a successfull BootNext:
~$ kernel-bootcfg --show
# C - BootCurrent, N - BootNext, O - BootOrder
# --------------------------------------------
# O - 0002 - Fedora
# O - 0000 - Windows Boot Manager
# O - 0001 - Fedora Linux 40 (Workstation Edition)
6.9.12-200.fc40.x86_64 (UKI)
# C O - 0003 - Fedora Linux 40 (Workstation Edition)
6.10.3-200.fc40.x86_64 (UKI)
I am happy to report a bug and provide more info. What would be the
correct component?
Use 'python-virt-firmware'. More specifically, you need 'uki-direct'
sub-package of it but Bugzilla doesn't have sub-components.
Thanks for testing all this!
Cc: Gerd
Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=2303676
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
