Xorg broken after update

[Sante]

Hello, first off I don't need support, I just rsync'ed a system snapshot so I'm fine. But the last time I upgraded my packages via discover Xorg broke , so no GUI. Tried in vain reinstalling-reconfiguring everything xorg - related and the video drivers but no dice. So you all may want to be careful about the latest package upgrades, at least using discover to deploy them. My debian is no frankendebian btw, it's a clean and fresh buster configuration.


106 packages were marked for installation:

Code: Select all

 base-files chromium chromium-common chromium-sandbox distro-info-data fonts-noto-cjk fonts-noto-cjk-extra fonts-opensymbol
  gir1.2-javascriptcoregtk-4.0 gir1.2-nm-1.0 gir1.2-webkit2-4.0 libfribidi-dev libfribidi0 libfribidi0:i386 libglib2.0-0
  libglib2.0-0:i386 libglib2.0-bin libglib2.0-data libglib2.0-dev libglib2.0-dev-bin libglib2.0-doc libjavascriptcoregtk-4.0-18
  libmariadb3 libncurses-dev libncurses6 libncurses6:i386 libncursesw6 libnm0 libnss-myhostname libnss-systemd libpam-systemd
  libpython2.7 libpython2.7-dev libpython2.7-minimal libpython2.7-stdlib libreoffice libreoffice-avmedia-backend-gstreamer
  libreoffice-base libreoffice-base-core libreoffice-base-drivers libreoffice-calc libreoffice-common libreoffice-core
  libreoffice-draw libreoffice-help-common libreoffice-help-en-us libreoffice-impress libreoffice-java-common libreoffice-kde5
  libreoffice-l10n-it libreoffice-librelogo libreoffice-math libreoffice-nlpsolver libreoffice-report-builder
  libreoffice-report-builder-bin libreoffice-script-provider-bsh libreoffice-script-provider-js
  libreoffice-script-provider-python libreoffice-sdbc-firebird libreoffice-sdbc-hsqldb libreoffice-sdbc-postgresql
  libreoffice-style-breeze libreoffice-style-colibre libreoffice-style-tango libreoffice-wiki-publisher libreoffice-writer
  libsystemd0 libsystemd0:i386 libtinfo-dev libtinfo6 libtinfo6:i386 libudev1 libudev1:i386 libwebkit2gtk-4.0-37 libxslt1.1
  libxslt1.1:i386 linux-compiler-gcc-8-x86 linux-headers-4.19.0-6-amd64 linux-headers-4.19.0-6-common linux-image-4.19.0-6-amd64
  linux-kbuild-4.19 linux-libc-dev mariadb-client-core-10.3 mariadb-common mariadb-server-core-10.3 ncurses-base ncurses-bin
  ncurses-term network-manager python-cryptography python2.7 python2.7-dev python2.7-minimal python3-cryptography python3-uno
  qemu-kvm qemu-system-common qemu-system-data qemu-system-gui qemu-system-x86 qemu-utils systemd systemd-sysv udev uno-libs3
  ure 

Always be praised Our Lord of backups, have a nice time

[Head_on_a_Stick]

*cough*pebkac*cough*

[Sante]

actually it was a couch. so it's just my fault for relying on the gui package manager ?

[stevepusser]

It probably wasn't due to Discover, but since it seems to be a graphics driver problem, and since we have no information about your hardware and driver situation before the update, we can't say anything one way or another.

But since no one else has reported similar problems here, that argues for the problem being on your end.

[Head_on_a_Stick]

actually it was a couch.

Heathen slob!

so it's just my fault for relying on the gui package manager ?

Yes. At least the command line would have given decent error messages. And as Steve notes nobody else is complaining about this.

[Sante]

It probably wasn't due to Discover, but since it seems to be a graphics driver problem, and since we have no information about your hardware and driver situation before the update, we can't say anything one way or another.

Very right. It's a core i7-7700 system, MSI board (H110M Pro-VH) with integrated intel graphics. 8 GB system ram.
BTW I attempted to upgrade via the tty and got no errors. Rebooting, again no gui, on a bare text tty, so I had to restore the system. It is a debian 10 clean install and so far upgrading packages didn't cause anything to break. graphics driver i915 is in use.

[Head_on_a_Stick]

Do you still have the X.Org logs for the failed sessions? They usually show exactly what happened.

[Sante]

Ok so I recreated the situation. Trouble starts from the 4.19.0-6-amd64 kernel packages (all the other packages don't break the system), and looking at Xorg log files this emerges:

Code: Select all

 [  4426.779] (EE) Failed to open authorization file "/var/run/sddm/{b02fe017-788c-41dc-ad62-f6be34c0a09b}": No such file or directory

while in fact there is a file with a different name in there.

According to systemctl sddm is running, only the X terminal is nowhere to be seen among the TTYs.
Attempted to stop and restart, to no success.


I found a bug that looks similar

Debian Bug report logs - #930622 (xserver-xorg-video-intel: sddm doesn't start. (EE) Failed to open authorization file)

And a Merry Christmas and a Happy New Year to Ya'all folks.

[Sante]

Still battling with the usual problem, I disabled the sole extra repository I added (buster-proposed-updates) to see if that was the reason but again, no dice. I'm considering restoring an old root backup to see if this cures the inability to update the kernel image without nuking the graphics driver in a way that defies any re-installation and reconfiguration attempt but still no clue about why all this is my fault, all my fault. BTW it appears by the SMART mails that the brand new SSD I had replaced by the seller is going south like its predecessor, which makes me think that maybe, and I stress maybe, all I need is just to buy a new SDD. Any other point of view is more than welcome.

[Head_on_a_Stick]

the inability to update the kernel image without nuking the graphics driver

If you're using proprietary drivers then I will be rather annoyed. Name calling is on the table here.

[CwF]

all I need is just to buy a new SDD

possible, I have seen an issue like this once, multiple times, but on one particular board/cable/ssd. The disc would go read only under stress, like a many package update, and quietly fail to read only during the upgrade, bork the completion and leave the system in a curious state rebooting to a prompt.
Always fixable, it took awhile to figure it out until I couldn't save a document since the file system had gone read only, with no other errors to obsfuscate the issue. No crash, just a semi-controlled shutdown, and the disk disappeared...then it came back, I replaced it. It still claims to be good. Maybe the board, never knew for sure, attrition fixed it.

[Sante]

the inability to update the kernel image without nuking the graphics driver

If you're using proprietary drivers then I will be rather annoyed. Name calling is on the table here.

Um no, I'm using the inbuilt intel graphics now, no longer under the thrall of NVidia The old graphic adapter now does close to nothing on a FreeBSD box.

[Sante]

all I need is just to buy a new SDD

possible, I have seen an issue like this once, multiple times, but on one particular board/cable/ssd. The disc would go read only under stress, like a many package update, and quietly fail to read only during the upgrade, bork the completion and leave the system in a curious state rebooting to a prompt.
...

Just ordered a new high quality SSD drive to replace the rotten one (S3+) which in the meantime showed on logs that it had gone read only in several occasions while upgrading packages, guess doing what? Yep, borking up the process mighty fine. I managed to witness this condition once, couldn't even touch a file as root because / had been remounted RO. Also pending and unreadable sector counts just took a steep hike lately so I reckon it is about time to stop dancing around this issue (no biggie anyway, I've backups too). A clean buster install will follow so this is pretty much the end of it. This particular PC is my own private F-35