When I run 'startx' in a console fails with a black screen
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 Quote:
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 : Code:
$ cat /var/log/Xorg.0.log SeB |
1 Attachment(s)
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 |
Slowly going forwards.
Now I can get startx to start everytime. Not sure how I managed this. Either it was
or more likely I've got a better feel for what's happening. See below. My session works now with some features. Which are -
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
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 Quote:
|
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
Code:
slackpkg install-new |
Quote:
Alex |
2 Attachment(s)
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. Code:
COMMIT=3e27b37 ./mesa.SlackBuild |
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
|
All times are GMT -5. The time now is 01:43 AM. |