To improve the configuration of hprofile <http://hprofile.sf.net> (which I wrote), and in general to make the use of config profiles (as controlled via RC_USE_CONFIG_PROFILES) more flexible, I would like a mechanism to set the DEFAULTLEVEL variable not only from the kernel command line, but also during the execution of the "boot" runlevel. The advantage of this would be that a script executed from the "boot" runlevel could determine the profile based on the current state of the system (in my example, it would have to detect whether Gentoo was started from the normal dualboot configuration, or within VMWare for windows; other uses may be if the machine was booted in a docking station or not, whether a particular network connection could be made, etc.). Hence, an appropriate runlevel could be detected and selected automatically, negating the need to have multiple options in the GRUB or LILO menu. From my initial analysis of /sbin/functions.sh and /sbin/rc, I think the easiest way for this to happen would be if the get_bootconfig() function in /sbin/functions.sh would check a file called, say, ${svcdir}/defaultlevel for the name of the default runlevel if the "softlevel" option was not set in /proc/cmdline, and set the newsoftlevel variable to this. Reproducible: Always Steps to Reproduce: N/A
I had another look and noticed I could set the runlevel to be started after boot by putting its name in /var/init.d/ksoftlevel. I created another 'boot' runlevel service which determines the correct runlevel, and writes the name of this to /var/init.d/ksoftlevel (effectively overwriting the value of ${DEFAULTLEVEL} from setup_defaultlevels(), which is stored in that file when /sbin/rc is called with the 'boot' option). This appears to work, but is it safe? Or is it simply a side-effect of the current implementation of /sbin/rc (which seems to use /var/init.d/ksoftlevel as a temporary store for the ${DEFAULTLEVEL} variable). Or put differently, is ksoftlevel intended to be used in this way? If not, why not? I also discovered that the simple modification requested above probably wouldn't work, because the setup_defaultlevels() function is only called when the 'boot' runlevel is first entered, so any modification that depends on services started during 'boot' would not have a chance to affect it.
tracing old bugs here. i'm pretty certain this functionality is present in the system now, since you filed this bug in 2003. if not, please reopen.
