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. >> >> 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 -- Vitaly -- _______________________________________________ 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
