02-06-2020, 12:06 PM
(02-06-2020, 08:32 AM)Jeremiah Cornelius Wrote:(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.