Xorg stopped working after updating yesterday

thePiGrepper · 2018-06-11 15:42:10

The title says it all. After updating yesterday (last time was May 1st I believe) and rebooting the system, the kernel booted nicely, but just when the display manager was supposed to kick in, only a dash appear on the screen and that was it. the strange thing was that, it wouldnt let me switch ttys either, so I had no option but to chroot in using the arch installer. I disabled the lightdm service and restarted and everything is OK, by that I mean, all the TTYs are available and it's behaving normally.
So, what can this be? is it xorg itself? I'm using lightdm to load a xfce DE, but the latter shouldnt matter because I never got to that part in the first place, lightdm itself didnt work at all. oh, btw, I tried with lxdm and it didnt work either, so Xorg maybe?
any ideas are appreciated.

tyzoid · 2018-06-11 16:26:48

Can you post your xorg log?

andreas_baumann · 2018-06-11 18:47:06

What Xorg driver are you using on which graphic card?

thePiGrepper · 2018-06-11 20:45:06

It's a HP mini 210-4000 with a n2800 atom processor, so no discrete graphics. regarding the log, I'll post it when I get back, but it didnt show anything interesting. It has been working fine without xf86-video-intel.

Last edited by thePiGrepper (2018-06-11 20:48:29)

thePiGrepper · 2018-06-12 02:44:21

I just confirmed that it was, as expected, the xorg-server package when it updated from 1.19.6+13+gd0d1a694f-2.1 to 1.20.0-5.0. What would be the next step from here? /var/log/Xorg.0.log doesnt say much of anything.

andreas_baumann · 2018-06-12 17:02:58

Did you install xf86-video-intel or xf86-video-vesa? You can either run it with intel drivers or with VESA drivers, but drivers you need. :-)

andreas_baumann · 2018-06-12 17:04:46

Also xf86-video-fbdev may work..

andreas_baumann · 2018-06-12 17:06:28

The closest thing I found in the Archlinux wiki is: https://bbs.archlinux.org/viewtopic.php?id=144208. So it's a GMA 3600?

What is lspci -v showing for the VGA device?

thePiGrepper · 2018-06-12 20:13:51

andreas_baumann wrote:

Did you install xf86-video-intel or xf86-video-vesa? You can either run it with intel drivers or with VESA drivers, but drivers you need. :-)

Actually, no. The atom n2800 comes with intel GMA3600 (https://wiki.archlinux.org/index.php/Intel_GMA_3600) gpu, and there isn't accelerated driver support for xorg, so either xf86-video-intel or x86-video-vesa wont do a thing here. As a matter of fact, that's also consistent with my system's configuration. I only have xorg-server and it works (or worked before last update, as I previously said). So what I think is that some change in Xorg broke something for my cpu/gpu. what exactly, I dont know yet, but according to the upstream git repository there are around 856 commits between those two versions (without taking into account the additional patches and the exact commit from which the previous package of Xorg was compiled, so it's probably less than that), and at some point there it broke my system. I dont know what would be the next step here, besides reporting the bug to upstream, right?

as I said before. The more alarming issue is solved now, after downgrading Xorg. the next issue would be how to keep upgrading Xorg in the future without breaking my system again.

Last edited by thePiGrepper (2018-06-12 20:15:20)

andreas_baumann · 2018-06-13 07:56:27

pacman -Ql xorg-server | grep mode
xorg-server /usr/lib/xorg/modules/drivers/modesetting_drv.so

aha, so it uses the modesetting video driver, which is part of xorg-server, didn't know about that one.

If it doesn't work in Xorg 1.20, there is little you can do but report it upstream.
The Intel driver may be proprietary and Intel not be willing to release the code or a fix. Then you are
really out of luck.

thePiGrepper · 2018-06-13 16:36:02

andreas_baumann wrote:

pacman -Ql xorg-server | grep mode
xorg-server /usr/lib/xorg/modules/drivers/modesetting_drv.so
aha, so it uses the modesetting video driver, which is part of xorg-server, didn't know about that one.
If it doesn't work in Xorg 1.20, there is little you can do but report it upstream.
The Intel driver may be proprietary and Intel not be willing to release the code or a fix. Then you are
really out of luck.

Sure, I already made my peace with the fact that this generation of Atom processors won't get GPU support. That's 'ok' with me. the problem at hand though, is that some *additional* change happened on this particular release breaking xorg-server for my system. Well, as you say I should report it upstream now, so that they can fix it eventually. Thanks for taking time to answer.

Btw, I've noticed that the package update cycle is a little slow. I was wondering if you are in need of mantainers or any other kind of help so that we can try to keep up to date with upstream Arch? I'm more than willing to help. who do I need to talk for that?

andreas_baumann · 2018-06-13 16:51:08

Ah. Help is always good. :-)
We basically can use any help we get: testers, packagers, developers. You can talk to me, deep42thought or tyzoid about that.

Maybe a first step is to help testing packages, this means: reporting them as being in use (there was a forum entry somewhere
in "How to test").
A mirror is always welcome idea, but only if you have bandwith or machines to spare.

Helping to fix packages as seen on https://packages.archlinux32.org/buildm … how=broken
Providing a build slave as on https://packages.archlinux32.org/buildm … slaves.php.

Improving the build system (https://buildmaster.archlinux32.org/) is also very nice.

The reason things are behind is exactly the build system. We sort of buffer the packages till we deem them
stable. Sometimes a dependency blocks other packages, that's when things seem to lag.
You can always use [testing], [community-testing], but be prepared for trouble. :-)

deep42thought · 2018-06-13 18:07:15

andreas_baumann wrote:

The reason things are behind is exactly the build system. We sort of buffer the packages till we deem them
stable. Sometimes a dependency blocks other packages, that's when things seem to lag.
You can always use [testing], [community-testing], but be prepared for trouble. :-)

Let me add, that we had currently some lower level issues with the build system, letting ~1k packages accumulate on the build list. This created some additional lag, which should vanish in the next few days, but I think, as abaumann said, the most pressing things are testing packages (not that tedious) and fixing broken packages (more involving, but also more important).

Thanks for your offer to help! btw: we're mostly in #archlinux32 on irc.freenode.net

cheers,
deep42thought

thePiGrepper · 2018-06-13 18:42:31

Thanks for the links. I'll take a look. I usually take a portion of my free time to play with my netbooks and different distros/DEs/etc, so I'm thinking that setting an Arch distro using the testing repos would be the easiest thing to do for now. If I encounterany issue or I'm able to fix one of the existing ones, I'll give it a try. Thanks again for the quick reply, and I'll see you around.

andreas_baumann · 2018-06-13 19:58:45

BTW:

Does this sound familiar:

/var/log/Xorg.0.log:

[ 22.718] (EE) Caught signal 4 (Illegal instruction). Server aborting

coredumpctl showing a

Stack trace of thread 242:
#0 0x00000000b7f58d21 __kernel_vsyscall (linux-gate.so.1)
#1 0x00000000b7d749c2 raise (libc.so.6)
#2 0x00000000b7d5e71e abort (libc.so.6)
#3 0x000000000056b555 OsAbort (Xorg)
#4 0x000000000056b5d2 FatalError (Xorg)
#5 0x000000000060a93a n/a (Xorg)
#6 0x00000000b7f58d38 __kernel_rt_sigreturn (linux-gate.so.1)
#7 0x00000000b632cd37 n/a (kms_swrast_dri.so)
#8 0x00000000b5f0181f n/a (kms_swrast_dri.so)
#9 0x00000000b7f698b3 call_init.part.0 (ld-linux.so.2)
#10 0x00000000b7f699b2 _dl_init (ld-linux.so.2)
#11 0x00000000b7f6d7e0 dl_open_worker (ld-linux.so.2)
#12 0x00000000b7e7bc91 _dl_catch_exception (libc.so.6)
#13 0x00000000b7f6d077 _dl_open (ld-linux.so.2)
#14 0x00000000b7b8cb73 n/a (libdl.so.2)
#15 0x00000000b7e7bc91 _dl_catch_exception (libc.so.6)
#16 0x00000000b7e7bd40 _dl_catch_error (libc.so.6)
#17 0x00000000b7b8d333 n/a (libdl.so.2)
#18 0x00000000b7b8cc16 dlopen (libdl.so.2)
#19 0x00000000b7f2eb6e n/a (libgbm.so.1)
#20 0x00000000b7f2ecb3 n/a (libgbm.so.1)
#21 0x00000000b7f2ee24 n/a (libgbm.so.1)
#22 0x00000000b7f2f0d7 n/a (libgbm.so.1)
#23 0x00000000b7f2c9ba gbm_create_device (libgbm.so.1)
#24 0x00000000b6ef4ee4 glamor_egl_init (libglamoregl.so)
#25 0x00000000b7f49b4a n/a (modesetting_drv.so)
#26 0x000000000051c169 InitOutput (Xorg)
#27 0x000000000049d8e1 n/a (Xorg)
#28 0x00000000b7d60041 __libc_start_main (libc.so.6)
#29 0x000000000049e7e2 _start (Xorg)

See also https://bugs.archlinux32.org/index.php? … task_id=39

libvirt decided suddenly to force me to use the modesetting xorg driver (after VESA failing in many beautiful ways).

thePiGrepper · 2018-06-14 17:35:46

I just checked my old Xorg.0.log and it doesn't appear to me. what machine are you using btw?

andreas_baumann · 2018-06-14 18:48:14

This is a standard VGA in a libvirt/qemu setting, which is especially annoying, as I cannot even test
Xorg currently, see also bugs:
- https://bugs.archlinux32.org/index.php? … task_id=39 and
- https://bugs.archlinux32.org/index.php? … task_id=42

jeverett · 2018-09-30 03:54:08

Thanks to you all for posting about this and looking into this already! If it helps, I'm getting almost exactly the same kind of error as shown in FS#39 on bugs.archlinux32.org (https://bugs.archlinux32.org/index.php? … task_id=39), but getting it on my Thinkpad T42.

Summary of what I'm seeing: Xorg is crashing (repeatedly) when the machine tries to launch lightdm, so all I see on startup (after the normal systemd startup messages) is an "underscore" cursor flashing at the upper-left hand side of the screen, where the machine can sit for many minutes. As mentioned in the first few posts, I can't press Ctrl-Alt-F1 or Ctrl-Alt-F2 for an alternate console. This started happening after an upgrade on Friday 09/21, when mesa and lightdm were upgraded (among other things). Looking through the journactl output, I see repeated attempts to launch Xorg, with it dumping core until it's tried seven times.

After looking through FS#39, I downgraded mesa from 18.1.8 to 18.1.7, and the machine is back to normal: lightdm is running again, and I'm getting no errors in journalctl.

If I can help with anything with this bug, please let me know. As it is, I'll try to keep to mesa 18.1.7.

K8ebBM214bp4UJV · 2018-10-04 22:20:40

Hello. Like all the others I'd like to thank every dev working hard to keep Arch alive in 32 bits.

I had the same issue that after a full system update my pc couldn't boot anymore and just a blinking underscore on a black screen. The installation is pretty standard with lightdm and xfce, on a Pentium 4 with a Geforce fx-5200. Like another poster said, the problem started 20 something of september when Linux got bumped to 4.18.6. Last time something similar had happened it was a bug on xorg, which was fixed on the next update. Thinking it happened again, I tried to update from testing, tried to downgrade xorg, thought maybe it was a bug on linux, but no dice. Disabling the lightdm service I was able to boot into the system but any attempt to launch an xorg session would give a coredump. I don't use the intel integrated graphics, so i have installed the nouveau driver. I tried to reinstall the driver and everything I could think of, but the problem persisted.

The only solution I managed at the time, and after reading some posts on the arch forums, was to roll the entire system back to the point before the linux update. For anyone in need of such fix, this is what I did:

- remove all packages in cache

sudo pacman -Scc

- modify /etc/pacman.d/mirrorlist, and comment out the current servers but adding the last valid date from the archives (september 7th in my case)

sudo nano /etc/pacman.d/mirrorlist

#Server = https://mirror.archlinux32.org/$arch/$repo
#Server = https://32.arlm.tyzoid.com/$arch/$repo
Server = https://archive.archlinux32.org/repos/2018/09/07/$arch/$repo

- make a full system upgrade

sudo pacman -Syyuu

This last command will downgrade every package up to the date from the archive. After this my system would boot without issues. When you want to update normally, you must edit the mirrorlist file again and uncomment the servers and delete the archive entry.

While trying to identify the problematic package, I updated independently everything i thought could be the culprit, but taking a hint from the previous poster (thanks jeverett!) mesa was guilty. The logs pointed to an 'Illegal instruction' by nouveau_dri.so. Tracking this down, after updating mesa from the testing repo everything is well once more.

Updating to mesa 18.2.1-1.0 the problem is gone, and doing a full system upgrade as of the time of this post, everything is fixed.

Again thank you devs and collaborators.

levi · 2018-10-05 00:51:03

When you did that last system upgrade are you on the live repos or still configured to use the September 9th archives (thanks for the instructions on how to do that by the way; I wasn't aware of that)?

I personally stick my intel graphics by the way, as in my experience nouveaux is a crapshoot and the alternative binaries for proprietary cards are purely suck it and see, but that doesn't help others using intel graphics who are having booting problems. All seems to still be working for me, which is why I've not posted before in this thread.

deep42thought · 2018-10-05 05:17:08

K8ebBM214bp4UJV wrote:

Updating to mesa 18.2.1-1.0 the problem is gone, and doing a full system upgrade as of the time of this post, everything is fixed.

You say mesa in [testing] work, while mesa in [extra] does not? Should we move mesa from testing to extra, then?

regards,
deep42thought

K8ebBM214bp4UJV · 2018-10-06 02:11:59

@levi
np. yeah i wasn't aware of it until i needed it two weeks ago. I usually install 'downgrade' from the aur and start doing some digging one package at a time. it is time consuming, though, so this alternative is like a nuke. i did restore the current servers and commented out the archive link to keep it just in need of another roll back. i had to switch to noveau when the proprietary nvidia driver got deprecated (it had xorg as dependency, and as it got updated, the nvidia couldn't satisfy dependencies). nouveau works for me, so meh... this is just an internet browsing machine for the most part.

@deep42thought
yes.

again thank you for your hard work.

[url=https://i.imgur.com/9N9bJSe.png]

[/url]

Arch Linux

#1 2018-06-11 15:42:10

Xorg stopped working after updating yesterday

#2 2018-06-11 16:26:48

Re: Xorg stopped working after updating yesterday

#3 2018-06-11 18:47:06

Re: Xorg stopped working after updating yesterday

#4 2018-06-11 20:45:06

Re: Xorg stopped working after updating yesterday

#5 2018-06-12 02:44:21

Re: Xorg stopped working after updating yesterday

#6 2018-06-12 17:02:58

Re: Xorg stopped working after updating yesterday

#7 2018-06-12 17:04:46

Re: Xorg stopped working after updating yesterday

#8 2018-06-12 17:06:28

Re: Xorg stopped working after updating yesterday

#9 2018-06-12 20:13:51

Re: Xorg stopped working after updating yesterday

#10 2018-06-13 07:56:27

Re: Xorg stopped working after updating yesterday

#11 2018-06-13 16:36:02

Re: Xorg stopped working after updating yesterday

#12 2018-06-13 16:51:08

Re: Xorg stopped working after updating yesterday

#13 2018-06-13 18:07:15

Re: Xorg stopped working after updating yesterday

#14 2018-06-13 18:42:31

Re: Xorg stopped working after updating yesterday

#15 2018-06-13 19:58:45

Re: Xorg stopped working after updating yesterday

#16 2018-06-14 17:35:46

Re: Xorg stopped working after updating yesterday

#17 2018-06-14 18:48:14

Re: Xorg stopped working after updating yesterday

#18 2018-09-30 03:54:08

Re: Xorg stopped working after updating yesterday

#19 2018-10-04 22:20:40

Re: Xorg stopped working after updating yesterday

#20 2018-10-05 00:51:03

Re: Xorg stopped working after updating yesterday

#21 2018-10-05 05:17:08

Re: Xorg stopped working after updating yesterday

#22 2018-10-06 02:11:59

Re: Xorg stopped working after updating yesterday

Board footer