:D I also use an HP Aero 13 and see this bug every time it boots. It's
even more distracting on such a machine that skips displaying the BIOS
logo.
** Tags added: mantic noble
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Ubuntu.
I think the next step is to either try disabling
PLY_ENABLE_SYSTEMD_INTEGRATION, or to work around Red Hat's preference
for Plymouth to wait for DRM and allow it to render with fbdev
immediately on boot (that would fix other bugs too).
--
You received this bug notification because you are a membe
** Changed in: mesa (Ubuntu)
Status: Fix Committed => Fix Released
** Tags removed: fixed-in-mesa-23.3
** Tags added: fixed-in-mesa-23.3.0
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bug
From what I read of overnight discussions, it is believed that Mesa
23.3.3 has a fix. Looks like some kind of GLX protocol breakage happened
in 23.3.0?
** Also affects: mesa (Ubuntu)
Importance: Undecided
Status: New
** Changed in: mesa (Ubuntu)
Status: New => Fix Committed
--
** Summary changed:
- ssh-agent fails to start (has_option: command not found)
+ Xorg scripts fail with "has_option: command not found"
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1922414
See also bug 2049016.
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1922414
Title:
Xorg scripts fail with "has_option: command not found"
Status in Light Display Manager:
Invalid
Status
** Changed in: plymouth (Ubuntu)
Assignee: (unassigned) => Daniel van Vugt (vanvugt)
** Changed in: plymouth (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Ub
I'm finally looking at this again. Theories tested today:
* Disabling PLY_ENABLE_SYSTEMD_INTEGRATION didn't fix anything. Seems
we're dealing with kernel messages and not just systemd logging.
* Reducing device_timeout to 0.1 (seconds) in ubuntu-default-
devicetimeout.patch helps a lot and hides
This appears to be a networking or server problem, so likely isn't a bug
we need to track here.
** Package changed: xorg (Ubuntu) => ubuntu
** Changed in: ubuntu
Status: New => Invalid
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subs
** Changed in: mesa (Ubuntu)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2043915
Title:
Booting into live session results in try/install page
Confirmed fix released in https://cdimage.ubuntu.com/daily-
live/20240116/
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2043915
Title:
Booting into live session results in try/install pag
Thanks, yes any failure to install now needs a separate bug report.
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2043915
Title:
Booting into live session results in try/install page white
> #18
> Instead of changing this patch can you finish the adoption for simpledrm?
> This will get a DRM framebuffer up and running instantly. It should help a
> lot.
Yes! I've been thinking the same. We already have bug 1965303 to track
that. But I find it curious that device_timeout=0.1 didn't f
I can't seem to reproduce any such issue with 2024-01-17 here.
Please log a new bug, although it might be bug 2049617 as mentioned in
https://discourse.ubuntu.com/t/help-with-edubuntu-desktop-
installer/41683
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA
I don't think the bug description is quite right here. I went back to
20.04 and no bug, but then tried 20.04.6 and the bug had already
started. Reverting plymouth to the original version made no improvement.
So the main difference I see between Ubuntu 20.04 (no bug) and Ubuntu
20.04.6 (bug) seems t
It seems the BGRT logo gets displayed 3 times on boot, not 2. Why is
that? You can see this more clearly when using the grub menu or a grub
delay:
1. BIOS displays the BGRT logo.
2. Screen is cleared for the grub menu or delay.
3. Something displays the BGRT logo.
4. Screen is cleared and some
> Who or what is step 3? Is it a separate plymouth instance just for
initrd?
It's the kernel ("efifb: showing boot graphics").
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
A solution, but a bit scary:
1. If "splash" then tell fbcon it's not allowed to take over the
framebuffer:
fbcon=map:1
2. After plymouth is finished (or even when it's just started and taken
over the framebuffer), tell fbcon it is allowed to use the framebuffer:
$ con2fbmap 1 0
This c
or
Plymouth's 8 second device timeout.
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Daniel van Vugt (vanvugt)
** Changed in: linux (Ubuntu)
Status: New => In Progress
--
You received thi
First draft, proof of concept, fix.
** Patch added: "0001-fbcon-Defer-AND-delay-console-take-over.patch"
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1970069/+attachment/5740765/+files/0001-fbcon-Defer-AND-delay-console-take-over.patch
--
You received this bug notification because
** Changed in: plymouth (Ubuntu)
Status: In Progress => Invalid
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
Annoying boot messages interfering with splash screen
S
The kernel patch is still in progress but I also wonder if plymouthd
starts early enough to do all the console blocking? If so then it could
FBIOPUT_CON2FBMAP like con2fbmap does, to umap the console from the
framebuffer. But that's still racing with other kernel things which
might have already dum
Here's a complete self-contained solution. Do kernel patches need to be
proposed elsewhere?
** Patch added: "0001-fbcon-Defer-AND-delay-console-takeover.patch"
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1970069/+attachment/5741542/+files/0001-fbcon-Defer-AND-delay-console-takeover
Added "Signed-off-by:"
** Patch added: "0001-fbcon-Defer-AND-delay-console-takeover.patch"
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1970069/+attachment/5741877/+files/0001-fbcon-Defer-AND-delay-console-takeover.patch
--
You received this bug notification because you are a memb
I think it's fortunate the Ubuntu kernel team rejected my email
formatting. They also suggest it should go upstream first. One reason
against that was I originally couldn't get the upstream kernel to
reproduce the bug. But today it does, so upstream patches shall go.
--
You received this bug noti
Here's what was sent for review upstream. Thankfully only the
description changed, no code.
If anyone has the ability to test kernel patches in the meantime then
please do. I'm starting a long weekend...
** Patch added: "fbcon-Defer-AND-delay-console-takeover_upstream-v1.patch"
https://bugs.l
The kernel documentation explicitly mentions mailing lists for other
components but not the one being modified:
FRAMEBUFFER CORE
M: Daniel Vetter
S: Odd Fixes
T: git git://anongit.freedesktop.org/drm/drm-misc
F: drivers/video/fbdev/core/
This seems to be a bug in the kernel
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
Annoying boot messages interfering with splash sc
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 f
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).
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 recei
** Changed in: plymouth (Ubuntu)
Status: Invalid => Confirmed
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
Annoying boot messages interfering with splash screen
Sta
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 paramet
"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 kn
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 are
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
Annoying boot messages interfering with splash screen
Status in linux package in Ubuntu:
In Progress
Status in plymouth packa
> 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 efif
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 talk
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
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 pap
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
Canonical's Ubuntu QA, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
Annoying boot messages interfering with splas
> 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 who
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"
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1970069/+attachment/57
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
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 receiv
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 screen".
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
Canonical's Ubuntu QA, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
** 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
Canonical's Ubuntu QA, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Ti
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
Canonical's Ubuntu Q
** 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
+ n
** 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 parameter
Same issue in Yelp (the Help app) when in Xorg sessions. So I think this
is a webkit2gtk bug that only manifests on Xorg (like our installer/live
sessions).
Also I have removed the series targets because they were getting
cluttered and likely targeting the wrong package anyway.
** Also affects: w
** Tags removed: kinetic lunar
** Tags added: udeng-2004
--
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1970069
Title:
Annoying boot messages interfering with splash screen
Status in linux
53 matches
Mail list logo
