[systemd-devel] Requirements for successful mounting of RootImage?

[Lennart Poettering]

On So, 30.07.17 13:58, Topi Miettinen (toiwoton at gmail.com) wrote:

> Hey,
> 
> I have this test.service unit:
> [Unit]
> 
> [Install]
> WantedBy=multi-user.target
> 
> [Service]
> Type=oneshot
> ExecStart=/bin/ls -lR
> RootImage=/fs
> MountAPIVFS=no

Any reason you turn this off? This is likely to break sooner or later,
so it would make a ton of sense to test things first with it left on,
before checking anything else.

> 
> The file /fs has a MBR partition table:
> Disk /dev/loop0: 1.1 MiB, 1192960 bytes, 2330 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x3990f3e6
> 
> Device       Boot Start   End Sectors  Size Id Type
> /dev/loop0p1 *       34  2329    2296  1.1M 83 Linux

That should work. See if "systemd-nspawn -i" can get a shell in it. If
so, RootImage= should work too, it uses the same code.

Also, consider invoking /usr/lib/systemd/systemd-dissect on the image
file, it will tell you whether it can make sense of the image, and how
it would mount it.

> In the only partition a squashfs file system containing:
> bin
> bin/ls
> boot
> dev
> etc
> etc/group
> etc/nsswitch.conf
> etc/passwd
> home
> lib
> lib64
> lib64/ld-linux-x86-64.so.2
> lib/libc.so.6
> lib/libdl.so.2
> lib/libpcre.so.3
> lib/libpthread.so.0
> lib/libselinux.so.1
> media
> opt
> proc
> root
> run
> sbin
> srv
> sys
> tmp
> usr
> usr/bin
> usr/lib
> usr/lib64
> usr/lib/x86_64-linux-gnu
> usr/sbin
> var
> var/tmp
> 
> However, starting the service fails with abort:
> Jul 30 13:25:42 machine systemd[1]: Starting test.service...
> Jul 30 13:25:42 machine kernel:  loop0: p1
> Jul 30 13:25:42 machine systemd[1]: test.service: Main process exited,
> code=killed, status=6/ABRT
> Jul 30 13:25:42 machine systemd[1]: Failed to start test.service.
> Jul 30 13:25:42 machine systemd[1]: test.service: Unit entered failed state.
> Jul 30 13:25:42 machine systemd[1]: test.service: Failed with result
> 'signal'.
> 
> It looks like systemd successfully mounts the file system, but then
> suddenly aborts before even looking inside the file system:
> 
> 2761  mount("/dev/loop1p1", "/run/systemd/unit-root", "squashfs",
> MS_NODEV, NULL <unfinished ...>
> 2761  <... mount resumed> )             = 0
> 2761  rt_sigprocmask(SIG_UNBLOCK, [ABRT],  <unfinished ...>
> 2761  <... rt_sigprocmask resumed> NULL, 8) = 0
> 2761  rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
> 2761  getpid( <unfinished ...>
> 2761  <... getpid resumed> )            = 2761
> 2761  gettid( <unfinished ...>
> 2761  <... gettid resumed> )            = 2761
> 2761  tgkill(2761, 2761, SIGABRT <unfinished ...>
> 2761  <... tgkill resumed> )            = 0
> 2761  rt_sigprocmask(SIG_SETMASK, [],  <unfinished ...>
> 2761  <... rt_sigprocmask resumed> NULL, 8) = 0
> 2761  --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=2761,
> si_uid=0} ---
> 2761  +++ killed by SIGABRT +++
> 
> The file system can be mounted by hand with losetup and mount, and
> /bin/ls can be run from chroot. So I think everything should be OK but
> RootImage still does not work and the error messages are useless.
> Perhaps I miss some RootImage requirements? What exactly they are?

They are documented briefly in "systemd-nspawn's" --image= setting.

That said, if systemd actually mounted something, then the image is
fine. Most likely something is simply borked in the namespacing code,
and that is kind hard to debug, because logging is already turned off
at that point. It should be relatively easy to patch that in
temporarily though, i.e. find apply_mount_namespace() in
src/core/execute.c and place a log_open() before the setup_namespace()
invocation, and check if this improves logging for you.

Lennart

-- 
Lennart Poettering, Red Hat