Bug#799115: qemu-user-static: Unsupported syscalls (sys_name_to_handle_at, sys_signalfd4) prevent booting systemd.

[Michael Tokarev]

On Tue, 15 Sep 2015 15:54:05 -0700 Ben Longbons  wrote:
> Package: qemu-user-static
> Version: 1:2.4+dfsg-2
> Severity: wishlist
> 
> Dear Maintainer,
> 
> I recently discovered systemd-nspawn and machinectl. After working
> through various bugs (try to use at least systemd 226 on the host)
> I started playing with emulated builds, but a full boot didn't work.
> 
> Note that calling systemd-nspawn *without* -b does produce a working
> shell.
[]
> Looking at the arm64 syscall list, 264 is sys_name_to_handle_at and 74 is 
> sys_signalfd4.

I looked at this, and can say it is not an easy thing to implement.

The system call is trivial to do in qemu, but the problem is that
we have to catch reads from the file descriptor returned, and
convert signalfd_siginfo structure between host and target.

That's probably why it hasn't been implemented so far.

Hwell...

/mjt

Bug#799115: qemu-user-static: Unsupported syscalls (sys_name_to_handle_at, sys_signalfd4) prevent booting systemd.

[Michael Tokarev]

Control: tag -1 + patch fixed-upstream

On Sat, 30 Jan 2016 13:02:44 +0300 Michael Tokarev  wrote:
[]
> I looked at this, and can say it is not an easy thing to implement.
> 
> The system call is trivial to do in qemu, but the problem is that
> we have to catch reads from the file descriptor returned, and
> convert signalfd_siginfo structure between host and target.
> 
> That's probably why it hasn't been implemented so far.

Actually it HAS been implemented, in commit:

commit e36800c91a74b656b4b4c74483863950cf9ec202
Author: Laurent Vivier 
Date:   Fri Oct 2 14:48:09 2015 +0200

linux-user: add signalfd/signalfd4 syscalls

This patch introduces a system very similar to the one used in the kernel
to attach specific functions to a given file descriptor.

In this case, we attach a specific "host_to_target()" translator to the fd
returned by signalfd() to be able to byte-swap the signalfd_siginfo
structure provided by read().


Which has been applied upstream after 2.5 version.
I'll include it in debian once 2.6 will be out.  Hopefully no
backporting of large stuff will be needed.

Thanks,

/mjt

Bug#799115: qemu-user-static: Unsupported syscalls (sys_name_to_handle_at, sys_signalfd4) prevent booting systemd.

[Michael Tokarev]

Control: found -1 1:2.5+dfsg-1

With 2.5 upstream version, name_to_handle_at has been implemented.
But not signalfd4.

So it is still impossible to run systemd using qemu linux-user
emulation.

(And no, 2.5 is still not out, I'm just marking bugs which are
present in 2.5).

Thanks,

/mjt

Bug#799115: qemu-user-static: Unsupported syscalls (sys_name_to_handle_at, sys_signalfd4) prevent booting systemd.

[Michael Tokarev]

Control: tag -1 + confirmed upstream

16.09.2015 01:54, Ben Longbons wrote:
> Package: qemu-user-static
> Version: 1:2.4+dfsg-2
> Severity: wishlist
> 
> Dear Maintainer,
> 
> I recently discovered systemd-nspawn and machinectl. After working
> through various bugs (try to use at least systemd 226 on the host)
> I started playing with emulated builds, but a full boot didn't work.

Thank you very much for this detailed bugreport.

Unfortunately yes, as you discovered, a few syscalls aren't implemented
in qemu-user (it is a general problem, syscall implementation isn't
arch-specific, it is done in a common source file).  And new ones are
added in linux all the time.

> Looking at the arm64 syscall list, 264 is sys_name_to_handle_at and 74 is 
> sys_signalfd4.

Yes, neither of these two syscalls are imlemented in upstream qemu.
It shouldn't be difficult to implement, but as usual it all boils
down to available time and the "amounf of need" in something ;)
Maybe some day...

Out of curiocity, why do you want systemd-nspawn with a foreign
chroot?

Thanks,

/mjt

Bug#799115: qemu-user-static: Unsupported syscalls (sys_name_to_handle_at, sys_signalfd4) prevent booting systemd.

[Ben Longbons]

Package: qemu-user-static
Version: 1:2.4+dfsg-2
Severity: wishlist

Dear Maintainer,

I recently discovered systemd-nspawn and machinectl. After working
through various bugs (try to use at least systemd 226 on the host)
I started playing with emulated builds, but a full boot didn't work.

Note that calling systemd-nspawn *without* -b does produce a working
shell.

# cd /var/lib/machines
# arch=arm64
# qemu-debootstrap --arch=$arch jessie jessie_$arch
< snip lots of output>
# systemd-nspawn -bD jessie_$arch
Spawning container jessie_arm64 on /var/lib/machines/jessie_arm64.
Press ^] three times within 1s to kill container.
Failed to create directory /var/lib/machines/jessie_arm64/sys/fs/selinux: 
Read-only file system
Failed to create directory /var/lib/machines/jessie_arm64/sys/fs/selinux: 
Read-only file system
/etc/localtime is not a symlink, not updating container timezone.
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
qemu: Unsupported syscall: 264
systemd 215 running in system mode. (+PAM +AUDIT +SELINUX +IMA +SYSVINIT 
+LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR)
Detected virtualization 'systemd-nspawn'.
Detected architecture 'arm64'.

Welcome to Debian GNU/Linux 8 (jessie)!

Set hostname to .
qemu: Unsupported syscall: 74
Failed to allocate manager object: Function not implemented
^]^]
Container jessie_arm64 terminated by signal KILL.

Looking at the arm64 syscall list, 264 is sys_name_to_handle_at and 74 is 
sys_signalfd4.

The same bug occurs with arm64, armel, armhf, mips, mipsel, ppc64el, s390s
(though the syscall numbers vary of course).

I did not test amd64 or i386 because my host is amd64 and I'm not aware
of any way to force qemu emulation on the native architecture.

It is possible that there are additional unimplemented syscalls that do
not get called until after the above succeed.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (600, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, powerpc, arm64, armhf

Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

qemu-user-static depends on no packages.

Versions of packages qemu-user-static recommends:
ii  binfmt-support  2.1.5-1

Versions of packages qemu-user-static suggests:
ii  sudo  1.8.12-1

-- no debconf information