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.