[Expired for lightdm (Ubuntu) because there has been no activity for 60
days.]
** Changed in: lightdm (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
[Expired for linux (Ubuntu) because there has been no activity for 60
days.]
** Changed in: linux (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Fine tuning: only one extra mount is necessary .. then plymouth
finishes very quickly .. and xorg/lightdm start normally!
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1821609
Title:
** Summary changed:
- lightdm login screen briefly appears and then blanks out on Intel(R)
Core(TM)2 Duo CPU T5870
+ lightdm login screen briefly appears and then blanks out on Intel(R)
Core(TM)2 Duo CPU T5870 (boot timing issues implicated)
--
You received this bug notification because you
okay I have another solution to the timing issue .. add two partition
mounts to fstab ..
my existing sda1 disco install has /home (sda2) and /home/store1 (sda5)
mounted via fstab .. this was the original install configuration .. thus
always a mount delay ..
to test .. added the same partions
of course the sda1 partition (on the SSD) has never failed to work properly no
matter which grub source (installs on sda1,sda6,sda7,sda8,sda9) is used
plymouth always appears when sda1 boots..
this disco version was installed jan 10 with a bootstrap log date of oct 13,
2018 .. it has been
okay turned back the clock .. to a spinning metal disk previously
installed in this hardware .. ran a number of test installs all work
fine .. cosmic/bionic/disco early version disco final all work boot
normally .. always ..
thus conclusion is a SSD is very fast and can respond to requests sooner
video of sda9 boot using sda9 install of grub (native grub) .. note absence of
plymouth .. flash at top edge of screen was missed .. note brief appearance of
lightdm .. short gap then lightdm reappears .. xorg.0.log.old records the
crash .. similar to others above
xorg.0.log records
video of sda8 non-native grub boot (a disco-xubuntu iso install) sda9
has installed grub (also a disco-xubuntu iso install ) will show in
next video uploaded
note the red flash .. plymouth attempt to start .. then cursor appears
and then lightdm briefly
** Attachment added: "video of failing
I will try to do videos for you tomorrow it is getting late in the day
here ..
a brief synopsis for now ..
history: this is standard grub arrangement as "installed by default"
used to work flawlessly with multiple partitions of various linux OS's
.. It is only since early march that I noticed an
Okay, this bug has absolutely nothing to do with grub or netplan.
Changing the renderer couldn't possibly affect the behavior of X, and
the grub configuration looks, at a glace, to be run-of-the mill; pretty
much default if you disregard that there is any number of different
installs on the
bug is still present in disco xubuntu iso "final" 04-13.1-2019
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1821609
Title:
lightdm login screen briefly appears and then blanks out on
okay a previous "fresh install that was crashing plymouth
screen/lightdm/xorg was fixed by copying a known working set of netplan
conf files into /etc/netplan ..
the 01-netcfg.yaml from the "network install" uses networkd as the
renderer .. with a working network device config.. plus the
okay I stumbled across something .. the network install .. used netplan
to set-up my wifi connection to start on boot .. so as soon as systemd
networkd starts wifi is started NetworkManager thus has no access or
anyway to try for other networks.. so I tried to change this.. If I edit
the config
An additional data point for reference .. did a netboot install of
xubuntu using "daily" amd64 netboot mini.iso .. base install followed
by taskselect install of xubuntu ..
boots normally plymouth and lightdm screens appear as expected .. also
switching to foreign grub .. it still boots
okay apr 8 and apr 9 iso's have same issues kept logs of various boots
into the fresh installs .. no change in grub-source during testing was
made .. all with fresh installs
typical first boot is normal .. no crash of xorg on first start ..
second boot shows lightdm briefly then xorg crashes
third boot of same install ..
** Attachment added: "third reboot of fresh install xorg.0.log.old --
slighjtly different"
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1821609/+attachment/5253548/+files/Xorg.0.log.old
--
You received this bug notification because you are a
testing xubuntu-disco-daily.iso apr 06, 2019 First boot fine plymouth,
and xorg/lightdm started normally.. did a number of updates and
rebooted.
second boot plymouth not seen, xorg/lightdm appeared briefly .. then
vanished .. then reappears ..
checked xorg.0.log(s) ..
xorg.0.log .. seemed ok
just some summary thoughts in addition to point to some anomalies ..
the "failures in lightdm appear to correspond with shorter journal logs ..
so certain processes are not running as expected ..
plymouth also does not appear on the screen ..
as it needs the proper graphics support ..
--
I've been merrily switching between OS's without this kind of issue for more
than 10 years ..
the behaviour changed recently in the last 30 days ..
it was fine prior to that ..
This is a regression bug and will annoy anyone working with multiple instances
of disco xubuntu for testing..
yes
Your setup is anything but a typical one, and bugs should not be used to
"ask" how something works the way it does. You mentioned that the
"original" disco install always works fine, so I don't think there's a
valid bug here at all?
--
You received this bug notification because you are a member
okay generated the default grub.cfg via sda6 grub-install boot instance
.. vt.handle=1 is set by default for self root boot about a minute to
boot
no change .. still no plymouth on boot but there is a flicker with
lightdm .. which restarts once video mode switch has happened ..
note all grub
whoops added the wrong attachment above it is the one including the
grub-update dialog .. instead of being the bot after the command
** Attachment added: "this one is after the grub-update .. accidental switch"
here is the journalctl boot log for sda6 /zlink4 booted by it's own
install of grub (self grub)
(it was reinstalled for this purpose .. to show it works .. however
plymouth does not show on the screen at all on boot but does on shutdown
)
now one change is addition of a vt.handoff=1 to the end
here we have a normal journalctl boot log .. notice the size .. more
entries .. about 1 minute start to finish source the partition that
always works lightdm starts normally plymouth appears on screen etc.
this one was booted by grub installed by zlink4 - on sda6 ..
** Attachment added: "zlink1
** Summary changed:
- lightdm login screen briefly appears and then blanks out on Intel(R)
Core(TM)2 Duo CPU T5870 - failure to load i915 kernel module
+ lightdm login screen briefly appears and then blanks out on Intel(R)
Core(TM)2 Duo CPU T5870 (using "foreign grub")
--
You received this
so why the peculiar behaviour that lightdm works when the partition
installed native grub boots the system
BUT not when a grub installed by another partition is used then lightdm
consistently crashes and the machine locks up..
BUT if i915 is added to /etc/modules in the offending partition it
i915 is loaded just fine on your first journal log:
Mar 25 23:26:06 zlink2 kernel: [drm] Initialized i915 1.6.0 20181204 for
:00:02.0 on minor 0
but it's happening after lightdm is started, so I'd say it's lightdm
which is just being too hasty
** Changed in: xorg-server (Ubuntu)
a little digging and plymouth is supposed to work with drm modesetting
drivers which means i915 has to be loaded for it to work .. so not
seeing it means ..some hardware detection has failed .. is that part of
plymouth or something else?
since it works on the upgraded install on sda1 I suspect a
Kernel module will load if added to /etc/ modules .. I have my sda1
partition running kernel 5.0.0-8.9 as are the iso's tested recently .. my
sda1 partition loads i915 without using /etc/modules.. I notice that the
recent isos do not show Plymouth progress screen at startup..is that
relevant?
If you're sure that's the problem then we would need to figure out which
kernel version it started in. Please try some different kernel versions:
https://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D
and see if you can find the two closest versions where one doesn't have
the bug and the
31 matches
Mail list logo
