Bug#941908: gnome: unable to start gnome-shell, cursor only with no login
On Mon, 07 Oct 2019 14:26:28 -0500 william l-k wrote: > Thank you for your suggestions. I'll give it try and report back. gnome-shell 3.34 released to testing yesterday solving a similar issue (see https://bugs.debian.org/941782). Can you check if the problem you reported is also solved now after full-upgrading to the last testing version ? And in case it is, confirm it here ? Thank you for reporting this issue. Regards, Jean-Marc https://6jf.be/keys/ED863AD1.txt pgpOdldjbfrN_.pgp Description: PGP signature
Bug#941908: gnome: unable to start gnome-shell, cursor only with no login
Thank you for your suggestions. I'll give it try and report back. On Mon, 7 Oct 2019 16:16:56 +0100 Simon McVittie wrote:> Control: tags -1 + moreinfo> > On Mon, 07 Oct 2019 at 08:55:14 -0500, william l-k wrote:> > Problem: Instead of getting the authentication screen, the system has the> > cursor appear (which moves around just fine so the system isn't frozen), but> > never reaches a working gnome session.> > This looks like #941782. Please upgrade gnome-shell to version 3.34.x> (which was only in unstable until recently, but has just migrated into> testing, so it might not be available on your mirror yet), and see> whether this resolves the bug.> > If you cannot upgrade to gnome-shell 3.34 yet, downgrading the> gir1.2-gnomedesktop-3.0 package to the version from Debian 10 'buster'> is thought to work around this bug.> > > We are all on Debian testing. We also all had unattended upgrades running. I'll let you know if I'm able to get this to work. I'd probably forget how to fix anything if nothing ever went wrong, and then I'd be helpless in the face of disaster > > The testing/unstable suites sometimes break, despite our best efforts;> this is particularly true shortly after a stable release, as disruptive> changes that were queued up during the freeze get uploaded. If you run> testing/unstable, I would recommend using apt-listbugs to avoid upgrading Thanks for the tip on this. > to a version with known release-critical bugs.> > On critical or remote systems, I would recommend using the latest> Debian stable release, currently Debian 10 'buster', rather than> testing/unstable. > I would not recommend using unattended-upgrades with testing/unstable.> It's usually OK as a way to install security updates on a stable system,> but testing/unstable has too many transitions between incompatible versions> for unattended-upgrades to do the right thing in all cases. Learned this the hard way. I renamed the program for when running on a testing system: unintended-upgrades > > smcv> >
Bug#941908: gnome: unable to start gnome-shell, cursor only with no login
Control: tags -1 + moreinfo On Mon, 07 Oct 2019 at 08:55:14 -0500, william l-k wrote: > Problem: Instead of getting the authentication screen, the system has the > cursor appear (which moves around just fine so the system isn't frozen), but > never reaches a working gnome session. This looks like #941782. Please upgrade gnome-shell to version 3.34.x (which was only in unstable until recently, but has just migrated into testing, so it might not be available on your mirror yet), and see whether this resolves the bug. If you cannot upgrade to gnome-shell 3.34 yet, downgrading the gir1.2-gnomedesktop-3.0 package to the version from Debian 10 'buster' is thought to work around this bug. > We are all on Debian testing. We also all had unattended upgrades running. The testing/unstable suites sometimes break, despite our best efforts; this is particularly true shortly after a stable release, as disruptive changes that were queued up during the freeze get uploaded. If you run testing/unstable, I would recommend using apt-listbugs to avoid upgrading to a version with known release-critical bugs. On critical or remote systems, I would recommend using the latest Debian stable release, currently Debian 10 'buster', rather than testing/unstable. I would not recommend using unattended-upgrades with testing/unstable. It's usually OK as a way to install security updates on a stable system, but testing/unstable has too many transitions between incompatible versions for unattended-upgrades to do the right thing in all cases. smcv
Bug#941908: gnome: unable to start gnome-shell, cursor only with no login
Package: gnome Version: 1:3.30+2 Severity: critical Justification: breaks the whole system Dear Maintainer, I would be shocked if only systems that I installed are having this problem. It sure seems like any computer running gnome will break with one of the recent updates... Description: I spend all weekend troubleshooting my sons laptop over the phone. We are all on Debian testing. We also all had unattended upgrades running. His system is barely working and needs to have a new installation. Switching to lxqt and ssdm we were able to get a graphical environment, but there were freezes at times that reisub couldn't solve requiring hard reset. Problem: Instead of getting the authentication screen, the system has the cursor appear (which moves around just fine so the system isn't frozen), but never reaches a working gnome session. I have tried every suggestion regarding similar past problems to no avail. We can reach a tty, but are unable to repair the system without reverting to a prior snapshot (if it exists). Some of what I tried: General description of attempted solutions: -looked for driver problem which is unlikely given the large differences in set ups between affected machines. - pam-auth-update --force systemctl restart gdm3 -manually removed /var/lib/gdm/.ICEauthority -tried wayland=true and wayland=false -purged the gnome destop and reinstalled. Same problem. I suspect that reinstalling debian testing running gnome won't help him IF he upgrades to the current version of whatever is killing gnome. Other affected machines: On Saturday, the same thing happened to my laptop. I had a recent snapshot and restored. Once the merge completed, I took a new snapshot, upgraded, and recreated the problem. Are laptops are not alike. He has a newer Lenova whereas I have an older toshiba. His is running an intel chip, whereas mine is running amd. Both have hdds. Our entertainment center / home server has a phenom with a seperate graphics card and developed the same problem due to unattended upgrades. This system had auto-login set up and is running off an lvm setup on two pairs of raid 1 disks. After fixing it once and taking a new snapshot unattended-upgrades upgraded some packages and did a scheduled reboot (2am). After reverting to the snapshot, this time I couldn't get the system to boot. lvm manager isn't available early in the session and I don't think grub knew how to handle a merging snapshot on this setup. I was able to get a shell on root using an install usb, and once I mounted the efi boot directory and home (probably didn't need that) and ran update-grub the boot problem was solved. Our file server running off of an old aspire netbook with an amd chip. Upgraded and has the same problem. I don't know when that one experienced a problem because I access the machine via ssh and rarely need to see the physical machine. I've been killing unattended upgrades on any other computer until this is solved. I was able to get some problem indications via email off of the unrepaired computer: Sample one: Oct 05 23:43:52 prisma minissdpd[839]: peer 10.5.6.235:6 is not from a LAN Oct 05 23:43:52 prisma minissdpd[839]: peer 10.5.6.235:6 is not from a LAN Oct 05 23:43:52 prisma minissdpd[839]: peer 10.5.6.235:6 is not from a LAN Oct 05 23:43:52 prisma minissdpd[839]: peer 10.5.6.235:6 is not from a LAN Oct 05 23:43:52 prisma minissdpd[839]: peer 10.5.6.235:6 is not from a LAN Oct 05 23:43:52 prisma minissdpd[839]: peer 10.5.6.235:6 is not from a LAN Oct 05 23:43:52 prisma minissdpd[839]: peer 10.5.6.235:6 is not from a LAN Oct 05 23:43:52 prisma minissdpd[839]: peer 10.5.6.235:6 is not from a LAN Oct 05 23:43:52 prisma minissdpd[839]: peer 10.5.6.235:6 is not from a LAN Oct 05 23:43:52 prisma minissdpd[839]: peer 10.5.6.235:6 is not from a LAN Oct 05 23:43:52 prisma minissdpd[839]: peer 10.5.6.235:6 is not from a LAN Oct 05 23:43:51 prisma minissdpd[839]: peer 10.9.5.109:42606 is not from a LAN Oct 05 23:43:51 prisma minissdpd[839]: peer 10.9.6.86:58553 is not from a LAN Oct 05 23:43:51 prisma minissdpd[839]: peer 10.9.5.79:35187 is not from a LAN Oct 05 23:43:50 prisma minissdpd[839]: peer 10.9.5.79:35187 is not from a LAN Oct 05 23:43:50 prisma minissdpd[839]: peer 10.9.5.79:35187 is not from a LAN Oct 05 23:43:49 prisma minissdpd[839]: peer 10.9.5.109:42606 is not from a LAN Oct 05 23:43:48 prisma minissdpd[839]: peer 10.9.6.145:57325 is not from a LAN Oct 05 23:43:48 prisma minissdpd[839]: peer 10.9.6.86:58553 is not from a LAN Oct 05 23:43:47 prisma minissdpd[839]: peer 10.9.6.145:57325 is not from a LAN Oct 05 23:43:47 prisma minissdpd[839]: peer 10.9.5.109:42606 is not from a LAN Oct 05 23:43:46 prisma minissdpd[839]: peer 10.9.6.145:57325 is not from a LAN Oct 05 23:43:46 prisma minissdpd[839]: peer 10.9.5.220:44867 is not from a LAN Oct 05 23:43:45 prisma systemd[1]: systemd-hostnamed.service: Succeeded. Oct 05 23:43:45 prisma systemd[1160]:
