After the latest upgrades on my gentoo vserver system running a 3.3.0 Linux  vserver-kernel (vserver-sources-2.3.3.1), the system did not start up properly anymore. No kernel modules got loaded and even the network devices have not been available after a reboot. This is more or less the worst case, since then one has to be physically in front of the machine and can not repair the system via ssh remote login.

The kernel upgrade was not the reason for this,  but the upgrade to udev-182. This is what the log said:

Mar 21 17:20:05 mittelerde /etc/init.d/sshd[5563]: ERROR: cannot start sshd as net.eth0 would not start
Mar 21 17:20:09 mittelerde /etc/init.d/udev-mount[6075]: Udev uses a devtmpfs mounted on /dev to manage devices.
Mar 21 17:20:09 mittelerde /etc/init.d/udev-mount[6076]: This means that CONFIG_DEVTMPFS=y is required
Mar 21 17:20:09 mittelerde /etc/init.d/udev-mount[6077]: in the kernel configuration.
Mar 21 17:20:09 mittelerde /etc/init.d/udev-mount[6067]: ERROR: udev-mount failed to start
Mar 21 17:20:09 mittelerde /etc/init.d/udev[6066]: ERROR: cannot start udev as udev-mount would not start
Mar 21 17:21:06 mittelerde /etc/init.d/net.eth0[6463]: ERROR: interface eth0 does not exist

With the information “CONFIG_DEVTMPFS=y is required” the log contains the necessary hint to get things to work. The CONFIG_DEVTMPFS option had to be enabled in the kernel. Afterwards the kernel has to be recompiled. The option can be found in menuconfig under Device Drivers-> Generic Driver options and is called Maintain a devtmpfs filesystem to mount at /dev.  For getting the devfs automatically mounted at boot time it makes sense to also enable the option Automount devtmpfs at /dev, after the kernel mounted the rootfs (CONFIG_DEVTMPFS_MOUNT).

It is safe to enable these options with older udev versions. Doing so protects your system from not working any more when you get the udev update later.

Jürgen

(2 votes, average: 5.00 out of 5)

Loading...

Posted in drivers, kernel, linux | 3 Comments »

I just upgraded the vserver kernel in my test environment to 2.6.31-vs2.3.0.36.23. After rebooting the machine I recognized that the hostname of the host machine was set to the hostname of the last vserver started. Checking all vservers I found out that all had the same hostname.

A quick google search revealed, that I am not the only one having this problem: linux.derkeiler.com. But the search revealed no solution.

Afterwards I remembered that I masked util-vserver-0.30.216_pre2841 as I described in util-vserver-0.30.216_pre2841 vserver startup fails.  So I removed the mask and installed the newer version of util-vserver. Afterwards everything was normal and the vservers, as well as the host machine had the correct hostnames.

It is important to use the  version of util-vserver matching the vserver kernel version running. The vserver kernel 2.6.31-vs2.3.0.36.23 seems to work with util-vserver-0.30.216_pre2841 and the vserver-kernel 2.6.28-vserver-2.3.0.36.4 works with util-vserver-0.30.215-r3.

Jürgen

(No Ratings Yet)

Loading...

Posted in gentoo, kernel, linux | 2 Comments »

A while ago during regular upgrades my gentoo box serving as test environment for vservers updated to util-vserver-0.30.216_pre2841. Some weeks later, when I restarted the box I recognized that it could not start any vserver:

# vserver ubuntu start
vcontext: pivot_root(): Invalid argument

An error occured while executing the vserver startup sequence; when
there are no other messages, it is very likely that the init-script
(/etc/init.d/rc 3) failed.

Common causes are:
* /etc/rc.d/rc on Fedora Core 1 and RH9 fails always; the ‘apt-rpm’ build
method knows how to deal with this, but on existing installations,
appending ‘true’ to this file will help.

The box is running vserver-sources kernel 2.6.28-vs2.3.0.36.4-gentoo #2 SMP.

Since I did not find any useful information regarding his error in the web I tried downgrading to util-vserver-0.30.215-r3. For gentoo users this is accomplished by including

>sys-cluster/util-vserver-0.30.215-r3

in /etc/portage/package.mask. Afterwards everything reverted to normality.

If you also experience the “pivot_root(): Invalid argument” error, try downgrading util-vserver and hope for the best 😉

regards

Jürgen

(No Ratings Yet)

Loading...

Posted in gentoo, kernel, linux | 1 Comment »