Hi,

It seems that since very recently, the lxc containers for ci.debian.net
on loong64 (sid) don't mount the shared directory anymore that
autopkgtest needs and configures.

loongson@ci-worker-loong64-01:~$ sudo lxc-start --name elbrus --daemon
--define "lxc.mount.entry=/tmp/autopkgtest-lxc.xn_rqv6m 
tmp/autopkgtest-lxc.xn_rqv6m none bind,create=dir 0 0"
loongson@ci-worker-loong64-01:~$ sudo lxc-attach elbrus
root@elbrus:/# ls -al /tmp
total 0
drwxrwxrwt  6 root root 120 Oct 29 21:29 .
drwxr-xr-x 18 root root 440 Oct 29 21:29 ..
drwxrwxrwt  2 root root  40 Oct 29 21:29 .font-unix
drwxrwxrwt  2 root root  40 Oct 29 21:29 .ICE-unix
drwxrwxrwt  2 root root  40 Oct 29 21:29 .X11-unix
drwxrwxrwt  2 root root  40 Oct 29 21:29 .XIM-unix

I ran the same lxc-start command once with lxc.log.level=0, this is the
output:
loongson@ci-worker-loong64-01:~$ sudo cat /tmp/bla
#
# pseudo filter code start
#
# filter for arch loongarch64 (3221225730)
if ($arch == 3221225730)
   # filter for syscall "finit_module" (273) [priority: 65535]
   if ($syscall == 273)
     action ERRNO(1);
   # filter for syscall "open_by_handle_at" (265) [priority: 65535]
   if ($syscall == 265)
     action ERRNO(1);
   # filter for syscall "delete_module" (106) [priority: 65535]
   if ($syscall == 106)
     action ERRNO(1);
   # filter for syscall "init_module" (105) [priority: 65535]
   if ($syscall == 105)
     action ERRNO(1);
   # filter for syscall "kexec_load" (104) [priority: 65535]
   if ($syscall == 104)
     action ERRNO(1);
   # filter for syscall "umount2" (39) [priority: 65533]
   if ($syscall == 39)
     if ($a1.hi32 & 0x00000000 == 0)
       if ($a1.lo32 & 0x00000001 == 1)
         action ERRNO(13);
   # default action
   action ALLOW;
# invalid architecture action
action KILL;
#
# pseudo filter code end
#

Hi,

Weirdly enough it seems to work now.

I have a hypothesis. /tmp if on tmpfs. Normally my /var/lib/lxc is also
on tmpfs but when I tested the above, it may not have been so. Could
that be a reason why the mount failed?

Paul

control: tags -1 + moreinfo

Hi Paul,

  Have you seen this issue recur? I don't regularly run lxc containers
myself, but if tmpfs was an issue I would expect to see the issue on
other architectures.

  loong64 is still pretty new; could a new kernel have introduced a
syscall or some other change that might require an update in lxc?

Mathias

Hi Mathias,

Sorry for the day.


No, I have not. I just tried my earlier hypothesis, but I think the
hypothesis was flawed. Without /var/lib/lxc mounted on /tmp (on tmpfs)
of course the lxc-copy command did't do anything on /tmp, so what I was
thinking was non-sense.


No idea.

I propose you close this bug as unreproducible.

Paul