autotldr@lemmings.world
on 06 Dec 2023 17:00
nextcollapse
This is the best summary I could come up with:
Fedora 40 is eyeing the next phase of its unified kernel (UKI) support within the distribution that will include the ability to support booting to unified kernel image files directly without having to go through a traditional bootloader like GRUB or SD-Boot.
The second phase of Fedora’s unified kernel support is looking at a boot path from the EFI SHIM to UKI directly without any bootloader present.
The UEFI boot configuration will get an entry for each kernel installed, newly-installed kernels are configured to be booted once but will then be made permanent after a successful boot, and also enabling UKI support for 64-bit Arm (AArch64).
This latest UKI work for Fedora will lead to better UEFI Secure Boot support, better supporting TPM measurements and confidential computing, and a more robust boot process.
Those interested in the latest UKI efforts for Fedora 40 can see this Fedora mailing list thread with more details.
The original article contains 153 words, the summary contains 153 words. Saved 0%. I’m a bot and I’m open source!
sabreW4K3@lemmy.tf
on 06 Dec 2023 17:20
nextcollapse
Is this good?
Flaky@iusearchlinux.fyi
on 06 Dec 2023 17:40
nextcollapse
It basically means instead of relying on a bootloader (e.g. GRUB or systemd-boot) the computer boots the kernel directly. Generally there should be no change besides having to use the BIOS menu to manually select a kernel.
sabreW4K3@lemmy.tf
on 06 Dec 2023 23:10
nextcollapse
Thank you, you’re awesome!
Flaky@iusearchlinux.fyi
on 07 Dec 2023 00:50
collapse
No problem! :)
FWIW, a lot of the DIY distros (Arch and Gentoo being the ones on most minds) allow this already so it’s nothing new. It’s just Fedora implementing it that’s new I guess. If you’re curious, the term to search is “EFISTUB”.
Blisterexe@lemmy.zip
on 07 Dec 2023 14:39
collapse
Is the benifit making secure boot work better?
duncesplayed@lemmy.one
on 08 Dec 2023 06:53
nextcollapse
I think for most people they won’t care either way.
Some people do legitimately occasionally need to poke around in GRUB before loading the kernel.
Setting up certain kernel parameters or looking for something on the filesystem or something like that.
For those people, booting directly into the kernel means your ability to “poke around” is now limited by how nice your motherboard’s firmware is.
But even for those people, they should always at least have the option of setting up a 2-stage boot.
vanderbilt@beehaw.org
on 08 Dec 2023 15:12
collapse
Yes, in my opinion. The configuration of grub (boot loader) is just another step to go wrong, and this will eliminate that possibility. Additionally, it will prevent stupider operating systems (cough Windows) from accidentally overwriting the boot loader during an update.
Dr_Willis@sh.itjust.works
on 06 Dec 2023 18:50
nextcollapse
I am reminded of the ability MANY years ago to write the kernel file directly to a floppy disk, or start of a hard drive and somehow being able to boot that way.
I just can’t recall how I did it, or WHY I did it.
Back when the kernel would fit on a floppy disk. I am truly showing my age.
6 yr old grandson found a box of old floppy disks and was asking what they were. He started stacking them up making card houses and roads for his matchbox cars. Glad he got some use out of those recycled AOL floppies.
dingdongitsabear@lemmy.ml
on 06 Dec 2023 20:06
nextcollapse
This latest UKI work for Fedora will lead to better UEFI Secure Boot support, better supporting TPM measurements and confidential computing, and a more robust boot process.
and HOPEFULLY lead to a less jerky-flashy-switchy boot xperience, looks like a Vegas light show at present. switched to systemd-boot, but it’s only a tiny bit better, still switches modes/blanks screen like five times.
taanegl@beehaw.org
on 08 Dec 2023 06:02
nextcollapse
Omg yes, I hate those. I’m sitting here thinking it’s probably one of those simple things that scares people away from Linux…“Oh god, I see black text on white background. Abort, abort, ABORT!!”
Mine only switches modes once, on load save backlight.
dingdongitsabear@lemmy.ml
on 08 Dec 2023 10:30
collapse
yeah, if you don’t have an encrypted drive (which I’m gonna do on a laptop NEVER) on some OEMs this can look semi-seamless.
here’s what it looks like on a laptop:
OEM logo
screen goes blank, backlight off
light on, OEM logo
blank screen
decrypt password
blank screen
loading spinner with OEM logo
gdm/sddm login screen
blank screen
9a. (sddm) loading animation
9b. (sddm) jerk when fractional scaling kicks in
and finally there’s the desktop
with additional mode switching interjected and occasionally the horror that is GRUB inserts a ‘Loading blah blah’ text message; thankfully we’re getting rid of that.
My HP crapbook doesn’t have this OEM logo bullshit. Only the windows bootloader shows it, and the logo file is stored in the BGRT. So I don’t think I’m affected unless the WBM or systemd-boot have this vuln.
Mine:
1. Screen turns on
2. I pick EndeavorOS in systemd-boot
3. It starts spitting out logs (I love this behavior)
4. It switches modes once the backlight is loaded
5. I log in
6. KDE loads
I will never understand people who install Plymouth, it just adds complexity in the boot process. If your distro installs this then I understand why: so it doesn’t look like you’re “hacking the government”. If your distro doesn’t install it and you install it then you probably picked the wrong distro.
Is there not issues with filling up the NVRAM with efi entries, even if you’re deleting old ones? I’ve bricked a computer by distrohopping so many times it couldn’t write new entries.
SteveTech@programming.dev
on 06 Dec 2023 22:48
collapse
I’m probably wrong, but NVRAM suggests that there should be some way to clear it. (Clearing the CMOS might if you can’t do it in software)
as_is_tradition@lemmy.ca
on 06 Dec 2023 22:53
collapse
threaded - newest
This is the best summary I could come up with:
Fedora 40 is eyeing the next phase of its unified kernel (UKI) support within the distribution that will include the ability to support booting to unified kernel image files directly without having to go through a traditional bootloader like GRUB or SD-Boot.
The second phase of Fedora’s unified kernel support is looking at a boot path from the EFI SHIM to UKI directly without any bootloader present.
The UEFI boot configuration will get an entry for each kernel installed, newly-installed kernels are configured to be booted once but will then be made permanent after a successful boot, and also enabling UKI support for 64-bit Arm (AArch64).
This latest UKI work for Fedora will lead to better UEFI Secure Boot support, better supporting TPM measurements and confidential computing, and a more robust boot process.
Those interested in the latest UKI efforts for Fedora 40 can see this Fedora mailing list thread with more details.
The original article contains 153 words, the summary contains 153 words. Saved 0%. I’m a bot and I’m open source!
Is this good?
It basically means instead of relying on a bootloader (e.g. GRUB or systemd-boot) the computer boots the kernel directly. Generally there should be no change besides having to use the BIOS menu to manually select a kernel.
Thank you, you’re awesome!
No problem! :)
FWIW, a lot of the DIY distros (Arch and Gentoo being the ones on most minds) allow this already so it’s nothing new. It’s just Fedora implementing it that’s new I guess. If you’re curious, the term to search is “EFISTUB”.
Is the benifit making secure boot work better?
I think for most people they won’t care either way.
Some people do legitimately occasionally need to poke around in GRUB before loading the kernel. Setting up certain kernel parameters or looking for something on the filesystem or something like that. For those people, booting directly into the kernel means your ability to “poke around” is now limited by how nice your motherboard’s firmware is. But even for those people, they should always at least have the option of setting up a 2-stage boot.
Yes, in my opinion. The configuration of grub (boot loader) is just another step to go wrong, and this will eliminate that possibility. Additionally, it will prevent stupider operating systems (cough Windows) from accidentally overwriting the boot loader during an update.
Does that mean that the OS would have to handle version booting?
My understanding is that’s a yes.
Thank you
I am reminded of the ability MANY years ago to write the kernel file directly to a floppy disk, or start of a hard drive and somehow being able to boot that way.
I just can’t recall how I did it, or WHY I did it.
Back when the kernel would fit on a floppy disk. I am truly showing my age.
6 yr old grandson found a box of old floppy disks and was asking what they were. He started stacking them up making card houses and roads for his matchbox cars. Glad he got some use out of those recycled AOL floppies.
and HOPEFULLY lead to a less jerky-flashy-switchy boot xperience, looks like a Vegas light show at present. switched to systemd-boot, but it’s only a tiny bit better, still switches modes/blanks screen like five times.
Omg yes, I hate those. I’m sitting here thinking it’s probably one of those simple things that scares people away from Linux…“Oh god, I see black text on white background. Abort, abort, ABORT!!”
Mine only switches modes once, on load save backlight.
yeah, if you don’t have an encrypted drive (which I’m gonna do on a laptop NEVER) on some OEMs this can look semi-seamless.
here’s what it looks like on a laptop:
with additional mode switching interjected and occasionally the horror that is GRUB inserts a ‘Loading blah blah’ text message; thankfully we’re getting rid of that.
My HP crapbook doesn’t have this OEM logo bullshit. Only the windows bootloader shows it, and the logo file is stored in the BGRT. So I don’t think I’m affected unless the WBM or systemd-boot have this vuln.
Mine:
I will never understand people who install Plymouth, it just adds complexity in the boot process. If your distro installs this then I understand why: so it doesn’t look like you’re “hacking the government”. If your distro doesn’t install it and you install it then you probably picked the wrong distro.
Is there not issues with filling up the NVRAM with efi entries, even if you’re deleting old ones? I’ve bricked a computer by distrohopping so many times it couldn’t write new entries.
I’m probably wrong, but NVRAM suggests that there should be some way to clear it. (Clearing the CMOS might if you can’t do it in software)
I’ve cleared entries before with efibootmgr.