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? - does UKI work with third-party kernel modules like nvidia? - grub-less UKIs mean updating efivars with every kernel update. GRUB developers expressed concerns this might wear down the NVRAM chips. Was this ever looked into in more detail?
Thanks for your responses in advance!
Best regards, Julian
[0] https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_2 [1] https://gitlab.gnome.org/GNOME/gparted/-/issues/245 [2] https://bugzilla.gnome.org/show_bug.cgi?id=649324#c7 [3] https://lists.gnu.org/archive/html/grub-devel/2022-02/msg00105.html
Julian Sikorski belegdol@gmail.com 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.
- 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).
- grub-less UKIs mean updating efivars with every kernel update. GRUB
developers expressed concerns this might wear down the NVRAM chips. Was this ever looked into in more detail?
With 'kernel-uki-virt' we're targeting virtualized and cloud environments where NVRAM is virtual so it's not an issue. It may (in theory) represent a problem for certain bare metal scenarios, in that case I would recommend using a bootloader between UEFI and UKI. As grub is not capable of booting UKIs (I remember seeing patches doing this but I'm not sure they were merged upstream/in Fedora) something like systemd-boot can be used. The merging 'nmbl' bootloader should also be capable of booting UKIs from day 1 (AFAIU).
(Personally, I'm not sure NVRAM wear is a real world problem. AFAIU, different NVRAMs support 10000 to 500000 write cycles. For example, koji tells we that there were 173 kernel built for Fedora-39. Even 10000 cycles will allow you to use 57 Fedora versions and this is likely beyond the life expectancy of any hardware.)
Am 05.08.24 um 11:07 schrieb Vitaly Kuznetsov:
Julian Sikorski belegdol@gmail.com 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. 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.
- grub-less UKIs mean updating efivars with every kernel update. GRUB
developers expressed concerns this might wear down the NVRAM chips. Was this ever looked into in more detail?
With 'kernel-uki-virt' we're targeting virtualized and cloud environments where NVRAM is virtual so it's not an issue. It may (in theory) represent a problem for certain bare metal scenarios, in that case I would recommend using a bootloader between UEFI and UKI. As grub is not capable of booting UKIs (I remember seeing patches doing this but I'm not sure they were merged upstream/in Fedora) something like systemd-boot can be used. The merging 'nmbl' bootloader should also be capable of booting UKIs from day 1 (AFAIU).
(Personally, I'm not sure NVRAM wear is a real world problem. AFAIU, different NVRAMs support 10000 to 500000 write cycles. For example, koji tells we that there were 173 kernel built for Fedora-39. Even 10000 cycles will allow you to use 57 Fedora versions and this is likely beyond the life expectancy of any hardware.)
I was thinking about bare metal. Fair enough. The only reason for my paranoia is that once NVRAM stops working, the machine is realistically a paperweight. In other words, once one realizes that the manufacturer has used subpar nvram, it is effectively too late. Having said that, having efivars updated twice per kernel update could be fewer writes than every time Windows is booted, depending on how often one actually boots Windows.
In any case, it is an exciting new development and I am interested to experience what it brings in the future.
Best regards, Julian
Julian Sikorski belegdol@gmail.com writes:
Am 05.08.24 um 11:07 schrieb Vitaly Kuznetsov:
Julian Sikorski belegdol@gmail.com 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.
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).
- grub-less UKIs mean updating efivars with every kernel update. GRUB
developers expressed concerns this might wear down the NVRAM chips. Was this ever looked into in more detail?
With 'kernel-uki-virt' we're targeting virtualized and cloud environments where NVRAM is virtual so it's not an issue. It may (in theory) represent a problem for certain bare metal scenarios, in that case I would recommend using a bootloader between UEFI and UKI. As grub is not capable of booting UKIs (I remember seeing patches doing this but I'm not sure they were merged upstream/in Fedora) something like systemd-boot can be used. The merging 'nmbl' bootloader should also be capable of booting UKIs from day 1 (AFAIU).
(Personally, I'm not sure NVRAM wear is a real world problem. AFAIU, different NVRAMs support 10000 to 500000 write cycles. For example, koji tells we that there were 173 kernel built for Fedora-39. Even 10000 cycles will allow you to use 57 Fedora versions and this is likely beyond the life expectancy of any hardware.)
I was thinking about bare metal. Fair enough. The only reason for my paranoia is that once NVRAM stops working, the machine is realistically a paperweight. In other words, once one realizes that the manufacturer has used subpar nvram, it is effectively too late. Having said that, having efivars updated twice per kernel update could be fewer writes than every time Windows is booted, depending on how often one actually boots Windows.
Yea, we don't want to be all over the internet with 'Linux breaks laptops!!!' of course :-)
In any case, it is an exciting new development and I am interested to experience what it brings in the future.
Good to know someone is trying UKIs outside of the limited "Confidential VM" use-case!
Am 06.08.24 um 09:37 schrieb Vitaly Kuznetsov:
Julian Sikorski belegdol@gmail.com writes:
Am 05.08.24 um 11:07 schrieb Vitaly Kuznetsov:
Julian Sikorski belegdol@gmail.com 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.... 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.
- grub-less UKIs mean updating efivars with every kernel update. GRUB
developers expressed concerns this might wear down the NVRAM chips. Was this ever looked into in more detail?
With 'kernel-uki-virt' we're targeting virtualized and cloud environments where NVRAM is virtual so it's not an issue. It may (in theory) represent a problem for certain bare metal scenarios, in that case I would recommend using a bootloader between UEFI and UKI. As grub is not capable of booting UKIs (I remember seeing patches doing this but I'm not sure they were merged upstream/in Fedora) something like systemd-boot can be used. The merging 'nmbl' bootloader should also be capable of booting UKIs from day 1 (AFAIU).
(Personally, I'm not sure NVRAM wear is a real world problem. AFAIU, different NVRAMs support 10000 to 500000 write cycles. For example, koji tells we that there were 173 kernel built for Fedora-39. Even 10000 cycles will allow you to use 57 Fedora versions and this is likely beyond the life expectancy of any hardware.)
I was thinking about bare metal. Fair enough. The only reason for my paranoia is that once NVRAM stops working, the machine is realistically a paperweight. In other words, once one realizes that the manufacturer has used subpar nvram, it is effectively too late. Having said that, having efivars updated twice per kernel update could be fewer writes than every time Windows is booted, depending on how often one actually boots Windows.
Yea, we don't want to be all over the internet with 'Linux breaks laptops!!!' of course :-)
In any case, it is an exciting new development and I am interested to experience what it brings in the future.
Good to know someone is trying UKIs outside of the limited "Confidential VM" use-case!
Am 06.08.24 um 10:15 schrieb Julian Sikorski:
Am 06.08.24 um 09:37 schrieb Vitaly Kuznetsov:
Julian Sikorski belegdol@gmail.com writes:
Am 05.08.24 um 11:07 schrieb Vitaly Kuznetsov:
Julian Sikorski belegdol@gmail.com 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.... 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.
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?
Best regards, Julian
- grub-less UKIs mean updating efivars with every kernel update. GRUB
developers expressed concerns this might wear down the NVRAM chips. Was this ever looked into in more detail?
With 'kernel-uki-virt' we're targeting virtualized and cloud environments where NVRAM is virtual so it's not an issue. It may (in theory) represent a problem for certain bare metal scenarios, in that case I would recommend using a bootloader between UEFI and UKI. As grub is not capable of booting UKIs (I remember seeing patches doing this but I'm not sure they were merged upstream/in Fedora) something like systemd-boot can be used. The merging 'nmbl' bootloader should also be capable of booting UKIs from day 1 (AFAIU).
(Personally, I'm not sure NVRAM wear is a real world problem. AFAIU, different NVRAMs support 10000 to 500000 write cycles. For example, koji tells we that there were 173 kernel built for Fedora-39. Even 10000 cycles will allow you to use 57 Fedora versions and this is likely beyond the life expectancy of any hardware.)
I was thinking about bare metal. Fair enough. The only reason for my paranoia is that once NVRAM stops working, the machine is realistically a paperweight. In other words, once one realizes that the manufacturer has used subpar nvram, it is effectively too late. Having said that, having efivars updated twice per kernel update could be fewer writes than every time Windows is booted, depending on how often one actually boots Windows.
Yea, we don't want to be all over the internet with 'Linux breaks laptops!!!' of course :-)
In any case, it is an exciting new development and I am interested to experience what it brings in the future.
Good to know someone is trying UKIs outside of the limited "Confidential VM" use-case!
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@gmail.com writes:
Am 05.08.24 um 11:07 schrieb Vitaly Kuznetsov:
Julian Sikorski belegdol@gmail.com 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.... 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.
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?
After one more reboot the 6.10 entry is gone entirely:
$ kernel-bootcfg --show # C - BootCurrent, N - BootNext, O - BootOrder # -------------------------------------------- # C O - 0002 - Fedora # O - 0000 - Windows Boot Manager # O - 0001 - Fedora Linux 40 (Workstation Edition) 6.9.12-200.fc40.x86_64 (UKI)
Best regards, Julian
Best regards, Julian
- grub-less UKIs mean updating efivars with every kernel update. GRUB
developers expressed concerns this might wear down the NVRAM chips. Was this ever looked into in more detail?
With 'kernel-uki-virt' we're targeting virtualized and cloud environments where NVRAM is virtual so it's not an issue. It may (in theory) represent a problem for certain bare metal scenarios, in that case I would recommend using a bootloader between UEFI and UKI. As grub is not capable of booting UKIs (I remember seeing patches doing this but I'm not sure they were merged upstream/in Fedora) something like systemd-boot can be used. The merging 'nmbl' bootloader should also be capable of booting UKIs from day 1 (AFAIU).
(Personally, I'm not sure NVRAM wear is a real world problem. AFAIU, different NVRAMs support 10000 to 500000 write cycles. For example, koji tells we that there were 173 kernel built for Fedora-39. Even 10000 cycles will allow you to use 57 Fedora versions and this is likely beyond the life expectancy of any hardware.)
I was thinking about bare metal. Fair enough. The only reason for my paranoia is that once NVRAM stops working, the machine is realistically a paperweight. In other words, once one realizes that the manufacturer has used subpar nvram, it is effectively too late. Having said that, having efivars updated twice per kernel update could be fewer writes than every time Windows is booted, depending on how often one actually boots Windows.
Yea, we don't want to be all over the internet with 'Linux breaks laptops!!!' of course :-)
In any case, it is an exciting new development and I am interested to experience what it brings in the future.
Good to know someone is trying UKIs outside of the limited "Confidential VM" use-case!
Julian Sikorski belegdol@gmail.com 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@gmail.com writes:
Am 05.08.24 um 11:07 schrieb Vitaly Kuznetsov:
Julian Sikorski belegdol@gmail.com 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.... 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
Am 08.08.24 um 13:18 schrieb Vitaly Kuznetsov:
Julian Sikorski belegdol@gmail.com 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@gmail.com writes:
Am 05.08.24 um 11:07 schrieb Vitaly Kuznetsov: > Julian Sikorski belegdol@gmail.com 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.... 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
-
Julian Sikorski -
Vitaly Kuznetsov