Home | News | Download | Packages | Forum | Wiki | Github

Blackscreen on Xorg start


#1

So I was installing xorg-minimal xf86-video-vesa twm xclock xterm and copied the default xinitrc from /etc/X11... to ~/.xinitrc on my normal user.

When I use “startx” X will start but I only see black screen with a white underscore at the top left. I cannot switch to any other VT or force shutdown via CTRL + ALT + BACKSPACE.

There is no relevant error or warning in neither dmesg nor Xorg.0.log.


Void musl on qemu, startx fails
(m4k5) #2

Hello.

I do not know whether viewed these topics and I do not know if they can help:
topic-1
topic-2
topic-3
topic-4
topic-5
topic-6
topic-7

You give enough details. You can start X with a record of this file:

    $ startx >> yourrandomfile

and let us know here :wink: .


(Masato the Empty) #3

It’s unfortunate that you lose keyboard control after this; I take it your only recourse is to hard reset the system? Note that ctrl-alt-bksp has been disabled by default for years in Xorg, so that not working isn’t a surprise.

However, in this case, it doesn’t matter since you don’t seem to actually be in X. Your note about the underscore in the corner is what tells us that, so good detail there.

If you can’t use ssh to see if the system is still responsive, then your best bet is trying to do what @m4k5 suggested, and redirect xorg output. There’s one thing I’d add though.

$ startx >> yourrandomfile 2>&1

so that you record both stdout and stderr. If the system isn’t completely seizing up preventing the flushing of data to disk, then this might leave you a record of what is happening.


#4

I am finally home and I can post some images:

Image of the issue:

Xorg.0.log part #1

Xorg.0.log part #2

Thank you for your replies! I will check those things shortly.


#5

I updated and still have the same issue
I tried startx >> yourrandomfile 2>&1 but that file would just be empty… which is extremely weird.
Trying with Qemu monitor to send ctrl + alt + F1/F2/F3... doesn’t change VT.
It looks like the VM does not react anymore.


(m4k5) #6
cat /var/log/Xorg.0.log | grep 'EE'

— a tip:

(WW) warning, (EE) error, (NI) not implemented, (??) unknown

Give us the result, please.[quote=“AnachronGuy, post:1, topic:1880”]
There is no relevant error or warning in neither dmesg nor Xorg.0.log.
[/quote]

After all, the last photo attached you I see the error. Concerning fbdev. Perhaps there’s more …


(Masato the Empty) #7

Did you ever get to try the different VGA cards? besides std, there are cirrus and qxl, at least on current Linux versions.

Your “yourrandomfile” should at least have the xorg startup messages, including the versions and a mention of the log file (I guess it doen’t log everything to stdout/err, but you should get at least this…)

So it sounds like everything could be crashing quite hard. My VMs run fine, including Void/Xorg. I’m using Void’s qemu package, and before switching to Void, I was using Debian’s (both I use with libvirt). So it could be an issue with your qemu build.

It’d still be good if you can setup sshd on the guest. You can use ssh or just putty on the host to get into it (makes it easier to copy and paste from log files, rather than having to take screen caps).


#8

I do actually have to close this.

I converted the void.qcow2 image via qemu-img convert -O vdi void.qcow2 Void.vdi to VirtualBox-Image Void.vdi and ran that.

No problems with X. All is smooth.
Seems like an issue on Qemus side.


(Benjamin) #9

So is this issue resolved then?


#10

Yes I will use VirtualBox for further testing.


(Masato the Empty) #11

so it was the build then. glad you got it working, even if it’s via virtualbox. (not particularly a fan, but it’s good that qemu isn’t the only game in town; and vbox has got plenty of users here too).