I was studied on the entry.sh in https://github.com/balena-io-library/base-images/blob/master/balena-base-images/rpi/alpine/3.10/run/entry.sh to understand what the code did. I followed how the code will flow and manually use terminal ran the code line by line.
The mount_dev function had got my attention. Anyone can tell me why need to mount --move /dev/shm, /dev/mqueue and others while executed this line
mount -t devtmpfs none “$tmp_dir”
everything from host’s /dev is already available in /tmp/tmpmount.
And, does anyone get error message “umount: /dev: target is busy” when the code executed ‘umount /dev || true’?
I am running raspberrypi OS Buster version on RPi 3B and run balenalib/raspberrypi3:buster as a container.
function mount_dev()
{
tmp_dir=’/tmp/tmpmount’
mkdir -p “$tmp_dir”
mount -t devtmpfs none “$tmp_dir”
mkdir -p “$tmp_dir/shm”
mount --move /dev/shm “$tmp_dir/shm”
mkdir -p “$tmp_dir/mqueue”
mount --move /dev/mqueue “$tmp_dir/mqueue”
mkdir -p “$tmp_dir/pts”
mount --move /dev/pts “$tmp_dir/pts”
touch “$tmp_dir/console”
mount --move /dev/console “$tmp_dir/console”
umount /dev || true
mount --move “$tmp_dir” /dev
…
}
I believe the mount_dev function and mount --move was part of something to allow /dev to stay up-to-date when running udevd in the container. I know there were some oddities to making sure new nodes were created in the containers /dev when new devices were plugged. I unfortunately don’t have the exact specifics of it, but hopefully @nghiant2710 the balenalib base images maintainer can fill in some more info for us here.
The reason for mount_dev function is we override the /dev mountpoint with a devtmpfs mount which shadows all the nice things docker mounted for us, including /dev/console, /dev/shm, /dev/mqueue and /dev/mqueue. That’s why we need to move everything to tmpmount and move them back to /dev again later.
Back to your issue, I never had that one before and I tried to reproduce in some BalenaOS versions (even the latest one) but I couldn’t reproduce it. Can you let us know more details about the environment? Also does it happen all the times or just randomly and when you hit the issue, are there any busy devices as I can happen when /dev is actually busy since we don’t umount forcefully. You can try to override the entry.sh with a non mount_dev script and see how it goes.
I see.
Sure!
I am using Rapsbian Official OS (Lite version) with Docker and Docker compose installed. Then used the Dockerfile and compose.yml as in Github (attached link on previous comment)
Pi Device used: RPi 3 model B
Raspbian OS details: OS version: Buster Lite (released 2019-09-26) Kernel version: 4.19
I used the similar Dockerfile (with buster changed to stretch) and compose.yml was working fine when I applied on host os with Stretch version. However, after I changed to getting balenalib/raspberrypi:buster and ran on the host with Buster version. I directly get the message.
Yes, it happened all the time when I turn UDEV=on on the privileged container.
I don’t think so. I didn’t mount any volume or device. I only have a keyboard and HDMI attached to my Pi. I experimented on forcefully umount and got the message too.
Please inform me if the information provided is insufficient for the investigation.
Can you brief more on the non mount_dev script, please?
Can I know what is the risks or what will be impacted if umount on /dev unsuccessful?
Hi @Shuuri, @nghiant2710 is out for holiday and he is going to be back next Wednesday in order to answer this. But as far as I know the umount failure isn’t going to affect anything because the container should tear down all the mounts if the container is removed or restarted.
@nghiant2710
[Update info] I tried to use BalenaOS as my RaspberryPi 3B+ host OS and “docker” run balenalib/raspberrypi3:buster image with privileged mode and turn UDEV=on. I also got a similar issue. Attached image capture on how I generate the umount: /dev: target is busy issue.
