Splash Screen TMP dir overwritten by tmpfs and mmdebstrap

[Chalta]

Issue Report: rpi-splash-screen layer fails when /tmp is a tmpfs mount

Repository: raspberrypi/rpi-image-gen
Component: layer/rpi/device/splash-screen

Description

The rpi-splash-screen layer fails to configure the splash image in build environments where mmdebstrap or the container runtime mounts a tmpfs filesystem over /tmp inside the chroot.

The build fails with:

Error: Splash image file not found

Root Cause
The splash-screen.yaml hook currently uses /tmp as a staging area to transfer the splash image from the Host to the Guest (Chroot):

# splash-screen.yaml
TEMP_IMAGE="/tmp/splash-screen-source.tga"
cp "$SPLASH_IMAGE" "$1$TEMP_IMAGE"  # Copies to the underlying backing store of /tmp

However, when configure-splash runs inside the chroot:

chroot $1 /usr/bin/configure-splash ... $TEMP_IMAGE

If /tmp is mounted as tmpfs (which is standard behavior for mmdebstrap and many containerized builds), the configure-splash process sees an empty RAM disk instead of the file that was copied to the underlying disk. The file is effectively "masked".

Suggested Fix

Avoid using /tmp for transferring files across the chroot boundary, as its persistence guarantees are weak in chroot/container environments.

Instead, stage the file in the root directory (/) or another persistent location (like /opt), and ensure it is removed after configuration.

Proposed Patch (splash-screen.yaml):

- TEMP_IMAGE="/tmp/splash-screen-source.tga"
+ TEMP_IMAGE="/splash-screen-source.tga"
  cp "$SPLASH_IMAGE" "$1$TEMP_IMAGE"
```

This ensures the file lands on the root filesystem, which is visible to the chroot process regardless of mount points.

[devopsbob]

I could see this happening in a container build environment. I would suggest the file might go to $1/usr/local/src/splash/splash-screen-source.tga as a transitory target.

[learmj]

While this sounds plausible, I'm wondering why I don't see it happen when using splash on x86 or arm64 builds...

If /tmp is mounted as tmpfs (which is standard behavior for mmdebstrap and many containerized builds), the configure-splash process sees an empty RAM disk instead of the file that was copied to the underlying disk. The file is effectively "masked".

...but this mount would happen at setup and the splash hook runs at customize (which is after setup)...so /tmp would be a valid location to copy to in customize hook context.

What build environment and platform are you using to run the build, and how can I reproduce this problem?

I know people have used examples/debstore/layer/debstore-installer.yaml without any problem and this too uses /tmp as an intermediate staging dir root.

There must be something else involved...

[devopsbob]

During my testings I have observed multiple orphan ram drives/devices appearing after CTL-C/breaking the build. I had to remove and reinsert the device to correctly clear the ram devices created. I would CTL-C as I found an 'oh yeah, do that too' and wanted to interupt and restart my build. I suspect the excess ramdrives would be orphans of the chroot emulations being interupted during an open semaphore or socket operation that leaves the ramdrive connected to the device. then, next or additional builds in the same session causing debstrap finding the wrong tmpfs ramdrive for the wrong image build...I am assuming the chroot somehow is creating a socket process to target the new filesystem which could be implemented as a ramdrive for indirection on file activity. I also did only see this with V1 of rpi-image-gen, didn't see it so far with v2/current branch...

[learmj]

@Chalta
I've looked at this again today. The mmdebstrap docs make specific references to /tmp, such as:

cleanup
...
Remove everything in /tmp inside the chroot.
...
"TMPDIR"
...
Since "TMPDIR" is only valid outside the chroot, the variable is being unset when running hook scripts. If you need a valid temporary directory in a hook, consider using /tmp inside your target directory.

So irrespective of anything having been mounted on /tmp, `/tmp' is a usable directory when inside the chroot.

Regarding:

If /tmp is mounted as tmpfs (which is standard behavior for mmdebstrap and many containerized builds),

This is not true. mmdebstrap does not mount /tmp as tmpfs. You can check this yourself by issuing a chroot "$@" bash in a customize hook (runs after all essential pkgs have been installed). You can then inspect the chroot from within mmdebstrap context.

Regarding containers, please can you point to the documentation for a container engine which states that /tmp is mounted as tmpfs by the container engine by default.

Docker, for example, does not:
tmpfs mounts: https://docs.docker.com/engine/storage/tmpfs/

Neither does podman:
https://docs.podman.io/en/latest/markdown/podman-run.1.html

By default /tmp is just part of the container’s writable layer (not tmpfs, and not a host bind either). To make it tmpfs, of course you can use --tmpfs /tmp (or --mount type=tmpfs,target=/tmp). Some distros/images may bind host /tmp explicitly via -v /tmp:/tmp, but that’s opt-in and not the default.

If my understanding on this is wrong, please correct me.

Even if /tmp was mounted as tmpfs by the container engine, it would be mounted before mmdebstrap execution commences, meaning that it would be valid if a hook did (1) cp foo $1/tmp or (2) chroot $1 <dostuff with /tmp>.
I'm really not seeing a scenario where having /tmp mounted as tmpfs in the chroot would cause a problem because whether it is or not is transparent to the mmdebstrap execution.

[learmj]

As of da4799a the webkiosk example uses the splash layer. I built this example by running rpi-image-gen in a container via podman where /tmp was mounted as tmpfs. I cannot reproduce the problem reported here.