I've installed the 20240410 iso on a couple of machines and this bug is
as good as fixed.
The systemd task would be nice to complete but that's more for the sake
of bug 1914409. Right now I have more important bugs to focus on...
** Changed in: systemd (Ubuntu)
Status: In Progress =>
In case anyone is wondering, you won't start to see an improvement until
you have at least:
linux >= 6.8.0-20.20 and
plymouth >= 24.004.60-1ubuntu6
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
** Changed in: linux (Ubuntu)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
Annoying boot messages
This bug was fixed in the package plymouth - 24.004.60-1ubuntu6
---
plymouth (24.004.60-1ubuntu6) noble; urgency=medium
* Cherry-pick upstream fixes for consistent default scale selection
that matches what Mutter chooses on the login screen (LP: #2054769)
* plymouth.hook:
This bug was fixed in the package initramfs-tools - 0.142ubuntu23
---
initramfs-tools (0.142ubuntu23) noble; urgency=medium
[ Daniel van Vugt ]
* hooks/framebuffer: Only add simple/tiny framebuffer drivers. This is to
limit the size of initrd when FRAMEBUFFER=y is soon
That commit is not meant to reflect the outcome of discussions that
happened after it (comment #93). It's just an intermediate "UNRELEASED"
commit reflecting intermediate development.
My intent with shared repos like this is to show what is being worked on
before anything is released to the
https://salsa.debian.org/ubuntu-dev-
team/plymouth/-/commit/bd9d0119fdbeb3b30c8d3caafdb8a31b23c188c4 does not
reflect the removal of the complete drm section.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
Thanks. I've reflected those changes in git:
https://salsa.debian.org/ubuntu-dev-team/plymouth/-/commits/ubuntu/latest/
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
** Changed in: plymouth (Ubuntu)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
Annoying boot messages
Sponsored plymouth 24.004.60-1ubuntu6 after dropping the complete drm
modules code and correcting the changelog entries. Unsubscribing
~ubuntu-sponsors.
** Patch added: "plymouth_24.004.60-1ubuntu6_sponsored.debdiff"
** Merge proposal linked:
https://code.launchpad.net/~bdrung/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/462690
** Merge proposal linked:
https://code.launchpad.net/~bdrung/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/462691
--
You received this bug
Daniel, please review and comment
https://code.launchpad.net/~bdrung/ubuntu/+source/initramfs-
tools/+git/initramfs-tools/+merge/462691 (see the description for the
two possible implementations)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which
That change is in plymouth, but hooks/framebuffer is in initramfs-tools.
If you're suggesting moving the code from plymouth into initramfs-tools
then I kind of understand, but it's not directly related to fixing this
bug.
--
You received this bug notification because you are a member of Ubuntu
If you are suggesting moving the logic from plymouth into initramfs-
tools then please start by duplicating the code you'd like moved into
initramfs-tools. That would be efficient since you have commit access to
initramfs-tools, and would mean I only have to deal with plymouth here.
--
You
Looking at the remaining "add drm modules (only if MODULES=dep)"
section: This logic should moved to hooks/framebuffer as well.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
** Changed in: initramfs-tools (Ubuntu)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
Annoying boot messages
It seems unlikely my all-in-one kernel fix will be accepted upstream.
While I could propose it as an Ubuntu patch, another alternative is to
just let the linux task track bug 2049390 (Fix Committed). Then most
people will only need the above Plymouth patch to get a complete fix.
The remaining
Here's a fix for plymouth/noble.
The source is in:
https://salsa.debian.org/ubuntu-dev-team/plymouth/-/commits/ubuntu/latest
We skipped ubuntu5 because that technically existed in bug 2054769 for
10 days already.
Also note this will cause some temporary initrd bloat while the
initramfs-tools
https://code.launchpad.net/~vanvugt/ubuntu/+source/initramfs-
tools/+git/initramfs-tools/+merge/462482
** Merge proposal unlinked:
https://code.launchpad.net/~vanvugt/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/462481
--
You received this bug notification because you are a
** Merge proposal linked:
https://code.launchpad.net/~vanvugt/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/462481
** Merge proposal linked:
https://code.launchpad.net/~vanvugt/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/462482
--
You received this bug
** Description changed:
[ Impact ]
Kernel (and systemd) log messages appear during boot for many machines,
when the user should be seeing only the BIOS logo and/or Plymouth splash
screens.
[ Workaround ]
On most machines you can hide the problem by using these kernel
Seems it's fairly easy to make a working solution in initramfs-tools
alone, but there's a compromise. If I only include tiny/simple
framebuffer drivers in initrd then i915 starts so late that Plymouth
doesn't use it, and bug 2054769 can occur on some machines. If I include
all the current drm
Plymouth would still need patching in order to optimize the drm modules
in debian/local/plymouth.hook
** Changed in: plymouth (Ubuntu)
Status: Invalid => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to
I think the delay I'm seeing is a feature of Plymouth, not a bug:
"ignoring since we only handle SimpleDRM devices after timeout"
As much as I dislike it perpetuating bug 1869655, this feature does
prevent bug 2054769 from reoccurring.
But this raises the question: is it worth putting i915,
Fedora 39:
CONFIG_FB_VESA=y
CONFIG_FB_EFI=y
Ubuntu 24.04:
# CONFIG_FB_VESA is not set
# CONFIG_FB_EFI is not set
In the kernel source, DRM_SIMPLEDRM recommends SYSFB_SIMPLEFB if you
want it to work on UEFI and VESA. And we do enable SYSFB_SIMPLEFB whose
help text says:
> you should still keep
Can you double check the framebuffer FB related conf options in your
kconfig against those in Fedora?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
That might explain the strange behaviour I'm seeing where simpledrm
doesn't seem to be usable until a few seconds into the boot (maybe not
till i915drmfb is mentioned in the log?).
/boot/config-6.8.0-11-generic:# CONFIG_FB_EFI is not set
It was removed as part of bug 1965303. But I was hoping
The backend is a framebuffer driver. For example efifb which uses the
framebuffer set up by GOP in pre-boot.
If there are framebuffer drivers in tinydrm then maybe they matter for
those architectures.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded
Hopefully I'm wrong about the need for all the 'tiny' drivers and
simpledrm is in a class of its own. But I'd like to better understand
what the backend of simpledrm is and how much we can assume that it will
just work(tm).
--
You received this bug notification because you are a member of Ubuntu
Also hooks/plymouth is equally to blame and needs modifying, as
mentioned in comment #49 which I forgot.
Looking at my older 6.6 kernel however I'm reminded that some kernels
may have the drivers we need in the form of tiny drm (which is the
backend for simpledrm??):
> * hooks/framebuffer can be totally removed.
By chance I was testing on a desktop that has the Nvidia driver
installed (though no Nvidia card today, Intel only). Disabling
hooks/framebuffer had relatively little impact. In the end it was
hooks/framebuffer-nvidia that also needed disabling to
** Changed in: initramfs-tools (Ubuntu)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
Annoying boot messages interfering
** Changed in: initramfs-tools (Ubuntu)
Status: Opinion => New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
Annoying boot messages interfering
Even if FRAMEBUFFER=Y wasn't added, I think that a change to stop adding
all those other drm drivers makes a lot of sense. No use doubling the
initrd size for the LUKS case.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to
Maybe initramfs-tools does still need changing. plymouth-start.service
seems to run twice, and I get the feeling only the second instance is
actually succeeding in splashing on screen.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
You can test if the above suggestion will work for you by adding these
kernel parameters:
loglevel=3 fsck.mode=skip
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1970069
I've analysed a couple of Noble systems today and don't think initramfs-
tools needs improving (although it might not hurt). On both systems,
plymouth-start was within 1 second of simpledrm starting (same
timestamp), but the bug still occurs. The reasons are:
1. One system actually experiences
** Also affects: initramfs-tools (Ubuntu)
Importance: Undecided
Status: New
** Changed in: initramfs-tools (Ubuntu)
Assignee: (unassigned) => Daniel van Vugt (vanvugt)
** Changed in: initramfs-tools (Ubuntu)
Importance: Undecided => Medium
** Changed in: initramfs-tools
AFAICT; these initramfs-tools package changes would cover it:
* hooks/framebuffer can be totally removed.
* scripts/init-top/framebuffer should probably stay
* conf/initramfs.conf needs FRAMEBUFFER=y added to it
--
You received this bug notification because you are a member of Ubuntu
Touch
Plymouth only gets added to the initrd when LUKS is enabled or you mark
another reason for needing the framebuffer.
So the suggestion I have from comment #49 is to mark needing the
framebuffer by default, and then stop including any DRM modules because
simpledrm is built into the kernel.
--
You
It's a bit unclear to me what change we need now to take advantage of
simpledrm? Comment #49 state getting plymouth in the initrd but that should
already be the case today or luks encryption wouldn't be working no?
what change would trigger the include of extra drm modules?
--
You received
Noble is now shipping with SimpleDRM enabled in kernel 6.8, so the next
step is comment #49 (which would also resolve bug 1869655).
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
Also focal (20.04.6) does have the bug now, per comment #23.
** Tags added: focal
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
Annoying boot messages
It looks like the above code might not need /dev/console at all. It
should be possible to modify it to use a private pipe for fsck's stdout.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
I'm starting to suspect our patch (comment #39) isn't directly to blame
for the systemd issue. Disabling or otherwise breaking systemd-
fsckd.service doesn't stop fsck output from polluting the console and
triggering this bug. Only skipping fsck avoids it. You can skip fsck
using 'fastboot' or
** Changed in: systemd (Ubuntu)
Status: Won't Fix => In Progress
** Changed in: systemd (Ubuntu)
Assignee: (unassigned) => Daniel van Vugt (vanvugt)
** Changed in: systemd (Ubuntu)
Importance: Low => Medium
--
You received this bug notification because you are a member of Ubuntu
** Tags removed: kinetic lunar
** Tags added: udeng-2004
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
Annoying boot messages interfering with splash
** Description changed:
[ Impact ]
Kernel (and systemd) log messages appear during boot for many machines,
when the user should be seeing only the BIOS logo and/or Plymouth splash
screens.
+ [ Workaround ]
+
+ On most machines you can hide the problem by using these kernel
** Description changed:
+ [ Impact ]
+
+ Kernel (and systemd) log messages appear during boot for many machines,
+ when the user should be seeing only the BIOS logo and/or Plymouth splash
+ screens.
+
+ [ Test Plan ]
+
+ 1. Boot Ubuntu on a number of laptops that have the problem and verify
+
Status update:
https://lists.freedesktop.org/archives/dri-devel/2024-February/442066.html
So once merged, the fix will need to be manually enabled by:
FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION = "splash"
--
You received this bug notification because you are a member of Ubuntu
Touch seeded
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: systemd (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
** Changed in: linux (Ubuntu)
Importance: Undecided => Medium
** Changed in: plymouth (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
Patches sent (to multiple places per get_maintainer.pl):
https://lkml.org/lkml/2024/2/2/373
https://lkml.org/lkml/2024/2/2/375
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
The blanking from GRUB_TIMEOUT>0 will be made much worse by
CONFIG_FB_EFI=n because usually in Ubuntu it's the efifb that restores
the logo after Grub has wiped it. I think not having CONFIG_FB_EFI at
the same time as using GRUB_TIMEOUT>0 explains your previous "really
long time of a black
With your change Fedora and Ubuntu are now behaving relatively similarly.
* Both have a deficiency where the handoff from BGRT logo to Plymouth is doing
a modeset for some reason.
* Due to something in Fedora's GRUB it's a little clearer when GRUB starts.
Here's various artifacts if you want
Ah I did have GRUB_TIMEOUT set; I hadn't expected that caused a black
screen.
Moving that to zero certainly helps. It's a lot better; but still not perfect.
Let me get things back to as close as possible to stock and capture logs and a
videos to compare with Ubuntu and Fedora with this exact
GRUB_TIMEOUT > 0 also causes the vendor logo to be replaced by a black
screen, but that seems to be Grub's fault. Default Ubuntu won't have
that problem since it ships GRUB_TIMEOUT=0. And if you want a nonzero
timeout without the blackness then GRUB_TERMINAL=console is a
workaround.
--
You
I think that's a different bug. I believe it's when plymouthd is
starting and is the handover (mode set?) from efifb to DRM. It doesn't
happen at all if you add "nomodeset" (please try that).
"Really long time" might be subjective though? How long?
VT switches (or more accurately virtual console
I tested it on Noble with a hand built kernel and it at least does what
you planned (don't see any console messages), but also I'm not seeing
the OEM vendor logo stick all the way through. There's a really long
time of a black screen. Not sure if this is because it was an upstream
kernel and
Here's a no-compromises patch set. No bugs, no delays, it just does the
right thing.
If I haven't changed my mind again on Friday then it will be sent
upstream.
** Patch added: "lp1970069-patchset-20240201a.patch"
> You could detect both parameters to avoid that corner case.
Sure one can check for "splash nomodeset" to avoid the confusion in most
cases, but that wouldn't fix it for "splash $DRIVER.modeset=0" or less
common architectures which might have no primary framebuffer. I guess we
can tell people
BTW bug 2050743 is making the situation worse on noble. It will be fixed
shortly.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
Annoying boot messages
You could detect both parameters to avoid that corner case.
Alternatively this is something I feel simpledrm will help you avoid
hitting too.
Otherwise it sounds good to me.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to
A new attempt at a kernel patch. While this is pleasingly simple and
reliable in my own testing, it has a bug when "splash" is used at the
same time as there being no primary framebuffer (like with "nomodeset").
I'm not sure if that's a realistic concern and am reluctant to go back
to delays to
Hmm, no plymouthd isn't starting quite early enough in Noble:
2.799s - plymouthd starts
4.080s - first show-splash attempt (rejected because DRM hasn't started yet)
5.290s - found /dev/dri/card0
5.364s - showing splash screen
What this means is that any attempt to fix the bug in plymouthd itself
I'm not sure we even need Plymouth installed in initrd because the
device_timeout experiment mentioned in comment #18 suggests plymouthd
was starting early enough already. It's not the root filesystem that
takes too long to appear, but the i915/amdgpu drivers to fully
initialize. Also all this
> I belive /usr/share/initrams-tools/hooks/plymouth can be modified to stop
> including any
> drm modules and /usr/share/initramfs-tools/framebuffer can be totally dropped.
Dropping the DRM modules would also allow us to use a near-zero
device_timeout in Plymouth now. It would then render to
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
Annoying boot messages interfering with splash screen
Status in linux package in Ubuntu:
In Progress
Thanks. So it still sounds like SimpleDRM is in Ubuntu's future (bug
1965303). But in case that doesn't happen in time for Noble, or if we
simply want a solution that backports to jammy, then I will still focus
on plymouth/kernel changes only.
--
You received this bug notification because you
Yeah; so try forcing plymouth to the Ubuntu initrd like this:
echo "FRAMEBUFFER=y" | sudo tee /etc/initramfs-tools/conf.d/splash
Then if you rebuild the initrd you'll end up with plymouth in it.
This unfortunately DOUBLES the initramfs size; but it's because it puts all the
drm modules in
Something "big" I notice different is that by default Ubuntu doesn't put
plymouth in the initramfs but Fedora does.
Maybe plymouthd really isn't running at the time systemd-fsckd is
running.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
> I don't really know if Fedora does that better or they just failed to
notice the bug.
I have Fedora 39 and Ubuntu both set up on a Z13 and Plymouth comes up in
Fedora with simpledrm; never see the console. That's why I was thinking
something might be missing and worth looking at.
* Fedora
"splash" is more appropriate than "quiet" (unfortunately) because we
would delay framebuffer takeover to the same event (primary DRM startup)
as Plymouth does.
I would also like to know why our Plymouth doesn't render on SimpleDRM
even when it's available (tested in bug 1965303). I don't really
Have you already looked at everything Fedora is doing in this area?
They already have simpledrm; but from what you described I would have
thought they should still lose the fbcon race.
Is it just that they don't have systemd-fsckd patch? I would think they
still end up showing ERR/WARN kernel
> But the feature would still be gated on the "splash" kernel parameter
which is Plymouth-specific and may cause pushback from kernel
developers.
If the patch is the way you go another idea for you is to use the
"quiet" keyword to key off instead for this behavior which is already
used by the
I now expect the kernel patch would change before it gets proposed to
dri-devel. In particular the primary delay doesn't need to be
configurable (or even finite?), and the secondary delay probably doesn't
need to be more than zero. But the feature would still be gated on the
"splash" kernel
** Changed in: plymouth (Ubuntu)
Status: Invalid => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
Annoying boot messages interfering with
I am also the author of the Plymouth feature that parses and renders the
fsck progress. What I think isn't being communicated here is that it's
currently useless on startup. Because Plymouth doesn't start rendering
until well after the fsck has already happened. See also bug 1869655.
--
You
AFAIK, the systemd-fsckd patch is still required, but we have vague
plans to get rid of it by making plymouth learn this functionality (i.e.
reading /run/systemd/fsck.progress directly). I have no idea about the
re-ordering, but it would be easy to test with a drop-in config.
** Changed in:
You can use the 'fastboot' kernel parameter to bypass the systemd-fsckd
issue. So overall most systems can work around the bug in full using
kernel parameters:
quiet splash loglevel=2 fastboot
After that I've only encountered one weird laptop that refused to stay
silent (even with loglevel=0).
The userspace part of this bug is coming from our systemd patch:
debian/fsckd-daemon-for-inter-fsckd-communication.patch
In particular where systemd-fsckd.service says:
StandardOutput=journal+console
Is the patch still required at all, or can it be reordered to wait for
Plymouth to splash
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
Annoying boot messages
82 matches
Mail list logo
