I've have alienbob's ktown installed for a number of weeks on current.

Struggled with slackpkg and slackpkg+ for a number of weeks. I think I've got over that learning curve as everything been working nicely for a week or two including the updates on 23May2018.

Today updated all updates from and including 25May2108.

Now when I boot into the system everything is fine until I start 'startx' when all I get is a black screen.

I've dropped my inittab back to 3 so I can get to the command line at boot. I'm using grub.

I've followed the instructions from alienbob

Just in case that got messed up.

I've also run 'xwmconfig' and select 'xinitrc.xfce' as my desktop session. Same result I get a black screen immediately after 'startx'

Any suggestions? I'm running slack current in virtualbox.


Now there's a thought. I'll try running the virtualbox addons stuff as there's been a few kernal upgrades in what I've done this morning.

Hello,

Can you post the output of command :
--
SeB

Made some progress then went backwards.

Rebuilt the packages virtualbox-addons and virtualbox-kernel-addons and installed same. Everything seemed to start ok except the mouse in virtualbox wouldn't move.

Rebuilt the packages again, don't ask why, now I'm almost back to square 1. For a normal start the login manager starts, so I enter the credentials then get the black screen.

Log file attached.

I'm going to continue looking down the virtualbox route for the problem.

Alex

Attached Files

Xorg.1.log (26.4 KB, 37 views)

Slowly going forwards.

Now I can get startx to start everytime. Not sure how I managed this. Either it was

1. moving from 4.2.8 to 4.2.10 for the virtualbox addons
2. rebuilding initrd again, even though I'd already done that.

or more likely I've got a better feel for what's happening. See below.

My session works now with some features. Which are -

1. start a session and log on to get to the desktop
2. click the Maximise button, on the title bar, I get the black screen
3. click the restore button, on the title bar, I get the log on screen so I have to log on again

1. start a session and log on to get to the desktop
2. gradually increase the size of the window, when it reaches about two thirds of the available screen, I get a black screen
3. slightly reduce the size of the screen, I get the log on screen back again so I have to log on again

I've now reverted back to kernel 4.14.43 which was the one that last worked correctly. Same problem.

It might be that there is an issue with one or more packages I installed this morning which were from and including 25May2018. At the moment I've got no idea how I can test the theory.

I have a backup from 21May2018 which might have helped but looking at the mirrors the packages from 23May2018 that have subsequently been recompiled have gone.

I could attempt to recompile

mesa
xf86-input-evdev
xf86-input-synaptics
x/xorg-server
x/xorg-server-xephyr
x/xorg-server-xnest
x/xorg-server-xvfb

Some of the above have just been rebuilt so I'd have to identify what packages caused them to be rebuilt.

It's all getting a bit messy.

Alex


Alex

EDIT: I wrote my reply before noticing that you had the same result with Xfce, so I wrote troubleshooting steps that were specific to KDE. Anyway, this doesn't apply, but here are some things to look into if the problem is specific to KDE:

1. Are you using the "ls" colors from trapd00r/LS_COLORS? Last I checked, that caused this issue.
2. Are you using the FISH shell? FISH doesn't automatically source the files in /etc/profile.d, and you need them to get KDE 5 running.
3. Are the right files in /etc/profile being loaded? /etc/profile.d/kde.sh in particular, is necessary.

I restored from a backup taken on 21May2018.

Installed everything from 23May2018.
Rebuilt initrd
Rebuilt grub.cfg
Rebuilt virtualbox-addons
Rebuilt virtualbox-kernel-addons

Still got the same problem!

Will repeat, but next time round will exclude some packages.

First suggestion: in /etc/acpi/acpi_handler.sh, change "init 0" to "init 3". This lets you use the power button to drop to runlevel 3. Then, instead of using "startx" to launch the GUI, use "init 4" (as root). The GUI can crash, or fail to launch, to your heart's content; all you need is a tap on the power button to fall back to the console. You could even set the default runlevel in /etc/inittab to 4; again, tap the power button to escape a failed GUI launch.

Starting with my backup and using slackpkg

1. upgraded the slackware64 packages from current except those in the x series and the kernels - no problems - took a backup
2. upgraded the ktown packages from alienbob - no problems - took a backup
3. upgraded the kernel - no problems - took a backup
4. upgraded the x series packages from current - black screen
5. restored from the latest backup
6. upgraded the x series packages from current except mesa - no problems
7. upgraded the mesa package from current - black screen

Would appear from this that a fully updated Slackware Current running with alienbobs ktown has problems with the latest mesa package.

With this latest information I found this discussion in another forum

https://bugs.launchpad.net/ubuntu/+s...l/+bug/1705369

So I added nomodeset to the command line on the grub menu screen. This did the business no more black screen.

To make this permanent I've added nomodeset to the GRUB_CMDLINE_LINUX_DEFAULT line in the file /etc/default/grub

From the above is there an issue with mesa-18.1.1-x86_64-1 that wasn't there with mesa-18.0.4-x86_64-1

Would you be willing to bisect the issue with git between those two versions? Its tedious, but not really that hard. It would also help to make sure it hasn't been fixed in the git master first.

Just a thought, since you mentioned previous struggles with slackpkg - I’ve seen this behavior before when forgetting to run

along with your other slackpkg commands. Just want to rule that out, if you are in fact running that command as well.

Yes I could give it a go. Am familiar with bisecting libreoffice for regressions, but that's a stand alone program. So will need some advice on how I can integrate the mesa git code into my system.

Alex

What video driver are you using? I adapted a script from Pat's script in current to build from the mesa git master a few years ago. The problem is that its specific to nouveau and if you are using amd or intel you will need to alter it a little bit (You can see Pat's script from reference). You may also need to build libdrm from the master if configure fails and you can specify a specific commit with the environment variable 'COMMIT'.

For example.
The slow and easy way to do this is to bisect mesa in a clone and then feed the commits it wants you to test to the slackbuild, use upgradepkg and then test.

Attached Files

	mesa.tar.gz.txt (3.3 KB, 7 views)
	libdrm.tar.gz.txt (2.8 KB, 5 views)

With the information I've got I should have both good and bad starting points. So what I shall do is make a clone of the mesa repository, start the git bisect process then

1. for each bisect create a tar file by using a hacked version of Pat's get-mesa.sh, so as I don't loose the git stuff
2. run Pat's SlackBuild against the file created in the previous step
3. upgrade the package ensuring reinstall flag is set
4. tell bisect good or bad
5. repeat until I find the bad commit