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
-- RomainReceived on Fri Nov 8 21:19:41 2019