Not sure when it stopped working, perhaps some version of OpenRC did that. /sbin/runlevel prints "unknown" in my tests when kexec is stopped, so the stop() logic in /etc/init.d/kexec breaks ("Not rebooting, so disabling"). Apparently it is also not possible to rely on ${RC_RUNLEVEL}, which equals to "shutdown" for both shutdown and reboot in my tests. Also, if you are going to fix /etc/init.d/kexec, maybe you can implement the generic case of being able to load kexec on startup/shutdown/reboot, with different KPARAM for each. I.e., LOAD_DURING_SHUTDOWN=both KPARAM="quiet memtest=2 halt alert" KPARAM_REBOOT="quiet memtest=2" (if unset, KPARAM can be used) KPARAM_SHUTDOWN="quiet memtest=2 halt" (if unset, kexec is unloaded) The settings above are for forensic RAM wiping (kexec loaded on boot would be used on abrupt boot media removal). By the way, the design of kexec init.d is really convoluted, in my opinion. The lengths to which one has to go to just load specific kernel and initrd are quite surprising: BOOTPART=/ KNAME=usr/local/boot/kernel-kexec.zi INITRD=/usr/local/boot/initrd-kexec.xz ROOTPART=none
So if I understand you correctly, /sbin/runlevel doesn't return the correct values? Right? which version of openrc, baselayout, sys-apps/sysvinit show this behavior? Do you have any filesystem specialties for /var or /var/run? tmpfs, ro?
(In reply to comment #1) > /sbin/runlevel doesn't return the correct values? Yes, it simply returns "unknown" > which version of openrc, baselayout, sys-apps/sysvinit show this > behavior? openrc 0.9.8.4 (although it was an earlier stable version when I opened the bug) baselayout 2.0.3 sysvinit 2.88-r2 > Do you have any filesystem specialties for /var or /var/run? tmpfs, ro? Yes, the filesystem is read-only with the (relevant) exceptions of /etc, and /var. /var/run and /var/lock are symlinks into tmpfs /run. The commit message at URL below provides some background: https://github.com/mkdesu/liberte/commit/0dab02a3c6f6f88696289a3b3705b14aa98813ec I have since moved kexec kernel loading directly into shutdown/reboot wrapper scripts, so I understand if you want to close this bug due to inability to reproduce. I see now that I assumed that the reason was due to OpenRC upgrade, but perhaps the reason is a conflict of sysvinit with read-only filesystem (although that would be rather weird, since runlevel is executed before the rw branches are unmounted).
Thanks for the information. It seems to be not related directly to kexec-tools. Moving Assignie. @openrc Could you guys help to solve the broken return of runlevel?
(In reply to comment #2) > Yes, it simply returns "unknown" Just tested - simply typing "runlevel" at the console (root or otherwise) prints "unknown". The culprit is apparently the non-existing /var/run/utmp[x] on my system. So I guess that it's your call whether relying on /sbin/runlevel in /etc/init.d/kexec is generic enough. Maybe OpenRC should distinguish between shutdown and restart in RC_RUNLEVEL.
Re: /sbin/runlevel doesn't return the correct values The bug is not with /sbin/runlevel, which acts as intended (prints "unknown" if /var/run/utmp is unavailable). The issue is that kexec init.d has to depend on /sbin/runlevel to determine whether system is going for a shutdown or for a reboot. If systems without /var/run/utmp are unsupported, please close the bug as invalid. Otherwise, I think that OpenRC could provide the necessary information in the form of RC_RUNLEVEL variable (which is currently "shutdown" in both cases).
How kexec detects is another story. /sbin/runlevel is a quite central figure in a system. So it should return the correct value and all of its depended environment should be provided, like /var/run/utmp. I would think, kexec-tools are not the only ones which detect the runlevel for actions.
(In reply to comment #6) > /sbin/runlevel is a quite central figure in a system. Well, that's not entirely correct. # find / -xdev -type f -print0 | xargs -0 grep -l /sbin/runlevel /etc/init.d/kexec In addition, when /sbin/halt or its aliases (which is also from sysvinit, so probably shares code with runlevel) is invoked directly: WARNING: could not determine runlevel - doing soft halt (it's better to use shutdown instead of halt from the command line) Running /sbin/shutdown doesn't cause such a warning, however. OpenRC runlevels are also independent from those of /sbin/runlevel (e.g., rc-status -r prints "default" - seems the same as RC_RUNLEVEL in runscript). The underlying issue with /var/run/utmp is that it doesn't exist with tmpfs /run, and is created by /etc/init.d/bootmisc, which is a non-essential bookkeeping service that some users might disable (I do). If /var/run/utmp is deemed critical for system function, it should be probably created in /lib/rc/sh/init.sh.
Note also the following passage from utmp(5): Warning: utmp must not be writable by the user class "other", because many system programs (foolishly) depend on its integrity. /sbin/runlevel cannot be critical to system functioning because critical system components should not depend on the integrity of utmp database.
(In reply to comment #3) > Thanks for the information. It seems to be not related directly to kexec-tools. > Moving Assignie. > > @openrc > Could you guys help to solve the broken return of runlevel? Actually you should not be using /sbin/runlevel or $RC_RUNLEVEL to detect a reboot in openrc init scripts. Instead, you should check $RC_REBOOT. I will attach a patch for your init script that should fix the issue.
Created attachment 302531 [details] kexec-reboot.patch This patch should fix the issue. I do not use kexec-tools here, so you definitely will want to test this before you commit. William
+*kexec-tools-2.0.3-r1 (18 Mar 2012) + + 18 Mar 2012; Justin Lecher <jlec@gentoo.org> +files/kexec.conf-2.0.3, + +files/kexec.init-2.0.3, +kexec-tools-2.0.3-r1.ebuild, +files/README.Gentoo: + Use $RC_REBOOT instead of /sbin/runlevel, #401231 thanks William Hubbs for + the patch; usability enhancements including better detection of the kernel + image, additional option parsing, better descriptions in the config file, + #392229, thanks teika for those things; better detection of genkernel, + #370207, thanks Łukasz Stelmach & Dennis Schridde for their contributions +
