Invalid argument from mkdir/install -d when using flatpak-builder on musl based distros

[Cogitri]

Linux distribution and version

Alpine Linux Edge

Flatpak-builder version

1.0.9

Flatpak version

1.6.2

Description of the problem

Building anything that calls mkdir or install -d with flatpak-builder fails when using flatpak-builder on a musl based distro, during make install this happens:

/usr/bin/mkdir -p '/app/share/man/man8'
/usr/bin/mkdir: cannot create directory ‘/app’: Invalid argument

Steps to reproduce

This can be reproduced with the following Dockerfile:

FROM alpine:edge
RUN apk add flatpak-builder
RUN flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
RUN flatpak install -y org.freedesktop.Platform/x86_64/19.08 org.freedesktop.Sdk/x86_64/19.08
RUN git clone --recursive https://github.com/A6GibKm/ch.protonmail.protonmail-bridge builder
WORKDIR builder

Build it using: docker build -t flatpak-builder . with the Dockerfile in the same dir and run it with docker container run --privileged --cap-add SYS_ADMIN --cap-add MKNOD --device /dev/fuse -it --rm flatpak-builder flatpak-builder build ch.protonmail.protonmail-bridge.yaml. The build fails with:

Running: install -Dp -m 755 apply_extra /app/bin/apply_extra
install: cannot create directory '/app': Invalid argument

[TingPing]

Its something localized to your system considering the same manifest builds on flathubs servers fine.

[Cogitri]

It appears that this happens for multiple Alpine users, so I don't think this is localized to my system - it might be to Alpine (as a host?) though. I'm not exactly sure where to dig for this though.

[TingPing]

I guess I missed the title, yeah musl or non-gnu coreutuils is likely relevant.

[Cogitri]

Doesn't it use the tooling from the flatpak SDK though?

[barthalion]

It does. The problem here is FUSE, or rather something that causes it to behave differently with musl. Build should work fine if you pass --disable-rofiles-fuse to flatpak-builder. From strace:

stat("/app/bin/apply_extra", {st_mode=S_IFREG|0755, st_size=175, ...}) = 0
mkdir("/app", 0755)                     = -1 EEXIST (File exists)
openat(AT_FDCWD, ".", O_RDONLY)         = 3</run/build/protonmail-bridge>
chdir("/app")                           = -1 EINVAL (Invalid argument)

[Cogitri]

Ah yes, it works fine with --disable-rofiles-fuse, thanks for the workaround :)

[necessarily-equal]

I also can reproduce. Note that it breaks GNOME Builder.

[Cogitri]

We'll just force-disable rofiles-fuse on Alpine for now, see https://gitlab.alpinelinux.org/alpine/aports/merge_requests/5738.

[ncopa]

I doubt it it related to musl. It is the syscall chdir that fails. Could it be a race condition? that /app is removed before chdir("/app") happens?

[Cogitri]

Hm, this has only been reproducible on Alpine Linux and Void Linux Musl for me though

[barthalion]

It's literally first creating the directory it's trying chdir into, there is no threads that could snatch that dir before it's entered. The bug exposed by musl is rather in ostree (rofiles-fuse) or FUSE itself.