search

andreyv / sbupdate

Generate and sign kernel images for UEFI Secure Boot on Arch Linux
GNU General Public License v3.0
225 stars 20 forks source link

Feature suggestion: Support for seamless boot via ACPI BGRT #9

Closed Taijian closed 4 years ago

Taijian commented 5 years ago

Hi,

please allow me to first say how much I love and appreciate what you've done with sbupdate, this tool has really made it so much easier to manage my secure boot process and it's updates!

Now that both i915 in the kernel and plymouth have gotten support for flicker-free booting via ACPI BGRT, the last step for that to really work well in my setup is sbupdate support. Now, I really have no idea how this works, but would it be possible to have sbupdate also support this feature in the same way that plymouth does? That would make my boot process really seamless. And note that this is different from just using a blank splash, because that would be a disruption from UEFI splash to blank screen back to UEFI splash via plymouth.

Thank you!

andreyv commented 5 years ago

Hi,

I don't have experience with Plymouth as I haven't used it. Could you please describe what do you expect to happen, what configuration do you have and what things should sbupdate do?

Taijian commented 5 years ago

Well, there are a couple of patches in the branch that gets merged into Plymouth here - specifically this commit - that enable a plymouth config that re-uses the firmware splash as the plymouth splash. This has the effect that if an efi stub gets booted with this plymouth option compiled in, the user does not see any noticeable transition between firmware boot splash and plymouth boot splash, apart from the addition of a little spinner, indicating boot progress. Phoronix talks about this here.

Now, what happens on my system currently is that:

  1. The firmware boot splash shows up
  2. systemd-boot menu to select boot option (I could at some point skip that, but currently necessary)
  3. sbupdate boot splash
  4. plymouth boot splash
  5. display manager - boot complete

Currently, I can utilize this plymouth mode to make 1 & 4 look alike, but 3 always sticks out, because it is diffenrent from the others. Ideally, there would be an option in sbupdate to make 1,3,and 4 all look exactly alike, e.g. by reusing the plymouth code to create the same splash that they are using from /sys/firmware/acpi/bgrt/image, a black background and some math.

I hope this helps?

andreyv commented 5 years ago

sbupdate uses the systemd EFI stub to do the actual booting. Currently the EFI stub has an option to use an embedded static splash image, or none, in which case the screen should be unchanged.

You can disable splash in sbupdate configuration, then try direct booting without a boot manager and see if the firmware splash is preserved.

Otherwise you should open an issue at systemd/systemd about EFI stub support for ACPI BGRT. Note that during the stub execution the kernel is not loaded yet, so there's no /sys/firmware/acpi/bgrt/image. The EFI stub needs to parse the ACPI table data manually.

The stub code is here: stub.c splash.c

Taijian commented 5 years ago

Hm, OK, so what I ended up doing is just read from /sys/firmware/acpi/bgrtmanually post-boot and create a splash screen for sbupdate to embed with ${imagemanipilationprogram}. When I get around to it I'll try and see if I can hack something together in bash to submit a pull request - might be a while, though...

Anyway, thank you for your input and engagement!

andreyv commented 5 years ago

I think it should be enough to add a readme section about the subject. It needs to be done one time and the choice of the image editing software should not matter.

Did you also try setting SPLASH to /dev/null? From the stub code linked above, it should then avoid changing the screen state.

pinembour commented 5 years ago

Hi, I have approximately the same setup as OP, and your last advice ( setting SPLASH to /dev/null ) works perfectly. Thanks for your amazing work :)