Bug 7511

We need a fixed mageia-xfce-config about poweroff vs halt commands

CC: (none) => thierry.vignaud
Assignee: bugsquad => jani.valimaa
Source RPM: nvidia-current-295.71-1.mga2.nonfree.src.rpm => mageia-xfce-config

How's this related to xfce and/or mageia-xfce-config?

>Boot the system using proprietary Nvidia driver. Wait a while and try switching
>back to terminal using Strg-Alt-F1. When you get a blank screen, shutting down
>the system with a poweroff will fail.

You're mixing apples and oranges here.  If switching to a console from X gives you a totally black screen, it means that getty isn't being started dynamically on the console as it should be (otherwise you'd get a text-based login prompt).  In that case, you can type whatever you want, but nothing will be listening.

You say that icewm shuts down the GUI, but then you say that CTRL-ALT-F7 brings you back to icewm.  Which is it ?

Also, if this is cauldron, X should be starting on tty1, not tty7.

What DM are you using ?  From time to time (especially with GDM), desktops using a DM other than their own run into permission problems with shutdown/restart that results in you just logging out, i. e. the DM is still running and showing you a GUI login prompt.

CC: (none) => ftg

This bug seems to be a little bit more complicated, this is why I posted the link above to the other bugtracking system:

The main problem is that system does not reliably poweroff when shutting down. It was figured out, that this behaviour correlates with another problem (switching back to tty*)

Directly after booting it is possible to shutdown the system from X and the system is powered off as it should (everything is fine). It is also possible to switch to a console from X and of cause I get a text-based login prompt. On tty1 I can see the output of systemd (no login prompt) and on tty2 - tty3, etc. I get a text-based login prompt.

After a while (I cannot define the period better, because it varies) switching back to console regarding if tty1 or tty2, etc. shows only a blank screen, but switching back to X using CTRL-ALT-F7 still works.

When you can observe this behaviour (switching to console shows a blank screen), system will not power off anymore when shutting down system from GUI.
When trying to shutdown the X session is terminated, probably the shutdown scripts from systemd are executed as well but I cannot see (because every tty is black), but finally the system is not powered off. The fan is still running and the leds are still on soo you will have to press the power button for a long time to get the system off.

Starting the system again and looking into syslog shows the following:
...
...
Sep 18 11:30:36 sol haldaemon[5337]: Stoppen des HAL-Systemdienstes: [  OK  ]
Sep 18 11:30:36 sol xinetd[4365]: Exiting...
Sep 18 11:30:36 sol kernel: Kernel logging (proc) stopped.
Sep 18 11:30:36 sol rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="3532" x-info="http://www.rsyslog.com"] exiting on signal 15.
Sep 18 12:56:15 sol kernel: imklog 5.8.10, log source = /proc/kmsg started.
Sep 18 12:56:15 sol rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="3564" x-info="http://www.rsyslog.com"] start
Sep 18 12:56:15 sol kernel: Initializing cgroup subsys cpu
...
...

-----------------------------------------------------------------------------
@Frank
I'm using
xdm-1.1.11-5.mga2.i586.rpm
icewm-1.3.7-8.mga2.i586.rpm

It is a filly patched Mageia release 2 (Official) for i586
-----------------------------------------------------------------------------

The bugtracker mentioned above talks about "fglrx" as well, so it may be that the problem is related to proprietary display driver and not Nvidia specific.

OK, I think Thierry thought that you had been caught in the halt/poweroff controvery (halt no longer powers off, it just shuts down the OS), but if you see the black screen stuff before attempting to shut down, that can't be it.

I can't remember whether we switched from tty7 to tty1 before or after the release of MGA2.

You might try reproducing the black screen (no attempt to shut down involved), and at the black screen try ALT-SYSRQ-E or ALT-SYSRQ-I to see if it's a user-level process that is blocking things.

Also, from the blank screen, try ALT-SYSRQ-S then ALT-SYSRQ-B, and after rebooting see if syslog has anything useful.

The Ubuntu link has posts from people complaining about all sorts of symptoms, most of which match the halt/poweroff issue.

But one of them has a valid suggestion for eliminating (or targeting) the video driver as the problem - run XFdrake and disable autostart of X, then see if the problem can be reproduced.  One poster said it could, but you never know...

OK, the next test results.
When the black screen appeared again I 

first)
switched black to tty1. Pressing ALT-SYSRQ-E at the black screen the computer did some thing I could not see and then switch back to XDM Loginmanager at tty7. Tty1 to tty6 have still a black screen. This could be repeated several times without any change.

second)
switched black to tty1. Pressing ALT-SYSRQ-I at the black screen the computer did some thing I could not see and did NOT switch back to XDM Loginmanager at tty7. Now all ttys including tty7 are black.

third)
switched black to tty1. Pressing ALT-SYSRQ-S then ALT-SYSRQ-B, worked fine to reboot the system. It needed some time but finally I was back at BIOS screen without using the power button. Unfortunately the syslog did not show up anything useful after reboot. The first entry is from start of rsyslogd.

fourth)
I disabled autostart of X using XFdrake. The reboot finished on tty1 with a text-based login prompt. Login a root and starting X using /etc/init.d/dm start brings up X on tty7 while tty1 remains black with cursor in left upper corner. Tty2 to tty6 still have a text-based login prompt while I'm writing this entry. But as time of failure varies that does not imply anything. Stay tuned....

First off, were you testing without requesting shutdown ?  That is, you left the machine at the desktop display (or the XDM login display) and then found that CTRL-ALT-F1 gave you a black screen ?

re (third):
That means that your syslog was rotated.  Look for the previous one in /var/log.

re (fourth):
The idea was not to start X at all, to see if the problem occurs even if the video driver is not running.

Colin, what was the status of the tty migration in MGA2 ?  IIRC there was a time when ttys were shut off entirely in runlevel 5.  Did that happen from the get-go, or was getty knocked down late in the boot sequence ?  Could that be what he's seeing ?  Also, if getty is being launched as needed in MGA2, is there a way to check 'ps' from a terminal window that would show whether whatever is supposed to be launching it is running ?

CC: (none) => mageia

Getty's should be displayed on tty2-6 but not on tty1. X *should* start on tty1, but due to various different DMs it's entirely possible one of them will not behave properly and jump to tty7.

Just out of curiosity, you might try to reproduce it using a different DM.  The most mainstream one for Mageia is KDM.

In response to comment 8.
Yes, I was testing without requesting shutdown, I left the machine at the desktop display and found that CTRL-ALT-F1 gave you a black screen.

addition (third):
syslog was not rotated. The logfile was not emtpty only the provided information was not useful. There were not logs from shutdown process or whatever but I will try again.

addition (fourth):
I tried again without starting X and let the machine run for 2,5h without logging in or working on it. I could not reproduce it that way.

Regarding Colins comment:
Getty's are displayed on tty2-6 and not on tty1. X is probably started on tty1 but jumps to tty7, because switching back from tty to X needs CTRL-ALT-F7.

While writing this update the problem raised again:
tty1 to tty6 give a black screen and the power of monitor is switched into standby. Switching back to X monitor wakes up again and shows DM.
Looking into shows nothing special. No crash, etc.

dmesg says something about nvidia driver but I don't know if this message there by default:

NVRM: loading NVIDIA UNIX x86 Kernel Module  295.71  Thu Aug  2 19:30:55 PDT 2012
e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
e1000e 0000:00:19.0: eth0: 10/100 speed: disabling TSO
NVRM: Your system is not currently configured to drive a VGA console
NVRM: on the primary VGA device. The NVIDIA Linux graphics driver
NVRM: requires the use of a text-mode VGA console. Use of other console
NVRM: drivers including, but not limited to, vesafb, may result in
NVRM: corruption and stability problems, and is not supported.


I will try ALT-SYSRQ* again

There is a long standing issue with KDE+Nvidia driver and display power management initialisation. Could it be you're seeing this issue?

https://bugs.kde.org/show_bug.cgi?id=295814

If so an "xset -dpms" should solve it (I think)

See the cauldron ML thread "Desktop monitor powering down"

Ahh I didn't read the whole thread... the above comment is probably not relevant.

OK, so it seems linked to X.

1) Anything in Xorg.0.log ?

2) Can you use XFdrake to set your driver to xorg:vesa and see if you can reproduce ?  This will show whether the problem is X itself or the nvidia driver.

Colin, would there be anything in a systemd-related log to indicate why getty isn't being started, or a query that could be issued from a terminal window when this occurs ?

For documentation purpose:
I could solve the problem by switching from the proprietary Nvidia driver to Nouveau driver. Using that driver the system powered down reliably.
 

In meantime I switched to Mageia 3 so from my opinion this bug can be closed, either with resolved or as wont fix.

Closing per comment #15

Status: NEW => RESOLVED
Resolution: (none) => WONTFIX
Source RPM: ? => nvidia