Mystery Image Remains On Screen After Shutdown - ?

I am having a problem with shutdown leaving an image on the screen. Does anyone know what this image represents or what causes it to be displayed?

https://drive.google.com/file/d/0B_VF5IlGClYFQTNMRFNxUVdHc0U/view?usp=sharing

Specs are openSuSE 42.3, kernel 4.4.79-19, nvidia driver 384.69-25.1

The image is your least problem. Something is delaying shut down and it is certainly not the image.
Hit escape and look what is causing the delay.
.:wink:

To me it looks if you want support for this. This will be moved to Install/Boot/Login and is CLOSED for the moment.

Moved from Looking for somethjing other yhen support and open again.

What you see is the shutdown. And it should of course not take that long.

Like @swannema said, hit the Esc key to see were it hangs.

ESC (or any other key) has no effect whatsoever. The machine seems to be down - sort of. The disks are off, but the fans are on and the machine’s power LED is lit. The display is showing the image, but without any animation of the green dots. R-S-E-I-U-B, ctrl-alt-del, ctrl-F1, etc. do nothing. Pressing the machine’s power button causes immediate power off.

Try hitting the Esc (not any other key) key as early as possible in the shutdown sequence (maybe repeat it).

I get the feeling that the whole shutdown runs OK until it comes to the power off. For some reason that is not done.

Yes, that is how it appears to me too. This is a picture of the last screen image:

https://drive.google.com/file/d/0B_VF5IlGClYFQTNMRFNxUVdHc0U/view?usp=sharing

Do you (or anyone else) know what process (or program) causes it to be displayed?

As explained earlier, that image is normal during shutdown.

But did you try to hit the Esc key as early as possible in the shutdown process? Maybe hit it a few times immediatly after you started shutdow, so that you do not miss the opportunity.

Perhaps the OP is not understanding how ESC works. It may be easier for him to remove the splash=silent and/or quiet boot options, so all text messages will show both during boot and shutdown (AFAIK). Maybe doing this at the boot screen won’t influence shutdown, so in his place I’d go to YAST > Bootloader > Kernel Parameters Tab and delete the text above from the optional kernel parameters field. He can always put it back later.

The correct key sequence for the tty1 VT is: <Ctrl + Alt + F1>.

  • Login as the user “root” and then “systemctl poweroff”. Alternatively “systemctl rescue” to shut down to single user mode and begin to troubleshoot the issue.

You may also consider enabling the “SysRq” keys – YaST – Kernel Setup. The “SysRq” key is the “Prt Scrn Sys Rq” key.

  • Regain control of the keyboard and mouse: <Alt + SysRq + r>
  • System shutdown and power off: <Alt + SysRq + o>

SysRq needs to be enabled, and the correct sequence would be:
Alt-SysRq-r e i s u b

SysRq is actually enabled by default, but with some options disabled, such as the “o” and the “b” options, for obvious reasons.

To fully enable, simply drop to a terminal and issue:

su -

enter the root pw, then:

echo 1 > /proc/sys/kernel/sysrq

then

logout

then

exit

Hi Gerry

I was interested in your steps to fully enable “the magic SysRq” for Alt-SysRq-r e i s u b. After doing it, i confirmed apparent success:


gooeygirl@linux-sr0s:~> **cat /proc/sys/kernel/sysrq**

**1**
gooeygirl@linux-sr0s:~> 

I rebooted, repeated the above cat, & was dismayed to see it had reverted to 0. I repeated the whole process, verified the above again showed 1, rebooted… once more it was back to 0.

How can it be made permanent please?

You can define the necessary (eg kernel.sysrq = 1) in /etc/sysctl.conf, or a .conf file in the /etc/sysctl.d/ directory

To get current settings do

sysctl --system

Reference: ‘man systctl’…

--system
              Load settings from all system configuration files.
              /boot/sysctl.conf-<kernelversion>
              /run/sysctl.d/*.conf
              /etc/sysctl.d/*.conf
              /usr/local/lib/sysctl.d/*.conf
              /usr/lib/sysctl.d/*.conf
              /lib/sysctl.d/*.conf
              /etc/sysctl.conf

Hmmm. That is a recent change (recent as in I think that was introduced with Leap versions) … but again for a good reason, as it is a risk in several situations.

… but, Deano has answered that already, thanks Deano.

Thanks Deano & Gerry

You can define the necessary (eg kernel.sysrq = 1) in /etc/sysctl.conf, or a .conf file in the /etc/sysctl.d/ directory

I’ve spent many hours on this today, testing researching & coming to some degree of understanding. I found:

1. Creating a .conf file in /etc/sysctl.d/ did not work. Given i had successfully previously done in this Maui Linux prior to my conversion months ago to oS TW, today i “borrowed & repurposed” my old Maui file file; /etc/sysctl.d/10-magic-sysrq.conf:


# The magic SysRq key enables certain keyboard combinations to be
# interpreted by the kernel to help with debugging. The kernel will respond
# to these keys regardless of the current running applications.
#
# In general, the magic SysRq key is not needed for the average Ubuntu
# system, and having it enabled by default can lead to security issues on
# the console such as being able to dump memory or to kill arbitrary
# processes including the running screen lock.
#
# Here is the list of possible values:
#   0 - disable sysrq completely
#   1 - enable all functions of sysrq
#  >1 - enable certain functions by adding up the following values:
#          2 - enable control of console logging level
#          4 - enable control of keyboard (SAK, unraw)
#          8 - enable debugging dumps of processes etc.
#         16 - enable sync command
#         32 - enable remount read-only
#         64 - enable signalling of processes (term, kill, oom-kill)
#        128 - allow reboot/poweroff
#        256 - allow nicing of all RT tasks
#
#   For example, to enable both control of console logging level and
#   debugging dumps of processes: kernel.sysrq = 10
# #
# 3/9/17: openSUSE Tumbleweed default in /proc/sys/kernel/sysrq = 184
#However 184 only enables S U B. By my deduction to enable REISUB, atop existing TW options, need 252.
kernel.sysrq = 252


Unfortunately after rebooting, despite that new file, /proc/sys/kernel/sysrq remained at 184, & in tty i confirmed that R E I remained disabled, with only S U B being enabled & functional.

2. Conversely, this is very successful: adding this instead to* /etc/sysctl.conf:*


#
# Magic SysRq REISUB:
# 3/9/17: openSUSE Tumbleweed default in /proc/sys/kernel/sysrq = 184
#However 184 only enables S U B. By my deduction to enable REISUB, atop existing TW options, need 252.
kernel.sysrq = 252

After rebooting, /proc/sys/kernel/sysrq now showed 252, & in tty i confirmed that each of R E I S U B is now enabled & functional.

3. FYI, based on today’s research & testing, this pic from my little working spreadsheet shows how i deduced my 252 :
https://paste.opensuse.org/images/35014126.png

I’ve spent many hours on this today, testing researching & coming to some degree of understanding. I found:

1. Creating a .conf file in /etc/sysctl.d/ did not work.

If you run ‘sysctl --system’ it will show you the order that the settings were applied. The naming is important. I found that in order to override settings in /usr/lib/sysctl.d/50-default.conf, my configuration file in /etc/sysctl.d/ needed to be named something like 80-custom.conf (or similar) so that it was processed after the default configuration…

linux-kgxs:/home/dean # sysctl --system
* Applying /boot/sysctl.conf-4.4.79-19-default ...
kernel.hung_task_timeout_secs = 0
kernel.msgmax = 65536
kernel.msgmnb = 65536
kernel.shmmax = 0xffffffffffffffff
kernel.shmall = 0x0fffffffffffff00
* Applying /usr/lib/sysctl.d/50-coredump.conf ...
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e
* Applying /usr/lib/sysctl.d/50-default.conf ...
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.all.promote_secondaries = 1
net.ipv6.conf.default.use_tempaddr = 1
fs.inotify.max_user_watches = 65536
kernel.sysrq = 184
dev.cdrom.autoclose = 0
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
kernel.kptr_restrict = 1
* Applying /etc/sysctl.d/80-custom.conf ...
kernel.sysrq = 252
* Applying /etc/sysctl.d/99-sysctl.conf ...
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0
* Applying /etc/sysctl.conf ...
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0

linux-kgxs:/home/dean # cat /proc/sys/kernel/sysrq
252

Ah, deano, thank you… the penny has finally dropped for me:

in order to override settings in /usr/lib/sysctl.d/50-default.conf, my configuration file in /etc/sysctl.d/ needed to be named something like 80-custom.conf (or similar) so that it was processed after the default configuration…

I failed to grasp the significance of your earlier clue to me, when you referred me to the man page [which i [i]did read then], but now your additional expansion & example has hit the mark for me. This now nicely lets me see why my prior attempts with creating my /etc/sysctl.d/10-magic-sysrq.conf didn’t work… they must have been clobbered each time by the subsequent default as this list’s sequence shows:


gooeygirl@linux-Tower:~> sysctl --system
Absolute path to 'sysctl' is '/usr/sbin/sysctl', so running it may require superuser privileges (eg. root).
gooeygirl@linux-Tower:~> **sudo sysctl --system**
[sudo] password for root: 
* Applying /boot/sysctl.conf-4.12.9-1-default ...
kernel.hung_task_timeout_secs = 0
kernel.msgmax = 65536
kernel.msgmnb = 65536
kernel.shmmax = 0xffffffffffffffff
kernel.shmall = 0x0fffffffffffff00
vm.dirty_ratio = 20
*** Applying /etc/sysctl.d/10-magic-sysrq.conf ...**
* Applying /usr/lib/sysctl.d/50-coredump.conf ...
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e
*** Applying /usr/lib/sysctl.d/50-default.conf ...**
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.all.promote_secondaries = 1
net.ipv6.conf.default.use_tempaddr = 1
fs.inotify.max_user_watches = 65536
**kernel.sysrq = 184**
dev.cdrom.autoclose = 0
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
kernel.kptr_restrict = 1
* Applying /etc/sysctl.d/99-sysctl.conf ...
net.ipv6.conf.all.disable_ipv6 = 1
vm.swappiness = 1
vm.vfs_cache_pressure = 50
kernel.sysrq = 252
*** Applying /etc/sysctl.conf ...**
net.ipv6.conf.all.disable_ipv6 = 1
vm.swappiness = 1
vm.vfs_cache_pressure = 50
**kernel.sysrq = 252**
gooeygirl@linux-Tower:~> 



So [if i am now understanding properly], the reason my pc now does boot eventually to my desired 252, is that despite my ***/etc/sysctl.d/10-magic-sysrq.conf ***being almost immediately “undone” by ***/usr/lib/sysctl.d/50-default.conf ***, that in turn later gets overturned by my /etc/sysctl.conf , in which i recently appended the important line “kernel.sysrq = 252”.

Clearly now i should tidy up my arrangement… either rename my /etc/sysctl.d/10-magic-sysrq.conf to have a number larger than 50, then remove that appended line from /etc/sysctl.conf
—OR—
Retain /etc/sysctl.conf as-is, & delete my /etc/sysctl.d/10-magic-sysrq.conf

Is either method regarded as superior / preferred over the other, pls?

Yes, I had just assumed that /etc/sysctl.d/ config files would override those in /usr/lib/sysctl.d/ to be honest.

So [if i am now understanding properly], the reason my pc now does boot eventually to my desired 252, is that despite my ***/etc/sysctl.d/10-magic-sysrq.conf ***being almost immediately “undone” by ***/usr/lib/sysctl.d/50-default.conf ***, that in turn later gets overturned by my /etc/sysctl.conf , in which i recently appended the important line “kernel.sysrq = 252”.

Yes, and easily determined from ‘sysctl --system’ as you now know.:slight_smile:

Clearly now i should tidy up my arrangement… either rename my /etc/sysctl.d/10-magic-sysrq.conf to have a number larger than 50, then remove that appended line from /etc/sysctl.conf
—OR—
Retain /etc/sysctl.conf as-is, & delete my /etc/sysctl.d/10-magic-sysrq.conf

Is either method regarded as superior / preferred over the other, pls?

Either approach will work.