Updated today can't startx - xinit: giving up xinit: unable to connect to X server
 

Once again I'm in need of help.
I'm running -current. Today I installed the update with the new kernel 6.1.20.
I'm using GRUB to boot.

When I tried to run startx I get the following:

xinit: giving up
xinit: unable to connect to X server: connection refused
xinit: Server error

I've tried looking into this but so far I've heard that it's a driver issue but I'm using nouveau so nothing is changed.

I've also seen a couple of posts regarding making some changes to the /etc/default/grub file. I'm a little afraid of changing things and I don't want to make things worse.

Is it possible that this has something to do with GRUB?

I've looked at the /var/log/Xorg.0.log file and it says:
Caught signal 11 (Segmentation Fault). server aborting

I'm at a loss for competent help. So many of the posts online are really old and I know the method of fixing things can evolve over time.

Any recommendations would be very welcome.

Thanks.

If you did a kernel update something did change. As a user of the stable version of Slackware you are supposed to read and follow the important text in the changelog for kernel upgrades:

As a beta user of Slackware current you don't even get that text, you are supposed to know that.

With a kernel upgrade the kernel and all the modules (drivers) gets updated (replaced). As different Slackware users choose different boot loaders each Slackware user will have to make sure that the boot loader is updated to point to the new kernel.

Until you reboot, your old kernel will still be running, but it will no longer have modules for its version installed. Unable to load any drivers it might not be able to start X.

Once you reboot, if you have done everything right, your new kernel will be booted and it will use its new modules.

If you didn't do everything right with your boot loader you might still be running the old kernel which no longer will be able to load any modules from /lib/modules. You can check which kernel version you are running by looking at the output of:

or

regards Henrik

Thanks for your reply. I did update GRUB and I did reboot. uname -r shows the new kernel. I'm using the huge kernel.

Stop using the huge kernel and switch to the generic kernel with an initrd.

https://docs.slackware.com/howtos:sl...ge_for_generic

There are numerous tools available to help with the initrd and grub configuration.

Things just got worse. I tried to just reinstall slackware and now I get:
WELCOME TO GRUB
error: unknown filesystem.
Entering rescue mode...
grub rescue>

So I've done some searching and this SEEMS to be what's recommended:

From the prompt type "ls" which gives me (hd0) (hdo,msdos2) (hd1) (hd1,msdos4) (hd1,msdos3) (hd1,msdos2) (hd1,msdos1)
From there I typed "set prefix=(hd0,msdos2)/boot/grub" then
"set root=(hd0,msdos2)"
Then when I type "insmod normal" I get "error: unknown file system"

These are the commands from several web sites. I'm not sure what to try next. I'm am puzzled by this SEEMING to point to /boot/grub when all I've done is a fresh install and selected elilo.

Any ideas?

Thanks again.

OK. I may have answered my own question regarding the booting problem. In my BIOS I have two entries one that says SLACKWARE-15.0+ and another says SLACKWARE.
I've been trying SLACKWARE-15.0+. When I use SLACKWARE it starts. Makes sense. SLACKWARE+15 must be for GRUB. I needed elilo.

I still can't get startx to work! Bummer after reinstalling Slackware it still has the same problem. I'm still stuck.

BTW I formatted the / partition during the install hoping to wipe out what ever was causing my initial problem.

So did you find the modules for the new kernel below /lib/modules? Could you find a nouveau module with:

Sorry I can't help you with your grub issues, hope someone else has more experience from grub.

If you are reinstalling your system you might want to consider running stable Slackware 15.0 instead of current which often updates software for people to test if it is useful. Once the current version gets a release candidate status you could say that it has become a beta version. Before that, it should more be considered an alpha version.

regards Henrik

That would probably not solve his problem with the nouveu driver as both the huge kernel and the generic kernel uses the same kernel module below /lib/modules for those nVidia chipsets. As OP is not comfortable changing the boot system it might be a bad idea to add the complexity of an initrd to the boot process.

regards Henrik

grub has problems with ext4 filesystems formatted using recent mke2fs. See for example https://www.linuxquestions.org/quest...em-4175722029/.


Did it work earlier? Try the previous kernel. You can find it in https://slackware.uk/cumulative/slac...t/slackware64/

Everything worked until the last update. I've been updating the kernel since I was using 14.2. Never had this problem.

Remember - I'm no longer having a boot problem. Everything there is working as it should. It's just this startx problem.

henca - yes the nouveau.ko exists where you pointed to.

It may come to that, using 15.0 for the install. I've tried starx as me, then added another user - same problem - I even tried useing root (I know it's not recommended) - same error.

If you try the previous kernel, you may find there is a new bug in the latest kernel.

If so, the next step is to see if it has been loaded:

and if you see any messages from dmesg pointing to any problems with the nouveau driver:

regards Henrik

Well henca gave me a thought in recommending using 15.0. I'm really, really, really anal about backups. I just so happened to have a previous .iso file on another USB.

I installed from that and...I have a working X server!!!

My very special thanks to henca for staying with me on this. Help like yours is why I visit this forum so often.

This is solved but I'm still not sure what happened. For now I'm going to blacklist the kernels in my updates.

This was something other than the kernel. When I reinstalled from an older .iso file I blacklisted the kernel and ran a slackpkg update. My system wouldn't startx again.

I ended up going back to just the install from the old .iso. Going to stay put for now---no updates.

How old is that older iso? When did you upgrade last time without this problem?

mesa was upgraded on March 15, maybe it's the problem. Or earlier, xorg-server on Feb 7. Or libdrm, Feb 9.

The older .iso had the 6.1.12 kernel. In looking at the other packages that were installed that day I noticed one called x/libXaw-1.0.15-x86_64-1.tgz.

Since this mentioned "X" I'm thinking this may have really been the problem. I could try to blacklist this package and see if it changes anything when I do an upgrade but I'm too tired to do that today.

I'm sure this does have something to do with X, however. Could be the xorg-server as you mentioned.

I'm comfortable making mistakes if this is one. It takes less than 40 minutes to reinstall my whole system counting 3rd party packages and configurations.

I don't think libXaw is the culprit. libXaw is a library used in historical graphic X client programs to make the ugly user interface. It's not something the x server would use.

But as you can reinstall in 40 minutes, you could blacklist xorg-server, libdrm, and mesa, and upgrade. The odds are that one of those is the guilty one.

If that backup was updated prior to updating slackware, wouldn't rolling back to working state be a matter of minutes?

Or Snapshots are more "handy", perhaps?


Or anal is something else over there!? :D

It depends what you consider "handy". snapshots are done instantly, then recover is matter of rebooting and selecting the snapshot's boot entry in the grub menu. But of course snapshots will never replace a backup, unless sent to another drive.

It seems worth trying.
The only thing is when can I turn them back on in the future and is that going to cause something else to break.
Thanks again for staying with this. I'm still searching the internet. Not many solutions out there. One site said that ~/.Xauthority being empty was a problem but it didn't indicate how that might happen. Mine had zero bytes.

Kernel 6.1.12 is dated Feb 15, so you already have the latest xorg-server and libdrm (they were upgraded earlier in February). It seems that mesa is the only suspect left. You could try to upgrade only mesa. If X stops working, you can downgrade it using the package in your iso. Then you'll know you need to blacklist mesa before upgrades. On the other hand, if X works with the new mesa, I am wrong with my reasoning.

Got morning chores to do right now but I'll give this a try when I'm done. Thanks.

Petri - you da man!!
Mesa it is. Now going to try and upgrade all and see what happens.

I did exactly what you said I deleted the old mesa and installed the new and the x server gave me the same message. I then reinstalled the old mesa and startx worked!

Thanks a million. I would have never figured this out without your help.

It is really good that the problem has been narrowed down to Mesa, but I would not call the problem solved.

The idea with being a beta tester is to pinpoint exactly what goes wrong. Should Slackware apply some patch to Mesa? Should a patch be provided upstream to Mesa? Should Slackware forever stick to the good old version of Mesa and never update again because the upstream provider is giving out broken software and refuses to apply contributed patches? Should the Mesa project be forked to avoid problems like this? Failure to correctly answer those questions will one day give you a stable version 15.1 or 16.0 of Slackware which doesn't work on your hardware.

regards Henrik

Very good points. I'm nowhere near qualified, or able, to do the research to answer your questions. I'm not a beta tester I'm just an end user. My understanding for using -current was to obtain the most current software but doing so at some level of risk. I'm willing to take the risk since it's so easy for me to recover.

I totally agree this needs to be resolved. I hate to think I could never update this package again. But I do have a backup of the version that works for me now.

This is pretty interesting:
https://www.linuxquestions.org/quest...ce-4175723106/


Sounds like elcore found some instability in mesa/libdrm and reverted back to an older version.

Maybe what he found was similar to what I experienced.

I would say that Slackware current is not the right version for you and you are are not the right user for Slackware current.

With Slackware current there will be glitches and the idea is that the users of Slackware current shall track these glitches down and suggest improvements to make the next version of Slackware better. The idea is not that users of Slackware current shall ask for help for how to find workarounds for those glitches.

By saying so I do not want to sound like some kind of elite guy cracking down on a noob, I can easily admit that I am not a Slackware current user myself. If you for whatever reason don't think you are a beta or alpha tester Slackware current is not for you.

"Solving" your problems by blacklisting packages that break on your system will sooner or later give you a system where packages will not work together.

By switching to a stable version of Slackware you will get less trouble.

regards Henrik

I think it's valuable to hear that the bleeding edge mesa is broken. It has happened before, and PV has moved it to testing/ and put the old one back. No one else has complained about it yet. Maybe there are not many nvidia users tracking -current and using nouveau.

And the OP has now learned which packages to look at when there are problems with X.

Nope, what I did was upgrade unsupported variant/fork of 15.0 release, and reverted back to older unsupported variant of 15.0 release.
There's nothing else there to find, i.e. I'm not affiliated in any other way with either project.

Henrik - once again your response is valid, honest, and understood. Given your input on this matter I'm am marking this as unsolved.

I will say that overall my experience with -current has been quite enjoyable. My problems have been very few and far in between even though it is considered beta. It's remarkable when you think about it. If I continue to have issues I will, for sure, take your advice and move to 15.0 but in the meantime I'm still quite happy with what I have chosen.

I also can't help but notice one thing that is very important to remember. When I have a problem I do a lot of searching on the internet for a resolution. In those searches I can't help but to notice that people running Red Hat have issues with Red Hat that, many times, are not resolved. People running Arch have problems that aren't resolved. People running Mint have issues that aren't resolved. Should those people change distributions because they had a problem?

Do a search yourself for "xinit: giving up" as an example and see for yourself. Many, many, many of those posts never get any kind of resolution. In fact I never saw a cause noted for this at other sites let alone a resolution. It wasn't until the posts from Petri that I got an answer that worked. At least I have a forum to visit that has always given me an answer to my issue that gets me back up and running.

So, even though your opinion makes great sense, for now, I'm staying put.

Thanks for your help and input BTW.

Yes, also a bug report without any suggested patch has a value. However, those kind of bug reports are mostly appreciated when current reaches "beta" status with its first release candidate. At that point there is an intention to release everything in current as the next stable version and any showstopper should be reported. Before that, current is more like an "alpha" version and things are supposed to break when new versions of stuff are tested.

If those are few and no one is willing to do some deeper debugging we can only hope that the problem will be solved in the future by a new version from upstream. However, that would require someone to report the bug upstream.

regards Henrik

I am using Mesa 23.0.0 on Slackware 15.0, on an AMD card successfully. Based on my readings of reports here, the problem seems to be attributed to a Nvidia card possibly with the nouveau driver. This is a good thing to uncover and would be great to report upstream. This is why beta testing is helpful when done the right way.

As far as other distros, I think the idea of newer is always better being promulgated more, leads to alot more people on the bleeding edge, and more breakage. I am going to continue to be a fan of slackware promoting stable release cycles. This is the issue pretty much with all other distros, but also there is the one of other distros heavily customizing through patches which adds to the problem mix. I've used slackware current for years, and I can see PV's process is quite good for rooting out issues before they land on everyone. So I will definitely use stable releases for servers and production machines. -current is really only if you need to look ahead and use brand new hardware that can only run there out of box.

Henrik - I have taken your advice to heart and moved to 15.0.

XFCE looks a bit different and I had to recompile some COBOL programs but outside of that everything works, including mesa of course.

Thanks again for your input and your honesty.