Linux computer will not show login screen when booting up

JHugh · 12-06-2018, 07:40 AM

I am trying to boot up my RTD Linux computer and when it reaches the login screen there are no buttons or textboxes on the screen. The screen is blank except for the login screen background texture, which is gray. The computer was working fine a couple weeks ago.

The system has RedHat Linux as the OS. The following RedHat Linux versions are installed:
Red Hat Enterprise Linux Workstation (3.10.0-957.el7.x86_64) 7.5 (Maipo)
Red Hat Enterprise Linux Workstation (3.10.0-862.6.3.el7.x86_64) 7.5 (Maipo)
Red Hat Enterprise Linux Workstation (3.10.0-862.6.3.el7.x86_64) 7.5 (Maipo)
Red Hat Enterprise Linux Workstation (0-rescue-3cfded4e5c8c4ab8a4d7c437e38a5ef1) 7.4 (Maipo)

We have attempted to boot from all of these and they all result in the same errors shown below:
[ 2.985667] i8042: No controller found
[ 3.355588] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[ 10.616518] iTCO_wlt: I/O address 0x8460 already in use, device disabled

Any assistance or suggestions on what to try would be much appreciated, since we need this computer to work for our code development.

MensaWater · 12-06-2018, 01:15 PM

You may be on the GUI console. If you use your mouse to drag up from the bottom it will show you the list of accounts and you can select one of those to login with (or tell it to do other and input root).

Alternatively if it is the GUI console you should be able to hit Ctrl-Alt-F2 to go to the virtual console which will be CLI based and it should show you a login prompt.

JHugh · 12-07-2018, 06:39 AM

My mouse cursor will not show up on the screen at all. But, when I used CTRL-SHIFT-F2, I managed to get to the CLI.

I performed a yum update and it updated 1108 files. Now there is a boot options for Red Hat Linux 7.6.

Unfortunately, I still have the same error messages when booting and cannot get to the GUI. I'm not sure how to proceed, since the program that I am using requires a GUI to work.

Thanks.

lazydog · 12-07-2018, 07:10 AM

Go back over to terminal 2, Ctrl-Shift-F2, and run the following:

Code:

systemctl get-default

If it returns graphical.target then you should have a GUI then I would try to use Ctrl-Shift-F7 and see if the GUI is there.
If it returns multi-user.target you are not in GUI mode and need to stat the GUI with startx. Then you need to run;

Code:

systemctl set-default graphical.target

to get the gui to start every reboot.

If everything looks good then run the following;

Code:

journalctl --dmesg

and check for any issues running the gui at startup.

JHugh · 12-07-2018, 08:53 AM

Quote:

Originally Posted by lazydog

Go back over to terminal 2, Ctrl-Shift-F2, and run the following:

Code:

systemctl get-default

If it returns graphical.target then you should have a GUI then I would try to use Ctrl-Shift-F7 and see if the GUI is there.
If it returns multi-user.target you are not in GUI mode and need to stat the GUI with startx. Then you need to run;

Code:

systemctl set-default graphical.target

to get the gui to start every reboot.

If everything looks good then run the following;

Code:

journalctl --dmesg

and check for any issues running the gui at startup.

Thank you for the response.

I ran:

Code:

systemctl get-default

It returned:

Code:

graphical.target

So I ran:

Code:

systemctl set-default graphical.target

I restarted the computer and it still has the same issue.

I tried hitting Ctrl-Shift-F7 and it went to a black screen and displayed the following lines:

Code:

[OK] Started crash rcovery kernel arming
[OK] Reached target multi-user system
[OK] Reached target graphical interface
[OK] Started stop read ahaead data collection 10s after completed changes
Starting update UTMP about system runlevel changes...
[OK] Started update UTMP about system runlevel changes
_

After it displays the above message, it just stops and does not do anything else, but I can still see the text cursor blinking.

I am trying to get to the gnome desktop.

Thanks again.

MensaWater · 12-07-2018, 09:00 AM

I believe your GUI is running because it is the GUI that interprets "Ctrl-Alt-F2". In the CLI virtuals you use Alt-<fkey> to switch (e.g. Alt-F1 would switch back to the first Virtual which by default in RHEL7 is where the GUI is, Alt-F3 would switch to another CLI virtual.

Back in 2012 I'd seen the i8042 error and my notes say:
On both servers saw: "i8042.c: No controller found" during boot just
before the nash stuff.
Looked online and this appears to be a known issue with a certain
driver and can be ignored. Found bugzilla for it at Redhat:
https://bugzilla.redhat.com/show_bug.cgi?id=583782
That says in part:
"This is known behavior of the i8042 driver -- it outputs a loud
warning when no i8042.c device has been found. It is still this way
upstream FWIW so I'm not inclined to change the default behavior."
The bug was closed with status "WONTFIX".

You might try looking up each of the errors to see if either of them relate to the mouse.

Your keyboard is working as indicated by the Ctrl-Alt-F2

On a test just now I found when I'm in the GUI console if I hit Ctrl-Shift-PgUp it shows me the login user IDs screen just like the mouse drag would. In that list I was then able to use the keyboard arrow up/down to select the login (or not listed so I could enter root) and hit enter.

If you can't get GUI console to work your app may work via X-Windows to another system. You can even do it to Windows workstations by using an X emulator such as Cygwin's X11 or commercial tool like OpenConnect eXceed.

P.S. Are you actually sitting at the monitor attached to graphical port on back of the server or are you using a KVM/Remote Console tool or a hypervisor (e.g. VMWare or MS HyperV) tool to see the console. If you're using such a tool the tool it itself may impact things. Often they have a way to sync mouse from the operating system through which you launched the console to the console itself. They also can interfere with some keystrokes as your launching OS might interpret the key stroke rather than sending it to the console.

JHugh · 12-07-2018, 09:44 AM

Sorry I was confused. I thought that CTRL-SHIFT-F2 was a typo. My computer only responds to CTRL-ALT-F2 and not CTRL-SHIFT-F2. I guess this means (maybe) that the GUI is not working.

CTRL-ALT-PgUp and CTRL-SHIFT-PgUp does not work.

I'm working with a single board computer from RTD running Red Hat Linux Enterprise Edition. The computer has a two USB ports, which I attached the mouse/keyboard and a DisplayPort ports, which I attached my monitor to. It also has two ethernet ports, one of which is connected to the internet, and two RS232/RS485 ports for my hardware device (neither are connected).

Thanks.

MensaWater · 12-07-2018, 11:49 AM

D'oh! It is a typo - it should be Ctrl-Alt-F2 not Ctrl-Shift-F2. However the comment applies - if Ctrl-Alt-F2 works it is the GUI that is seeing that. For non-GUI you don't need the Ctrl.

The Ctrl-Alt-PgUp worked for me but only if I used the PgUp key on the number pad - the other Page Up key didn't work. Specifically I used Left Ctrl, Left Alt and number pad Pg Up/9 Key (with number lock off).

Did you search for the other errors?

Is it possible one of the USB ports is bad? Are they specifically labeled for keyboard and mouse or just generic? If you reverse the mouse and keyboard while it is down then boot it up does the mouse start working and the keyboard fail?

You might also try a different mouse if you have one to rule out the mouse itself being an issue.

If that doesn't work you might need to create or modify xorg.conf.d files for it to recognize your mouse. What you would need for RTD I don't know what settings would be appropriate. I see RTD has a support page so it might be beneficial to send your question to them.

JHugh · 12-07-2018, 12:27 PM

I just tried both PgUp keys with CTRL-ALT-PgUp and neither worked.

I guess it's a good sign that the GUI is seeing the CTRL-ALT-F2, which means it's active.

Do you know where any error log files are located so that I can post them here and look at them to see where the problem is at?

Thanks.

MensaWater · 12-07-2018, 12:35 PM

/var/log/messages still has them in RHEL7. Also dmesg command may give some info.

RHEL7 uses systemd so there is detail you can see with "sytemctl status <service>" for specific services as with any other systemd based distro but as noted above a lot of the errors will also show up in /var/log/messages.

Note that during boot both messages and dmesg populate with a lot of information during boots - it isn't all (or even mostly) errors.

lazydog · 12-07-2018, 12:39 PM

Quote:

Originally Posted by JHugh

Thank you for the response.

I ran:

Code:

systemctl get-default

It returned:

Code:

graphical.target

So I ran:

Code:

systemctl set-default graphical.target

No need to run this as it only sets the graphical environment if it is not already set.

Quote:

I restarted the computer and it still has the same issue.

I tried hitting Ctrl-Shift-F7 and it went to a black screen and displayed the following lines:

Code:

[OK] Started crash rcovery kernel arming
[OK] Reached target multi-user system
[OK] Reached target graphical interface
[OK] Started stop read ahaead data collection 10s after completed changes
Starting update UTMP about system runlevel changes...
[OK] Started update UTMP about system runlevel changes
_

After it displays the above message, it just stops and does not do anything else, but I can still see the text cursor blinking.

I am trying to get to the gnome desktop.

Thanks again.

Have you run the other command and looked at the log file yet?

Code:

journalctl --dmesg

Quote:

Originally Posted by MensaWater

I believe your GUI is running because it is the GUI that interprets "Ctrl-Alt-F2".

Both CTRL-ALT-F# and ALT-F# work the same on a system that doesn't have a GUI installed.

MensaWater · 12-07-2018, 02:34 PM

Quote:

Originally Posted by lazydog

Both CTRL-ALT-F# and ALT-F# work the same on a system that doesn't have a GUI installed.

You're right, at least for RHEL7 based on a test I just did.

Maybe it was earlier versions of RHEL where it Ctrl-Alt-fkey wouldn't work in CLI virtual. I quit trying the Ctrl-Alt-Fkey long ago. I also typically don't use Ctrl-Alt-F1 from CLI because my KVM and my Hypervisor access are both done from a Windows workstation and Ctrl-Alt-F1 gets interpreted by Windows itself. The KVM allows me to define keystrokes to send but the Hypervisor doesn't. They've changed where the GUI lives between versions and also by default RHEL7 doesn't allow restart of GUI with Ctrl-Alt-Backspace like it did in earlier RHEL. There is a way to enable that function in RHEL7.

JHugh · 12-10-2018, 07:47 AM

Thanks.

I'm going to try to get my IT depeartment to reinstall Linux Redhat and see if that helps.

Is there anything else I could try to get the gnome desktop to work before going this route?