armbian
lepotato docker build fails on MX Linux
Describe the bug
./compile.sh docker run with no changes to the kernel config and just the image with standard console interface..
The last few code updates leading up to and including the current state of the build code (git 10aeb2f30), the build fails at the point where it chroots the $SDCARD at /bin/bash at stage 2/2, although the latest code has rewritten the informational messages, I believe the error is still the same. I'm not sure why this is, I do know that MX Linux symlinks /bin to /usr/bin, why docker should have an issue with that confuses me.
To Reproduce
Run ./compile.sh docker It will reliably fail trying to chroot the $SDCARD at /bin/bash in debootstrap.sh
To make doubly certain I was not prey to config shenanigans, I stopped the docker daemon, deleted the container config, restarted the daemon and repeated the build with the same result. I was concerned that perhaps docker had been reusing the same config or was affected by an apparmor issue but that was not the case.
Provide logs: [paste of error(]https://pastebin.com/TJu21Hqz)
Try un-commenting
#DOCKER_FLAGS+=(--privileged)
in userpatches/config-docker.conf before running the script.
No change to the bug unfortunately, it's not a privileges issue. To be extra certain, i ran the build again with sudo, and the results were identical to the above error.
Can you provide logs - everything that is in output/debug folder ... and generating from scratch, delete also Docker images if any.
Currently have no clues - don't know nothing about MX Linux.
Apologies., here are most of the logs. compilation.log was too big to pastebin for me, but in all cases, the compilation isn't the issue.
output.log debootstrap-list.log potential-paths.log install.log hostdeps.log compiler.log patching.log
Hello. The build is breaking in a different place this time, we're making progress and getting a lot further, looks to just be an issue with the loop device.
looks to just be an issue with the loop device.
This is permission issue. Uncomment #DOCKER_FLAGS+=(--privileged) in the userpatche/config-docker.conf
New error seems to be an issue with the chroot in the Docker, debootstrap.sh is complaining it can't find executables like sfdisk and probably will have issues with others like losetup etc.
Please, compare Dockerfile in userpatches and config/templates.
Copy it from config/templates to userpatches if file in templates more recent.
And even if you not have to refresh dockerfile — please, remove builder docker image with command docker rmi armbian:22.11.0-trunk and let them be recreated.
This is that diff, removing fdisk doesn't seem to be a very good idea if its crashing the build at that point. I'll rebuild and let you know the result.
--- config/templates/Dockerfile 2022-09-19 15:50:02.126207499 +1000
+++ userpatches/Dockerfile 2022-09-05 19:42:27.586929150 +1000
@@ -49,7 +49,6 @@
dwarves \
f2fs-tools \
fakeroot \
- fdisk \
flex \
gawk \
gcc-aarch64-linux-gnu \
than means fdisk was added, not removed. And then change have to be activated (by docker container recreation).
Hope that should solve problem with missed sfdisk
OK now its building the temporary image fine, but docker isn't finding that loop minor device despite the configuration being set in the Dockerfile, see the debug output.
Updated the build, did a full jammy image with XFCE desktop. It's clearly failing at finding the /dev/loop0p1 and there is no difference in the docker configs.
What I find interesting is that the script failed just as badly when I built the image just for the kernel + u-boot which suggests something fundamentally wrong with your docker process. It built the rootfs just fine if I went on to attempt a second image but crashes in the same way with a single rootfs (see previous logs).
Perhaps you should use a two-stage process with docker as a useful compilation environment for kernels and build tools and use qemu for managing images so you're not messing about in dockers black box where you can't get at the devices.
@ewe2 you might wanna try the armbian-next branch. No promises, but a lot was done trying to get loop devices and binfmt working inside Docker. In the end, it still depends on how the hosts' kernel was built.
thanks, if the host kernel is a problem, what config do I need to check and reroll myself?
Ok, using armbin-next has succeeded with a minimal uboot configuration build but building even a command-line system fails with the same error. My docker has the device-cgroup-rule option so that isn't the problem. My kernel is a pretty-much standard debian one (5.17) using debian patches, its got all the BINFMT_MISC and the BLK_DEV stuff mostly in module form, so I cannot see how these are issues. I'm stumped.
It is as I suspected: I rebooted my MX system into systemd init and ran a full desktop build which ran to successful completion. Builds depend on systemd, at least for docker. This should be made clear to users. Consider this a wishlist bug perhaps.