6:07 p.m.
>>>> "K" == Kwinten Nelissen
<kwinten.nelissen(a)gmail.com> writes:
Hi Kwinten,
we got it. Already fixed here. A disk's var FS was indeed mounted at the
wrong position in the unionfs layer. New images will be available
asap (I'll post here). Once available, running
$ apt update
$ apt dist-upgrade
on the head-node and rebooting the nodes in question should fix the
problem.
Best,
Roland
K> Hi Roland, I installed singularity in the chroot-xenial
K> environment. During the installation a directory singularity is
K> recreated in /var/lib which is required to run any image as user.
K> I started to debug the problem and it turned out that the
K> directory /var from the chroot environment is not merged with
K> /var from the image file. However when I boot a compute node as
K> diskless everything works fine.
K> Thats why I come to the conclusion that something should go wrong
K> in /lib/qlustar/disk-auto-setup
K> init_var() {
K> local var_device=$1 fstype_opt=""
K> if ! $diskless; then
K> grep -q $var_device /etc/fstab && \
K> fstype_opt="-t $(awk '$2 == "/var" {print $3}'
/etc/fstab)"
K> if ! mount $fstype_opt $var_device /mnt ; then
K> echo "Unable to mount /mnt on disk partition $var_device"
K> >&2 remove_start_links return 1
K> fi
K> # Copy ramdisk var directory on new var filesystem
K> if $force_var_copy ; then
K> cp -p -R /var/* /mnt
K> else
K> # Make sure that certain files of /var in the image are
K> # always copied to the /var on disk var device is now
K> # mounted on /mnt
K> contents_file=/etc/qlustar/contents handle_contents
K> ${contents_file} /var /mnt [ -d /var/yp ] && cp -a /var/yp
K> /mnt
K> fi
K> My guess is that here only the ramdisk is copied which is
K> normal. However after I dont see that unionfs again is
K> initialized for /var.
K> as a result I get the following when I try to singularity:
K> $singularity shell container.img ERROR : Failed to resolve path
K> to /var/lib/singularity/mnt/container: No such file or directory
K> ABORT : Retval = 255