Building an overlay image without a skeleton
RFC 1/1 Building an overlay image without a skeleton
tldr: I want to build an rootfs image that can be used as an overlay for another buildroot image.
The recent churn in skeleton handling has prompted me to post this. In particular, Thomas Petazzoni's recent comment on a skeleton thread:
Quoted 3 lines
My personal preference would be to ultimately get rid of the custom skeleton thing. We have been encouraging rootfs overlay and post-build scripts since quite a while in the Buildroot manual [...]
I've been running with a local patch whenever I use buildroot since about 5 years ago that allows me to build an image in phases. My original motivation was for a client I set up with buildroot who did not want all the developers to be building the toolchain, bootloader, kernel and os-leve portions of the image each time. Most of the devs were working on custom applications to be deployed on the board, but some others worked on the different parts of the image.
I achieved this by splitting the build into the toolchain, which used the internal buildroot toolchain but was installed externally. The other phases used this toolchain as an external toolchain.
Each of the phases builds a part of the rootfs image and each phase contains only the parts of the rootfs image relevant to that phase. The final phase uses the skeleton and overlays to combine them into a final image. The devs all share the interim overlays and the one or two devs responsible to the non-final images can build and update them as necessary when they'll next be included in the final build.
I found this phased approach to be so useful that I used it myself for my personal projects on buildroot. So I've been carrying some patches that allow me to do this, and with the recent skeleton changes and discussion, it is perhaps time to share what I've done.
Basically I've added an option, BR2_BUILD_OVERLAY_ONLY, that effectively deselects BR2_PACKAGE_SKELETON. I've wrapped parts of the skeleton makefile in ifeq ($(BR2_PACKAGE_SKELETON),y) and some other parts of the build in ifneq ($(BR2_BUILD_OVERLAY_ONLY),y).
I have another bit not part of the attached patch which is a shell script - install-overlay - that does the copying of the overlay into the target. It handles overlay directories (as the current buildroot does) as well as (compressed) tarballs and a text list of overlays that recursively applies the overlays contained in the list.
Is this something that the buildroot devs thing may be more generally useful? If the approach reasonable?
If overlays are a preferred approach over custom skeletons, perhaps some tooling to help build overlays might be useful.
One future direction I am heading (still some way off) is to use this build-overlay feature to build containers that contain just one app, but that will need some thought as to how build deps between the base and the container overlay work (as well as ldconfig stuff).
I'd appreciate your comments.
Note: I've only just updated this patch from two years ago. It seems to work with my test builds, but it is possible I've missed something.
commit 59a1720159119ca36709b6977005188355f94e57
Author: Cam Hutchison <[email protected]> Date: Fri Jul 17 09:21:17 2015 +1000
overlay: Add an option to build an overlay image.
An overlay rootfs image contains just what was built for the selected options, and excludes the skeleton and other system files placed into the rootfs. The build image is suitable to use as an overlay for another build.
Makefile +2 -0
@@ -591,6 +591,7 @@ ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y) xargs -r $(STRIPCMD) $(STRIP_STRIP_DEBUG) endif +ifneq ($(BR2_BUILD_OVERLAY_ONLY),y) mkdir -p $(TARGET_DIR)/etc # Mandatory configuration file and auxiliary cache directory # for recent versions of ldconfig
@@ -617,6 +618,7 @@ endif rsync -a --ignore-times $(RSYNC_VCS_EXCLUSIONS) \ --chmod=u=rwX,go=rX --exclude .empty --exclude '*~' \ $(d)/ $(TARGET_DIR)$(sep)) +endif @$(foreach s, $(call qstrip,$(BR2_ROOTFS_POST_BUILD_SCRIPT)), \ $(call MESSAGE,"Executing post-build script $(s)"); \
package/pkg-generic.mk +2 -0
@@ -409,9 +409,11 @@ $(2)_DEPENDENCIES ?= $$(filter-out host-skeleton host-toolchain $(1),\ $$(patsubst host-host-%,host-%,$$(addprefix host-,$$($(3)_DEPENDENCIES)))) endif ifeq ($(4),target) +ifeq ($(BR2_PACKAGE_SKELETON),y) ifneq ($(1),skeleton) $(2)_DEPENDENCIES += skeleton endif +endif ifeq ($$($(2)_ADD_TOOLCHAIN_DEPENDENCY),YES) $(2)_DEPENDENCIES += toolchain endif
package/skeleton/Config.in +1 -1
@@ -1,5 +1,5 @@ config BR2_PACKAGE_SKELETON bool - default y + default y if !BR2_BUILD_OVERLAY_ONLY help The basic skeleton for your rootfs.
package/skeleton/skeleton.mk +3 -0
@@ -7,6 +7,7 @@ # source included in buildroot SKELETON_SOURCE = +ifeq ($(BR2_PACKAGE_SKELETON),y) # The skeleton can't depend on the toolchain, since all packages depends on the # skeleton and the toolchain is a target package, as is skeleton. # Hence, skeleton would depends on the toolchain and the toolchain would depend
@@ -157,4 +158,6 @@ endif # BR2_INIT_BUSYBOX || BR2_INIT_SYSV endif # BR2_ROOTFS_SKELETON_DEFAULT +endif # BR2_PACKAGE_SKELETON + $(eval $(generic-package))
system/Config.in +19 -0
@@ -1,5 +1,22 @@ menu "System configuration" +config BR2_BUILD_OVERLAY_ONLY + bool "Build an overlay-only image" + default n + help + Build an image to use as an overlay for another build. + + Buildroot supports customizing the target root filesystem + with overlays, which are parallel directory trees overlaid + over the root filesystem that buildroot builds. + + If you select yes here, buildroot will build such an image + overlay without the skeleton parts of the image so that it + can be overlayed over a standard buildroot rootfs image. + The post-build and post-image scripts will still be run. + +if !BR2_BUILD_OVERLAY_ONLY + config BR2_TARGET_GENERIC_HOSTNAME string "System hostname" default "buildroot"
@@ -409,6 +426,8 @@ config BR2_ROOTFS_OVERLAY They are copied as-is into the rootfs, excluding files ending with ~ and .git, .svn and .hg directories. +endif # !BR2_BUILD_OVERLAY_ONLY + config BR2_ROOTFS_POST_BUILD_SCRIPT string "Custom scripts to run before creating filesystem images" default ""
toolchain/toolchain-external/toolchain-external.mk +2 -0
@@ -741,11 +741,13 @@ endef # Even though we're installing things in both the staging, the host # and the target directory, we do everything within the # install-staging step, arbitrarily. +ifneq ($(BR2_BUILD_OVERLAY_ONLY),y) define TOOLCHAIN_EXTERNAL_INSTALL_TARGET_CMDS $(TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LIBS) $(TOOLCHAIN_EXTERNAL_INSTALL_BFIN_FDPIC) $(TOOLCHAIN_EXTERNAL_INSTALL_BFIN_FLAT) $(TOOLCHAIN_EXTERNAL_FIXUP_UCLIBCNG_LDSO) endef +endif $(eval $(generic-package))
Does anyone know why this does not show up in patchwork? Too much rambling up-front? No Signed-off by?
Since I was just looking for discussion, I'm more curious that concerned. Presumably if I follow the posting patches guide in the docco, it will show up in patchwork?
Quoted 197 lines · Cam Hutchison
tldr: I want to build an rootfs image that can be used as an overlay for another buildroot image.
The recent churn in skeleton handling has prompted me to post this. In particular, Thomas Petazzoni's recent comment on a skeleton thread:
Quoted 3 lines
My personal preference would be to ultimately get rid of the custom skeleton thing. We have been encouraging rootfs overlay and post-build scripts since quite a while in the Buildroot manual [...]
I've been running with a local patch whenever I use buildroot since about 5 years ago that allows me to build an image in phases. My original motivation was for a client I set up with buildroot who did not want all the developers to be building the toolchain, bootloader, kernel and os-leve portions of the image each time. Most of the devs were working on custom applications to be deployed on the board, but some others worked on the different parts of the image.
I achieved this by splitting the build into the toolchain, which used the internal buildroot toolchain but was installed externally. The other phases used this toolchain as an external toolchain.
Each of the phases builds a part of the rootfs image and each phase contains only the parts of the rootfs image relevant to that phase. The final phase uses the skeleton and overlays to combine them into a final image. The devs all share the interim overlays and the one or two devs responsible to the non-final images can build and update them as necessary when they'll next be included in the final build.
I found this phased approach to be so useful that I used it myself for my personal projects on buildroot. So I've been carrying some patches that allow me to do this, and with the recent skeleton changes and discussion, it is perhaps time to share what I've done.
Basically I've added an option,
BR2_BUILD_OVERLAY_ONLY, that effectively deselectsBR2_PACKAGE_SKELETON. I've wrapped parts of the skeleton makefile in ifeq ($(BR2_PACKAGE_SKELETON),y) and some other parts of the build in ifneq ($(BR2_BUILD_OVERLAY_ONLY),y).I have another bit not part of the attached patch which is a shell script - install-overlay - that does the copying of the overlay into the target. It handles overlay directories (as the current buildroot does) as well as (compressed) tarballs and a text list of overlays that recursively applies the overlays contained in the list.
Is this something that the buildroot devs thing may be more generally useful? If the approach reasonable?
If overlays are a preferred approach over custom skeletons, perhaps some tooling to help build overlays might be useful.
One future direction I am heading (still some way off) is to use this build-overlay feature to build containers that contain just one app, but that will need some thought as to how build deps between the base and the container overlay work (as well as ldconfig stuff).
I'd appreciate your comments.
Note: I've only just updated this patch from two years ago. It seems to work with my test builds, but it is possible I've missed something.
commit
59a1720159119ca36709b6977005188355f94e57Author: Cam Hutchison <[email protected]> Date: Fri Jul 17 09:21:17 2015 +1000overlay: Add an option to build an overlay image.
An overlay rootfs image contains just what was built for the selected options, and excludes the skeleton and other system files placed into the rootfs. The build image is suitable to use as an overlay for another build.
Makefile +0
-0@@ -591,6 +591,7 @@ ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y) xargs -r $(STRIPCMD) $(STRIP_STRIP_DEBUG)endif
+ifneq ($(BR2_BUILD_OVERLAY_ONLY),y)
mkdir -p $(TARGET_DIR)/etc
# Mandatory configuration file and auxiliary cache directory # for recent versions of ldconfigMakefile +1
-0@@ -617,6 +618,7 @@ endif rsync -a --ignore-times $(RSYNC_VCS_EXCLUSIONS) \ --chmod=u=rwX,go=rX --exclude .empty --exclude '*~' \ $(d)/ $(TARGET_DIR)$(sep)) +endif @$(foreach s, $(call qstrip,$(BR2_ROOTFS_POST_BUILD_SCRIPT)), \ $(call MESSAGE,"Executing post-build script $(s)"); \package/pkg-generic.mk +0
-0@@ -409,9 +409,11 @@ $(2)_DEPENDENCIES ?= $$(filter-out host-skeleton host-toolchain $(1),\ $$(patsubst host-host-%,host-%,$$(addprefix host-,$$($(3)_DEPENDENCIES))))endif
ifeq ($(4),target)
+ifeq ($(BR2_PACKAGE_SKELETON),y)
ifneq ($(1),skeleton)
$(2)_DEPENDENCIES += skeleton
endif
+endif
ifeq ($$($(2)_ADD_TOOLCHAIN_DEPENDENCY),YES)
$(2)_DEPENDENCIES += toolchain
endifpackage/skeleton/Config.in +0
-0@@ -1,5 +1,5 @@config
BR2_PACKAGE_SKELETON
boolpackage/skeleton/Config.in +1
-1- default y + default y if !BR2_BUILD_OVERLAY_ONLYhelp
The basic skeleton for your rootfs.package/skeleton/skeleton.mk +0
-0@@ -7,6 +7,7 @@ # source included in buildroot
SKELETON_SOURCE=+ifeq ($(BR2_PACKAGE_SKELETON),y)
# The skeleton can't depend on the toolchain, since all packages depends on the# skeleton and the toolchain is a target package, as is skeleton. # Hence, skeleton would depends on the toolchain and the toolchain would dependpackage/skeleton/skeleton.mk +0
-0@@ -157,4 +158,6 @@ endif # BR2_INIT_BUSYBOX || BR2_INIT_SYSVendif #
BR2_ROOTFS_SKELETON_DEFAULTpackage/skeleton/skeleton.mk +2
-0+endif # BR2_PACKAGE_SKELETON +$(eval $(generic-package))
system/Config.in +0
-0@@ -1,5 +1,22 @@menu "System configuration"
system/Config.in +17
-0+config BR2_BUILD_OVERLAY_ONLY + bool "Build an overlay-only image" + default n + help + Build an image to use as an overlay for another build. + + Buildroot supports customizing the target root filesystem + with overlays, which are parallel directory trees overlaid + over the root filesystem that buildroot builds. + + If you select yes here, buildroot will build such an image + overlay without the skeleton parts of the image so that it + can be overlayed over a standard buildroot rootfs image. + The post-build and post-image scripts will still be run. + +if !BR2_BUILD_OVERLAY_ONLY +config
BR2_TARGET_GENERIC_HOSTNAME
string "System hostname"
default "buildroot"system/Config.in +2
-0@@ -409,6 +426,8 @@ config BR2_ROOTFS_OVERLAY They are copied as-is into the rootfs, excluding files ending with ~ and .git, .svn and .hg directories. +endif # !BR2_BUILD_OVERLAY_ONLY +config
BR2_ROOTFS_POST_BUILD_SCRIPT
string "Custom scripts to run before creating filesystem images" default ""toolchain/toolchain-external/toolchain-external.mk +1
-0@@ -741,11 +741,13 @@ endef # Even though we're installing things in both the staging, the host # and the target directory, we do everything within the # install-staging step, arbitrarily. +ifneq ($(BR2_BUILD_OVERLAY_ONLY),y)define
TOOLCHAIN_EXTERNAL_INSTALL_TARGET_CMDS$(TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LIBS) $(TOOLCHAIN_EXTERNAL_INSTALL_BFIN_FDPIC) $(TOOLCHAIN_EXTERNAL_INSTALL_BFIN_FLAT) $(TOOLCHAIN_EXTERNAL_FIXUP_UCLIBCNG_LDSO)endef
+endif$(eval $(generic-package))
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot