(02-06-2020, 02:38 AM)danielt Wrote: I saw some of the comments about broken graphics.
I haven't seen these before so I fired up a fresh install on an SD card and that worked just fine.
However when I rebooted back into my daily driver and the display manager (gdm) wouldn't start. Once it had crashed enough times for systemd to give up restarting it I was able to get over to a console and run an apt upgrade. The package list didn't look very promising (well... a new libreoffice is nice but I didn't expect that to fix anything). However after a reboot all seems to be well again.
Does the problem reproduce reliably. In other words does anyone think the upgrade has fixed it or do you think I spot it again in a couple of days time?
I'll keep an eye out. I'm running 3 (yes) installs of Bullseye for PBP. We do have a problem of reproducibility with anything but default installations, with the same tasksel options - but I'm not teaching Experimental Design, so we can get close!
Lately I've seen the problem recently reported by others, where the initrd will time-out looking for the encrypted RootFS, which can be corrected by manually opening luks in the busybox shell and starting /init.
More troubling, without changes I'm aware of making, initrd will timeout looking for the luks encrypted volume on nvme0n1 by UUID, not partlabel! I don't know if I care to deeply troubleshoot something like this, when the transient behavior will likely change upstream with Bullseye rolling changes. For now, I manually boot from busybox when it happens, and superstitiously re-roll my initrd update after checking fstab and crypttab when I get back to userland.
— Jeremiah Cornelius "Be the first person not to do something, that no one has thought of not doing before’’ — Brian Eno, "Oblique Strategies"
02-06-2020, 08:44 AM (This post was last modified: 02-06-2020, 08:57 AM by moonwalkers.)
(02-05-2020, 02:37 PM)Jeremiah Cornelius Wrote:
(02-04-2020, 03:29 PM)wasgurd Wrote:
(02-04-2020, 03:22 PM)Jeremiah Cornelius Wrote: A bunch of mesa/gl packages updated in Bullseye today, and everything is back to "normal".
There's a crash when you push Fn + F1, F2.... F12
I can't repro this.
(02-05-2020, 08:37 AM)moonwalkers Wrote:
(02-04-2020, 03:29 PM)wasgurd Wrote:
(02-04-2020, 03:22 PM)Jeremiah Cornelius Wrote: A bunch of mesa/gl packages updated in Bullseye today, and everything is back to "normal".
There's a crash when you push Fn + F1, F2.... F12
I'm on Sid with mesa from experimental, not seeing any crashes. Though for now OpenGL compositing in KWin is unusable, have to fall back to XRender.
What's up with gparted?
It never renders right, eventually crashing the graphical session - X11 and Wayland.
Works fine for me on KDE Plasma:
About mesa updates, etc. - if you install packages from experimental AFAIK you'd need to pin experimental archive to priority 100 to ensure APT will be installing updates from it, as by default its priority is set to 1 and will install packages from there only when explicitly asked. In my case I didn't get any mesa updates (that were upgraded in experimental from 20.0-git to 20.0-rc1) until I pinned experimental to 100. If you don't know what APT pinning is read `man apt_preferences`.
(02-06-2020, 02:38 AM)danielt Wrote: I saw some of the comments about broken graphics.
I haven't seen these before so I fired up a fresh install on an SD card and that worked just fine.
However when I rebooted back into my daily driver and the display manager (gdm) wouldn't start. Once it had crashed enough times for systemd to give up restarting it I was able to get over to a console and run an apt upgrade. The package list didn't look very promising (well... a new libreoffice is nice but I didn't expect that to fix anything). However after a reboot all seems to be well again.
Does the problem reproduce reliably. In other words does anyone think the upgrade has fixed it or do you think I spot it again in a couple of days time?
I'll keep an eye out. I'm running 3 (yes) installs of Bullseye for PBP. We do have a problem of reproducibility with anything but default installations, with the same tasksel options - but I'm not teaching Experimental Design, so we can get close!
Lately I've seen the problem recently reported by others, where the initrd will time-out looking for the encrypted RootFS, which can be corrected by manually opening luks in the busybox shell and starting /init.
More troubling, without changes I'm aware of making, initrd will timeout looking for the luks encrypted volume on nvme0n1 by UUID, not partlabel! I don't know if I care to deeply troubleshoot something like this, when the transient behavior will likely change upstream with Bullseye rolling changes. For now, I manually boot from busybox when it happens, and superstitiously re-roll my initrd update after checking fstab and crypttab when I get back to userland.
i solved difficulties with crypt by using /dev/mapper/$ in fstab in my patched installer for a separate /home. might work for you here, too.
(02-06-2020, 12:06 PM)xmixahlx Wrote: i solved difficulties with crypt by using /dev/mapper/$ in fstab in my patched installer for a separate /home. might work for you here, too.
Does this mean 2 luks encrypted disks? How is passphrase handling done at boot?
— Jeremiah Cornelius "Be the first person not to do something, that no one has thought of not doing before’’ — Brian Eno, "Oblique Strategies"
(02-06-2020, 02:38 AM)danielt Wrote: I saw some of the comments about broken graphics.
I haven't seen these before so I fired up a fresh install on an SD card and that worked just fine.
However when I rebooted back into my daily driver and the display manager (gdm) wouldn't start. Once it had crashed enough times for systemd to give up restarting it I was able to get over to a console and run an apt upgrade. The package list didn't look very promising (well... a new libreoffice is nice but I didn't expect that to fix anything). However after a reboot all seems to be well again.
Does the problem reproduce reliably. In other words does anyone think the upgrade has fixed it or do you think I spot it again in a couple of days time?
Not sure if you're referring to the issues with X failures at startup or perhaps something else like hardware acceleration.
As far as the X startup issues go, it seems I can reliably reproduce them with clean installs from sha aa7b393. It appears to only appear when certain desktops are selected in tasksel. Gnome runs fine. LXDE, XFCE, Cinnamon and Mate all induce X crashes.
Interestingly, KDE Plasma and LXQT don't crash, but don't start up either: instead we see a black screen with a movable mouse cursor.
In all crashing X cases, the log reports a seg fault with OsLookupColor+0x188 as the only stack frame, with the message
"unw_get_proc_info failed: no unwind info found [-10]".
This trace is absent from the KDE Plasma and LXQT cases, which instead mention an error line reading
"Failed to open authorization file "/var/run/sddm/{<some-guid>}": No such file or directory"
..where <some-guid> is an actual guid, though the curly braces appear literally.
(02-04-2020, 03:22 PM)Jeremiah Cornelius Wrote: A bunch of mesa/gl packages updated in Bullseye today, and everything is back to "normal".
There's a crash when you push Fn + F1, F2.... F12
I can't repro this.
(02-05-2020, 08:37 AM)moonwalkers Wrote:
(02-04-2020, 03:29 PM)wasgurd Wrote:
(02-04-2020, 03:22 PM)Jeremiah Cornelius Wrote: A bunch of mesa/gl packages updated in Bullseye today, and everything is back to "normal".
There's a crash when you push Fn + F1, F2.... F12
I'm on Sid with mesa from experimental, not seeing any crashes. Though for now OpenGL compositing in KWin is unusable, have to fall back to XRender.
What's up with gparted?
It never renders right, eventually crashing the graphical session - X11 and Wayland.
Works fine for me on KDE Plasma:
About mesa updates, etc. - if you install packages from experimental AFAIK you'd need to pin experimental archive to priority 100 to ensure APT will be installing updates from it, as by default its priority is set to 1 and will install packages from there only when explicitly asked. In my case I didn't get any mesa updates (that were upgraded in experimental from 20.0-git to 20.0-rc1) until I pinned experimental to 100. If you don't know what APT pinning is read `man apt_preferences`.
your description of apt pinning is exactly correct.
experimental is default 1 priority out of 1000
installed packages are 100
default release is 500
conveniently, a combination -1 and 1001 will purge packages and reinstate release if you have i.e. cherry picked from experimental and regret that decision, etc.
I pin experimental to 2 just to KNOW that all my configs work in policy.
unless you are on unstable it is usually a bad idea to pull from experimental, although some folks have a different take on risk and happiness than I do.
in almost every "risk" case it is cleaner and more functional to install to /usr/local from packages or upstream/git.
02-07-2020, 08:32 AM (This post was last modified: 02-07-2020, 08:42 AM by moonwalkers.)
(02-07-2020, 01:42 AM)phs Wrote: Interestingly, KDE Plasma and LXQT don't crash, but don't start up either: instead we see a black screen with a movable mouse cursor.
In all crashing X cases, the log reports a seg fault with OsLookupColor+0x188 as the only stack frame, with the message
"unw_get_proc_info failed: no unwind info found [-10]".
This trace is absent from the KDE Plasma and LXQT cases, which instead mention an error line reading
"Failed to open authorization file "/var/run/sddm/{<some-guid>}": No such file or directory"
..where <some-guid> is an actual guid, though the curly braces appear literally.
The "failed to open authorization file" message is a red herring, the real problem is that sddm-greeter crashes on default Debian installation because of crash in rockchip_dri.so. Either building Mesa from git or installing the Mesa packages from experimental (where they currently have 20.0-rc1, IIRC) fixes sddm-greeter crash. Alternatively, you can add 'QT_XCB_FORCE_SOFTWARE_OPENGL=1' line to your /etc/environment, that also prevents sddm-greeter crash.
(02-07-2020, 02:02 AM)xmixahlx Wrote: conveniently, a combination -1 and 1001 will purge packages and reinstate release if you have i.e. cherry picked from experimental and regret that decision, etc.
Just to clarify - priority of -1 means the package(s) will be completely ignored by APT, and priority 1001 and higher will happily downgrade the package(s), whereas with priority of 1000 and below only upgrades will be considered.
