Docker: load kernelmodules: loop, binfmt_misc

[rpier1]

The loop kernelmodule is needed, otherwise the script export-image/prerun.sh fails in this line

pi-gen/export-image/prerun.sh

Line 42 in f8f3d6f

BOOT_DEV=$(losetup --show -f -o "${BOOT_OFFSET}" --sizelimit "${BOOT_LENGTH}" "${IMG_FILE}")

with the message

losetup: /pi-gen/work/2020-01-08-Raspbian/export-image/2020-01-08-Raspbian-lite.img: failed to set up loop device: No such file or directory

See also: #320 (comment)

So this is a fix for #320

(I suggest you pull my previous pull-request first, in order to reduce the commits in this pull request from 2 to 1. [This pr is based on the previous one])

[rpier1]

By the way: I've verified that missing loop really is the problem; and that loading loop really does fix it.
I reproduced it and checked it multiple times.

[rpier1]

Unfortunately, this also assumes loop as kernel module.
So this pull-request has the same issue as was mentioned here: #372 (comment)

[rpier1]

But I think we can check it inside the debian docker container, i.e.
change this line

pi-gen/build-docker.sh

Line 95 in f8f3d6f

cd /pi-gen; ./build.sh ${BUILD_OPTS} &&

to

cd /pi-gen; ./docker_module_checks && ./build.sh ${BUILD_OPTS} && 

There you see a new call ./docker_module_checks and that could have code such as

function check_kernelmodule_loaded {
    local kernelMod="$1"
    local fail=0
    if ! $SUDO modinfo $kernelMod &>/dev/null; then
        # module missing
        fail=1
    else
        if $SUDO modprobe -n --first-time $kernelMod &>/dev/null; then
            # module not loaded
            fail=1
        fi
    fi
    if [[ $fail == 1 ]]; then
        echo "missing this kernel modul: $kernelMod. Please load it in your host (on debian like this: sudo modprobe $kernelMod)"
        exit 1
    fi
}


check_kernelmodule_loaded loop
check_kernelmodule_loaded binfmt_misc

So the code running in the container will fail, if the module is not loaded.

Any thoughts? (Thanks)

[rpier1]

But I think we can check it inside the debian docker container, i.e.

At least when running on Debian host, I know that it works, because I've seen that within the running container, loop is only loaded, if it is also loaded in the debian host.

I'm not entirely certain of the behaviour, when the host is not debian. Does anybody know?

[rpier1]

Reading up on this a bit, I don't think it will work.

[samtygier]

Not having loop module loaded could explain why #257 still gives me intermittent issues. I guess my attempts to debug it each time tend to cause the module to get loaded, and then it works. I was beginning to suspect it only happened the first time after a reboot.

Docker uses the host kernel. I am not sure what happens if the guest tries to load a module that the host kernel has built in.

I wonder if a safe way to load it would be to create a dummy image file, attach it with losetup, and then detach it. So you could check lsmod, if loop is not there then use losetup to trigger loading the module. This could be done in build-docker.sh.

[rpier1]

I guess my attempts to debug it each time tend to cause the module to get loaded, and then it works. I was beginning to suspect it only happened the first time after a reboot.

Correct. this is exactly the behaviour!
Without loop, my builds always failed the 1st time after a reboot, but the 2nd time I saw that loop magically got loaded automatically (somehow).

[der-eismann]

Since the docker build is especially made to be run on other distros like Fedora & CentOS this should be taken into consideration here. So please also support rpm or ignore OSes other than Ubuntu & Debian.

[samtygier]

I've seen the failure now even with the loop module loaded in the host. Running losetup --list once in the host seems to help though. Maybe just having

losetup --list > /dev/null

in build-docker.sh would work.

[edurenye]

With this branch the error still appears in Ubuntu 20.04