The sys-apps/baselayout-1.13.0_alpha12 has some issues related to vservers. Those were solved by hollow, last march [1]. Attached you'll find a bumped baselayout, which contains hollow's patch [2]. It would be nice if this could go into the official portage. Thanks, Chris [1] http://archives.linux-vserver.org/200703/0141.html [2] http://people.linux-vserver.org/~hollow/baselayout-1.13.0-gentoo-init-style-fixes.patch Reproducible: Always
Created attachment 125921 [details] baselayout-1.13.0_alpha12-r1 with vps patch
Created attachment 125923 [details, diff] hollow's VPS patch
These have already been incorporated into baselayout-2, which is in portage.
please use baselayout-2
Thanks for your feedback. I've installed sys-apps/baselayout-2.0.0_alpha4 within the vserver. While starting I get the following error message: [...] * Mounting local filesystems ... [ ok ] FATAL: Could not load /lib/modules/2.6.20-vs2.2.0-gentoo/modules.dep: No such file or directory * Activating (possible) swap ... [ ok ] [...] After digging around within the various init scripts, I figured out, that the above message comes form /etc/init.d/localmount. On line 57 the modprobe command gets called. However vservers aren't allowed to load kernel modules, therefore no modules.dep file will be around. I fixed this issue by replacing line 56 from: if [ -f /proc/modules -a ! -d /proc/bus/usb ] ; then to: if [ "${RC_SYS}" != "VPS" -a -f /proc/modules -a ! -d /proc/bus/usb ] ; then However is it really necessary to perform the whole localmount start() function on vservers? Per default vservers don't have the capability to mount filesystems. Furthermore the stop() function also skips unmounts within vservers. I also encountered another issue while trying to stop a vserver with vserver [name] stop: [...] * Stopping syslog-ng ... [ ok ] WARNING: could not determine runlevel - doing soft halt (it's better to use shutdown instead of halt from the command line) shutdown: timeout opening/writing control channel /dev/initctl init: timeout opening/writing control channel /dev/initctl /usr/lib/util-vserver/vserver.stop: line 83: 14077 Killed "${NICE_CMD[@]}" $_VCONTEXT $SILENT_OPT --migrate --chroot --xid "$S_CONTEXT" -- "${INITCMD_STOP[@]}"
> I also encountered another issue while trying to stop a vserver with vserver > [name] stop: > [...] > * Stopping syslog-ng ... [ ok ] > WARNING: could not determine runlevel - doing soft halt > (it's better to use shutdown instead of halt from the command line) > shutdown: timeout opening/writing control channel /dev/initctl > init: timeout opening/writing control channel /dev/initctl > /usr/lib/util-vserver/vserver.stop: line 83: 14077 Killed > "${NICE_CMD[@]}" $_VCONTEXT $SILENT_OPT --migrate --chroot --xid "$S_CONTEXT" > -- "${INITCMD_STOP[@]}" Please ignore the above, it seems that my previous update overwrite the vserver specific /etc/init.d/shutdown.sh and /etc/init.d/reboot.sh scripts.
If vservers cannot load modules then they should not expose /proc/modules
> If vservers cannot load modules then they should not expose /proc/modules A program within the vserver could still be interested in what modules are loaded on the carrier system.
it should definitely not be interested in hardware stuff at all.. that's the whole point about vservers being host (i.e. hardware) agnostic...
OK, regardless of /proc/modules... Wouldn't it make sense to skip the /etc/init.d/localmount start() function at the beginning? This would be the same behavior as in the stop() function and would solve the initial problem.
no, it would not make sense because there are cases were you need to mount inside (openvz) or want to mount inside (vserver's secure_mount), but for both of them all mounts automagically disappear once the guest is shutdown, so stop() can be skipped always...
and btw, this is only a cosmetic bug... i will look if we can remove /proc/modules from the default unhide list ...
Plus a few other things happen in localmount like swap activation and kernel core dump recovery. And only the host system should care about what modules it has loaded, the vserver should not.
it won't be fixed upstream, some other guest distros need it, and it's only a cosmetic bug ... you can still hide the /proc/modules manually
*** Bug 201736 has been marked as a duplicate of this bug. ***
