Hi there, Thank you both for your time. The problem here is unrelated to the glibc upgrade issue. It is, in fact, caused by the guests' /etc/init.d/rc (and rcS) being symlink(s) to /lib/init/rc(S). As soon as I manually copied these files, I could boot the container. This brings me to the obvious question: is such a behaviour normal? Shouldn't util-vserver be able to follow the symlink? Sorry if that seems like a dumb think to ask, it's been a long time since I've dived into a guest's boot process. On a side note, the shutdown is quite messy: [info] Using makefile-style concurrent boot in runlevel 6. [FAIL] udev requires a mounted sysfs, not started ... failed! failed! [ ok ] Asking all remaining processes to terminate...done. [ ok ] All processes ended within 1 seconds...done. [ ok ] Stopping enhanced syslogd: rsyslogd. [info] Saving the system clock. hwclock: Cannot access the Hardware Clock via any known method. hwclock: Use the --verbose option to see the details of our search for an access method. [ ok ] Deconfiguring network interfaces...done. [....] Unmounting temporary filesystems...umount: /tmp: must be superuser to unmount. failed. [....] Deactivating swap...swapoff: Not superuser. failed. mount: /: permission denied. [info] Will now restart. ifdown: shutdown eth0: Operation not permitted [FAIL] startpar: service(s) returned failure: udev ... failed! I'm guessing this could be fixed by removing a few scripts from rcS.d, but shouldn't there be a cleaner way? Cheers -- Romain