Activity log for bug #1869655

Date Who What changed Old value New value Message
2020-03-30 06:59:49 Daniel van Vugt bug added bug
2020-03-30 06:59:58 Daniel van Vugt grub2 (Ubuntu): importance Undecided Wishlist
2020-03-30 07:01:39 Daniel van Vugt description Add an Ubuntu splash logo to supplement the BGRT logo. Since we now keep the BIOS logo (ACPI BGRT image) on screen and don't replace it with a blank purple screen, it lasts much longer in 20.04 than it did in 19.04. This removes some sense of boot progress in that long period while we wait for the kernel to start plymouth. I suggest we need grub to display *something* once again. Because it's the longest part of the boot process on many machines and it feels a bit broken in 20.04. But since we're using the Plymouth 'bgrt' theme, grub would need to understand and integrate with the BIOS logo. Add an Ubuntu splash logo to supplement the BGRT logo. Since we now keep the BIOS logo (ACPI BGRT image) on screen and don't replace it with a blank purple screen, it lasts much longer in 20.04 than it did in 19.10. This removes some sense of boot progress in that long period while we wait for the kernel to start plymouth. I suggest we need grub to display *something* once again. Because it's the longest part of the boot process on many machines and it feels a bit broken in 20.04. But since we're using the Plymouth 'bgrt' theme, grub would need to understand and integrate with the BIOS logo.
2020-03-30 07:02:11 Daniel van Vugt description Add an Ubuntu splash logo to supplement the BGRT logo. Since we now keep the BIOS logo (ACPI BGRT image) on screen and don't replace it with a blank purple screen, it lasts much longer in 20.04 than it did in 19.10. This removes some sense of boot progress in that long period while we wait for the kernel to start plymouth. I suggest we need grub to display *something* once again. Because it's the longest part of the boot process on many machines and it feels a bit broken in 20.04. But since we're using the Plymouth 'bgrt' theme, grub would need to understand and integrate with the BIOS logo. Add an Ubuntu splash logo to supplement the BGRT logo. Since we now keep the BIOS logo (ACPI BGRT image) on screen and don't replace it with a blank purple screen, it lasts much longer in 20.04 than it did in 19.10. This removes some sense of boot progress in that long period while we wait for the kernel to start plymouth. I suggest we need grub to display *something* once again. Because it's the longest part of the boot process on many machines and it feels a bit broken in 20.04 seeing nothing but the BIOS logo for most of it. But since we're using the Plymouth 'bgrt' theme, grub would need to understand and integrate with the BIOS logo.
2020-03-30 08:51:05 Daniel van Vugt bug added subscriber Dimitri John Ledkov
2020-03-30 08:51:11 Daniel van Vugt bug added subscriber Sebastien Bacher
2020-04-02 15:15:59 Dimitri John Ledkov tags champagne flickerfreeboot focal flickerfreeboot focal rls-ff-notfixing
2020-04-20 07:53:45 Launchpad Janitor grub2 (Ubuntu): status New Confirmed
2020-04-30 19:28:54 Marcos Alano bug added subscriber Marcos Alano
2020-05-14 07:07:24 Daniel van Vugt bug watch added https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/110
2020-05-14 07:07:24 Daniel van Vugt bug task added plymouth
2020-05-14 07:08:26 Daniel van Vugt tags flickerfreeboot focal rls-ff-notfixing flickerfreeboot focal groovy rls-ff-notfixing
2020-05-14 07:08:32 Daniel van Vugt grub2 (Ubuntu): status Confirmed Triaged
2020-05-14 07:16:31 Daniel van Vugt summary Add an Ubuntu splash logo to supplement the BGRT logo Add an Ubuntu splash logo to Grub to supplement the BGRT logo
2020-05-14 07:44:19 Daniel van Vugt summary Add an Ubuntu splash logo to Grub to supplement the BGRT logo The plymouth splash starts too late to be useful on modern fast systems
2020-05-14 07:49:06 Daniel van Vugt description Add an Ubuntu splash logo to supplement the BGRT logo. Since we now keep the BIOS logo (ACPI BGRT image) on screen and don't replace it with a blank purple screen, it lasts much longer in 20.04 than it did in 19.10. This removes some sense of boot progress in that long period while we wait for the kernel to start plymouth. I suggest we need grub to display *something* once again. Because it's the longest part of the boot process on many machines and it feels a bit broken in 20.04 seeing nothing but the BIOS logo for most of it. But since we're using the Plymouth 'bgrt' theme, grub would need to understand and integrate with the BIOS logo. The Plymouth splash starts too late to be useful on modern fast systems. Such systems spend all their boot time (a couple of seconds) decompressing the kernel. During that time the user only sees the static BIOS logo (ACPI BGRT). Then when Plymouth can finally start animating, the startup process is already finished and there's virtually no time left to show any useful animations. This could be fixed in: grub: By adding a splash under the BIOS logo to show some progress _before_ a Linux kernel is even started and/or plymouth: By preferencing legacy framebuffer devices over DRM, if we find those are available a few seconds sooner. That would also fix bug 1868240.
2020-05-14 07:49:12 Daniel van Vugt summary The plymouth splash starts too late to be useful on modern fast systems The Plymouth splash starts too late to be useful on modern fast systems
2020-05-14 07:49:17 Daniel van Vugt grub2 (Ubuntu): importance Wishlist Low
2020-05-14 07:49:27 Daniel van Vugt bug task added plymouth (Ubuntu)
2020-05-14 07:49:32 Daniel van Vugt plymouth (Ubuntu): importance Undecided Low
2020-05-14 07:49:35 Daniel van Vugt plymouth (Ubuntu): status New Triaged
2020-05-14 07:50:35 Daniel van Vugt description The Plymouth splash starts too late to be useful on modern fast systems. Such systems spend all their boot time (a couple of seconds) decompressing the kernel. During that time the user only sees the static BIOS logo (ACPI BGRT). Then when Plymouth can finally start animating, the startup process is already finished and there's virtually no time left to show any useful animations. This could be fixed in: grub: By adding a splash under the BIOS logo to show some progress _before_ a Linux kernel is even started and/or plymouth: By preferencing legacy framebuffer devices over DRM, if we find those are available a few seconds sooner. That would also fix bug 1868240. The Plymouth splash starts too late to be useful on modern fast systems. Such systems spend all their boot time (a couple of seconds) decompressing the kernel. During that time the user only sees the static BIOS logo (ACPI BGRT). Then when Plymouth can finally start animating, the startup process is already finished and there's virtually no time left to show any useful animations. This could be fixed in:   grub: By adding a splash under the BIOS logo to show some progress _before_ a Linux kernel is even started and/or   plymouth: By preferencing legacy framebuffer devices (like EFI) over DRM, if we find those are available a few seconds sooner. That would also fix bug 1868240.
2020-05-14 07:51:29 Daniel van Vugt description The Plymouth splash starts too late to be useful on modern fast systems. Such systems spend all their boot time (a couple of seconds) decompressing the kernel. During that time the user only sees the static BIOS logo (ACPI BGRT). Then when Plymouth can finally start animating, the startup process is already finished and there's virtually no time left to show any useful animations. This could be fixed in:   grub: By adding a splash under the BIOS logo to show some progress _before_ a Linux kernel is even started and/or   plymouth: By preferencing legacy framebuffer devices (like EFI) over DRM, if we find those are available a few seconds sooner. That would also fix bug 1868240. The Plymouth splash starts too late to be useful on modern fast systems. Such systems spend all their boot time (a couple of seconds) decompressing the kernel. During that time the user only sees the static BIOS logo (ACPI BGRT). Then when Plymouth can finally start animating, the startup process is already finished and there's virtually no time left to show any useful animations. This could be fixed in:   grub: By adding a splash under the BIOS logo to show some progress _before_ a Linux kernel is even started and/or   plymouth: By preferencing legacy framebuffer devices (like EFI) over DRM, if we find those are available a few seconds sooner. That would also fix bug 1868240 completely, and bug 1836858 mostly as the flicker moves to when the login screen starts.
2020-05-14 07:57:13 Daniel van Vugt summary The Plymouth splash starts too late to be useful on modern fast systems Boot animations start too late to be useful
2020-05-14 07:57:33 Daniel van Vugt description The Plymouth splash starts too late to be useful on modern fast systems. Such systems spend all their boot time (a couple of seconds) decompressing the kernel. During that time the user only sees the static BIOS logo (ACPI BGRT). Then when Plymouth can finally start animating, the startup process is already finished and there's virtually no time left to show any useful animations. This could be fixed in:   grub: By adding a splash under the BIOS logo to show some progress _before_ a Linux kernel is even started and/or   plymouth: By preferencing legacy framebuffer devices (like EFI) over DRM, if we find those are available a few seconds sooner. That would also fix bug 1868240 completely, and bug 1836858 mostly as the flicker moves to when the login screen starts. Boot animations start too late to be useful Modern systems spend all their boot time (a couple of seconds) decompressing the kernel. During that time the user only sees the static BIOS logo (ACPI BGRT). Then when Plymouth can finally start animating, the startup process is already finished and there's virtually no time left to show any useful animations. This could be fixed in:   grub: By adding a splash under the BIOS logo to show some progress _before_ a Linux kernel is even started and/or   plymouth: By preferencing legacy framebuffer devices (like EFI) over DRM, if we find those are available a few seconds sooner. That would also fix bug 1868240 completely, and bug 1836858 mostly as the flicker moves to when the login screen starts.