V2, ARM and RISC-V. Works week for the Busybox builds. May need some more work on the Ubuntu/Debian builds as I have noticed some possible networking issues.
Hoping to add in Zephyr support when that’s complete.
Is it possible to invoke some of the buildroot menus like make menuconfig, make linux-menuconfig and busybox configuration menu. Also is it possible to configure for an overlay directory?
I love what you have done so far.
If you add bash to the run command (./run.sh bash ) then before the build executes, you will be dropped into the duo-buildroot-sdk(-v2) directory.
make your changes, then do ./build.sh to continue.
You could do your busybox menuconfig here. Just make sure it’s placed into the correct board config at /duo-buildroot-sdk/buildroot-2024.02/configs
or copy your config, back to my tool duo-docker-builder, and create a new profile. Note that the busybox.conf found here appends, not replaces the original config. So default settings you don’t want need to be explicitly disabled. CONFIG_XXX=n
Hi,
I have been playing around with the code and was wondering what the intention of the logic around the rootfs.tar.gz is. Is that intended to be used as an overlay, or as a skeleton, or as a complete rootfs replacement. I am wondering if I can customise the contents of certain directories /etc /mnt for example in the same way one would do using buildroot’s overlay facility.
I was also wondering if there is way of doing an incremental build. .i.e just rebuilding the rootfs without having to rerun the entire build.
Dockerfile adds this to the buildroot config.
BR2_ROOTFS_SKELETON_CUSTOM=y
BR2_ROOTFS_SKELETON_CUSTOM_PATH=
These are Debian based distros.
If you wanted to do something custom with Buszybox, take a look at the Busybox_BashSSH/post_build.sh script. This gets executed just prior to the image being built for the sd/emmc.
Create a new directory ../Busybox_Something and the menu system will find it.
Do you know if there is anyway of just rebuilding the rootfs or repackaging. If I change something in the overlay or turn on something in buildroot then I do not want to do an entire rebuild>
I have tried playing around with the build.sh script, but had little success in creating a more limited build that does not clean eveything before building. Many times the fundamental config will not change, Arm64 for SD card, for example, just some updates to packages. Any suggestions?
Yeah, the build.sh script is unlikely to help. I went down that rabbit hole too, and you have to get to grips with buildroot. The manual is here The Buildroot user manual
Tip: Google Gemini 2.5 pro is quite knowledgeable on buildroot.
I know buildroot very well and have used it for many years, but I am not sure that helps in this case because the milkv DUO use of buildroot is not at all conventional. It is wrapped in other layers that seem to override aspects of buildroots intended purpose. I use buildroot, for example, to build my raspbery PI images and there is no difficulty using skeletons and overlays for cusomization or doing partial builds. That is not possible with the DUO setup without a serious amount of tinkering.
(compile error)