网站建设中企动力,dw网页制作登录页面步骤,net域名大网站,无锡自助建网站Linux之buildroot(4)配置项目
Author#xff1a;Onceday Date#xff1a;2023年12月3日
漫漫长路#xff0c;才刚刚开始…
全系列文章请查看专栏: buildroot编译框架_Once_day的博客-CSDN博客。
参考文档#xff1a;
Buildroot - Making Embedded Linux Easy 文章目录…Linux之buildroot(4)配置项目
AuthorOnceday Date2023年12月3日
漫漫长路才刚刚开始…
全系列文章请查看专栏: buildroot编译框架_Once_day的博客-CSDN博客。
参考文档
Buildroot - Making Embedded Linux Easy 文章目录 Linux之buildroot(4)配置项目1.自定义项目1.1 推荐目录结构1.2 buildroot外部树(br2-external)1.2.1 external.desc文件1.2.2 Config.in和external.mk1.2.3 configs目录1.2.4 provides目录1.2.5 其他内容 1.3 保存配置(savedefconfig)1.4 保存软件包的配置1.5 定制目标文件系统1.6 设置文件权限和归属1.7 设置自定义用户1.8 镜像后处理操作1.9 提供patch补丁文件1.10 提供hash文件1.11 添加自定义包1.12 操作快速指南 2. 杂项问题2.1 NFS引导镜像启动2.2 Live CD引导镜像启动 3. 附加信息3.1 fakeroot介绍3.2 序列补丁文件(series files)3.3 NFS-boot引导3.4 Live CD启动 1.自定义项目
对于给定的项目可能需要执行的典型操作有: 配置Buildroot如构建选项(build options)和工具链(toolchain)、引导加载程序(bootloader)、内核(kernel)、包(package)和文件系统映像类型(filesystem image type)。 配置其他组件如Linux内核和BusyBox。 定制生成的目标文件系统(target filesystem)。 (1) 在目标文件系统(target filesystem)上添加或覆盖文件(使用BR2_ROOTFS_OVERLAY)。 (2) 修改或删除目标文件系统(target filesystem)上的文件(使用BR2_ROOTFS_POST_BUILD_SCRIPT)。 (3) 在生成文件系统映像之前运行任意命令(使用BR2_ROOTFS_POST_BUILD_SCRIPT)。 (4) 设置文件权限和所有权(使用BR2_ROOTFS_DEVICE_TABLE)。 (5) 添加自定义设备节点(使用BR2_ROOTFS_STATIC_DEVICE_TABLE)。 添加自定义用户帐户(使用BR2_ROOTFS_USERS_TABLES)。 生成文件系统映像后运行任意命令(使用BR2_ROOTFS_POST_IMAGE_SCRIPT)。 向某些包添加特定于项目的补丁(使用BR2_GLOBAL_PATCH_DIR)。 添加特定项目的包一般是自编写的程序应用。
关于此类特定项目的自定义如果是对其他开发者也非常有益的配置Buildroot社区强烈建议并鼓励向官方Buildroot项目提供改进、软件包和主板支持。
本章描述了如何在builroot中进行这些特定项目的自定义以及如何以一种可重复的方式存储它们即使在运行make clean之后也可以构建相同的映像。通过遵循推荐的策略甚至可以使用相同的Buildroot树来构建多个不同的项目!
1.1 推荐目录结构
在为项目自定义builroot时将创建一个或多个需要存储在某处的特定项目文件。虽然它们的路径可以在Buildroot配置中指定但Buildroot开发人员建议使用本节中描述的特定目录结构。与此目录结构不同你可以选择将此目录放置在任意位置如在Buildroot树中或者使用br2-external树。
简单来说就是目录结构最好是固定的树结构但目录存放的位置可以任意自定义一般都是采用br2-external外部这样可以保持buildroot内部树结构的干净。外部树(br2-external)结构一般如下:
-- board/
| -- company/
| -- boardname/
| -- linux.config
| -- busybox.config
| -- other configuration files
| -- post_build.sh
| -- post_image.sh
| -- rootfs_overlay/
| | -- etc/
| | -- some files
| -- patches/
| -- foo/
| | -- some patches
| -- libbar/
| -- some other patches
|
-- configs/
| -- boardname_defconfig
|
-- package/
| -- company/
| -- Config.in (if not using a br2-external tree)
| -- company.mk (if not using a br2-external tree)
| -- package1/
| | -- Config.in
| | -- package1.mk
| -- package2/
| -- Config.in
| -- package2.mk
|
-- Config.in (if using a br2-external tree)
-- external.mk (if using a br2-external tree)
-- external.desc (if using a br2-external tree)如果选择将此结构置于Buildroot树之外即在br2-external树中则company和boardname组件可能是多余的可以省略。
一个用户有几个相关的项目部分需要相同的定制这是很常见的。建议使用分层自定义方法而不是为每个项目重复这些自定义。几乎所有在builroot中可用的自定义方法如构建后脚本(post-build scripts)和根文件系统覆盖(root filesystem overlays)都接受空格分隔的项列表。
指定的项总是按从左到右的顺序处理。通过创建多个这样的项一个用于公共定制另一个用于真正特定项目的定制可以避免不必要的重复。每一层通常由board/company/中的一个单独的目录体现甚至可以引入两个以上的层。
一个用户有两个自定义层common和fooboard的目录结构示例如下:
-- board/-- company/-- common/| -- post_build.sh| -- rootfs_overlay/| | -- ...| -- patches/| -- ...|-- fooboard/-- linux.config-- busybox.config-- other configuration files-- post_build.sh-- rootfs_overlay/| -- ...-- patches/-- ...例如如果用户将BR2_GLOBAL_PATCH_DIR配置选项设置为:
BR2_GLOBAL_PATCH_DIRboard/company/common/patches board/company/fooboard/patches首先应用来自组件层的补丁(board/company/common/patches)。
然后是来自fooboard层的补丁(board/company/fooboard/patches)。
关于具体的br2-external树例子可以参考官方manual手册9.2.1.7 Example layout内容挺多就不复制过来了。
1.2 buildroot外部树(br2-external)
可以将特定项目的自定义文件放置在两个位置:
直接在Buildroot树中通常使用版本控制系统中的分支来维护它们以便很容易升级到较新的Buildroot版本。在Buildroot树之外使用br2-external机制。这种机制允许将包配置(package recipes)、板支持(boadr support)和配置文件保存在Buildroot树之外同时仍然将它们很好地集成在构建逻辑中这个位置称为为buildroot外部树(br2-external tree)。
通过将BR2_EXTERNAL (make变量)设置为要使用的br2-external树的路径可以告诉builroot使用一个或多个br2-external树。它可以传递给任何Buildroot make调用并且会自动保存在输出目录(output/)的隐藏文件.br2-external.mk中因此不需要在每次make调用时都传递BR2_EXTERNAL的值。不过它可以在任何时候通过传递一个新值来更改也可以通过传递一个空值来删除。
br2-external树的路径可以是绝对路径也可以是相对路径。如果它作为相对路径传递请务必注意它是相对于主Buildroot源目录而不是Buildroot输出目录进行解释的。
例如可以通过以下命令指定br2-external树的路径:
$ make BR2_EXTERNAL/path/foo menuconfig
$ make legal-info # 这个时候, 会使用/path/foo中的br-external树
$ make BR2_EXTERNAL/path/newfoo xconfig # 这个时候, 会使用/path/newfoo中的br-external树如下可以同时指定多个br2-external树的路径:
$ make BR2_EXTERNAL/path/foo:/path/newfoo menuconfig如下可以关闭所有br2-external树的路径 $ make BR2_EXTERNAL xconfig一个br2-external树必须至少包含这三个文件
external.desc external.mk Config.in除了这些强制文件之外br2-external树中可能还有其他可选的内容比如configs/或providers/目录。
1.2.1 external.desc文件
该文件描述了br2-external树: 该br2-external树的名称(name)和描述(description)。
该文件的格式是基于行的每行以一个关键字(keyword)开头后跟一个冒号和一个或多个空格然后是分配给该关键字的值。目前可识别的关键字有两个: Name(必选)定义br2-external树的名称。该名称只能使用集合[A-Za-z0-9_]中的ASCII字符禁止使用其他字符。builroot将变量BR2_EXTERNAL_$(NAME)_PATH设置为br2-external树的绝对路径这样就可以使用它来引用br2-external树。这个变量在Kconfig中可用因此可以使用它来获取Kconfig文件也可以在Makefile中使用它来包含其他Makefile文件或者从br2-external树中引用其他文件(如数据文件)。 由于可以同时使用多个br2-external树因此builroot使用此名称为每个树生成变量。该名称用于标识对应的br2-external树因此请尝试想出一个真正描述该br2-external树的名称以便它相对唯一这样它就不会与另一个br2-external树的名称冲突特别是如果计划以某种方式与第三方共享br2-external树或使用来自第三方的br2-external树。 Desc(可选)它提供了br2-external树的简短描述。它应该适合单行大部分是自由格式的并且在显示关于br2-external树的信息时使用(例如在defconfig文件列表上方或者在menuconfig中提示); 因此它应该相对简短(40个字符可能是一个不错的上限)。该描述在BR2_EXTERNAL_$(NAME)_DESC变量中可用。
下面是一个示例说明:
br2-external名字 BR2_EXTERNAL_$(NAME)_PATH值FOO BR2_EXTERNAL_FOO_PATHBAR_42 BR2_EXTERNAL_BAR_42_PATHBR2_EXTERNAL_$(NAME)_PATH和BR2_EXTERNAL_$(NAME)_DESC在Kconfig文件和Makefiles中都是可用的。它们也在环境中导出因此可以在构建后(post-build)、镜像后(post-image)和fakeroot脚本(in-fakeroot)中使用。
1.2.2 Config.in和external.mk
这些文件(可能每个都是空的)可以用来定义包配置(例如foo/Config.in和foo/foo.mk)或其他自定义配置选项或make逻辑。
builroot自动包含Config.in。从每个br2-external树中取出external.mk使其出现在顶层配置菜单中并将每个br2-external树中的external.mk与其余的makefile逻辑一起包含在内。
主要用途是存储包配置。推荐的方法是编写一个Config.in在文件中如下填写(external树里自定义包的配置):
source $BR2_EXTERNAL_BAR_42_PATH/package/package1/Config.in
source $BR2_EXTERNAL_BAR_42_PATH/package/package2/Config.inexternal.mk的内容如下所示(通配符自动读取也可以直接写明绝对路径来获取):
include $(sort $(wildcard $(BR2_EXTERNAL_BAR_42_PATH)/package/*/*.mk))然后在$(BR2_EXTERNAL_BAR_42_PATH)/package/package1和$(BR2_EXTERNAL_BAR_42_PATH)/package创建正常的Buildroot包配置。如果愿意还可以将包分组到名为boardname的子目录中并相应地调整上述路径也可以在Config.in中定义自定义配置选项在external.mk中自定义make逻辑。
1.2.3 configs目录
可以在br2-external树的configs子目录中存储builroot的defconfigs(生成的默认配置文件)。
builroot将自动在make list-defconfigs的输出中显示它们并允许使用正常的make name_defconfig命令加载它们。它们将在make list-defconfigs输出中可见位于External configs标签下方该标签包含定义它们的br2-external树的名称。
如果defconfig文件存在于多个br2-external树中则使用最后一个br2-external树中的defconfig文件。因此可以覆盖绑定在builroot或其他br2-external树中的defconfig。
1.2.4 provides目录
对于某些包builroot提供了两种(或更多)与api兼容的实现之间的选择。例如可以选择libjpeg或jpeg-turbo或者openssl和libressl之间选择一个。
br2-external可以通过提供一组定义这些选择的文件来扩展这些选择:
provides/toolchains.in定义预配置的工具链然后在工具链选择中列出。provides/jpeg.in定义了libjpeg的替代实现。provides/openssl.in定义了可选的openssl实现。provides/skeleton.in定义了可选的骨架实现。provides/init.in在定义可选的初始化系统实现时可以使用它为初始化选择默认框架。
1.2.5 其他内容
可以将所有特定于主板的配置文件存储在那里例如内核配置(kernel configuration)、根文件系统覆盖层(root filesystem)或者Buildroot允许设置位置的任何其他配置文件(通过使用BR2_EXTERNAL_$(NAME)_PATH变量)。
例如可以设置全局补丁目录、rootfs覆盖目录和内核配置文件的路径如下所示(运行make menuconfig并填写这些选项):
BR2_GLOBAL_PATCH_DIR$(BR2_EXTERNAL_BAR_42_PATH)/patches/
BR2_ROOTFS_OVERLAY$(BR2_EXTERNAL_BAR_42_PATH)/board/boardname/overlay/
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE$(BR2_EXTERNAL_BAR_42_PATH)/board/boardname/kernel.config还可以在br2-external树根目录下的linux/目录里添加额外的Linux内核扩展内容。
1.3 保存配置(savedefconfig)
可以使用命令make savedefconfig来存储builroot配置。
这通过删除默认值的配置选项来剥离builroot配置。结果存储在一个名为defconfig的文件中。如果想将其保存在另一个地方请更改Buildroot配置本身中的BR2_DEFCONFIG选项或者使用如下命令:
make savedefconfig BR2_DEFCONFIGpath-to-defconfig存储这个defconfig的推荐位置是configs/boardname_defconfig。如果你遵循这个建议配置将在make list-defconfigs中列出并且可以通过命令make boardname_defconf重新设置或者可以将文件复制到任何其他位置并使用下面命令重构:
make defconfig BR2_DEFCONFIGpath-to-defconfig1.4 保存软件包的配置
BusyBox、Linux kernel、Barebox、U-Boot和uClibc的配置文件如果更改了也应该存储起来。对于每一个组件都有一个builroot配置选项指向一个输入配置文件例如BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE。为了存储它们的配置将这些配置选项设置为想要保存配置文件的路径然后使用下面描述的命令来实际存储配置。建议存放这些配置文件的路径如下:
board/company/boardname/foo.config确保在更改BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE等选项之前创建了一个配置文件。否则builroot将尝试访问这个配置文件它还不存在并且会失败。可以通过命令make linux-menuconfig创建配置文件。
通过软件包配置buildroot可以额外支持make xxx-menuconfig目标用来配置指定软件包以下是内建支持的软件包
make linux-update-defconfig保存Linux配置到BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE路径文件里。make busybox-update-config保存busybox配置到BR2_PACKAGE_BUSYBOX_CONFIG路径文件里。make uclibc-update-config保存uClibc配置到BR2_UCLIBC_CONFIG路径文件里。make barebox-update-defconfig保存barebox配置到BR2_TARGET_BAREBOX_CUSTOM_CONFIG_FILE路径文件里。make uboot-update-defconfig保存U-Boot配置到BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE路径文件里。
1.5 定制目标文件系统
除了通过make *config更改配置之外还有一些其他方法可以定制生成的目标文件系统。推荐的两种方法是根文件系统覆盖和构建后脚本它们可以共存
1) Root filesystem overlays (BR2_ROOTFS_OVERLAY)文件系统覆盖层是一个文件树在构建目标文件系统之后直接复制到目标文件系统上。要启用此功能将配置选项BR2_ROOTFS_OVERLAY(在System configuration菜单中)设置为overlay的根目录。可以指定多个覆盖以空格分隔。
如果指定一个相对路径它将相对于Buildroot树的根。版本控制系统的隐藏目录(如.git.svn.hg).empty空文件和以~结尾的文件被排除在拷贝之外。
当启用BR2_ROOTFS_MERGED_USR时覆盖层必须不包含/bin/lib或/sbin目录因为builroot会将它们创建为指向/usr中相关文件夹的符号链接。在这种情况下如果覆盖层有任何程序或库它们应该放在/usr/bin、/usr/sbin和/usr/lib中。
(2) Post-build scripts (BR2_ROOTFS_POST_BUILD_SCRIPT)构建后脚本是在buildrot构建所有选定软件之后但在组装rootfs映像之前调用的shell脚本。要启用此功能请在配置选项BR2_ROOTFS_PoST_BUILD(在系统配置菜单中)中指定一个以空格分隔的构建后脚本列表。如果指定一个相对路径它将相对于Buildroot树的根。
使用构建后脚本可以删除或修改目标文件系统中的任何文件。但是应该谨慎使用此功能。每当发现某个包生成错误或不需要的文件时应该修复该包而不是使用一些构建后清理脚本来解决它。该脚本的推荐路径如下:
board/company/boardname/post_build.sh运行后构建脚本时将主Buildroot树作为当前工作目录。目标文件系统的路径作为每个脚本的第一个参数传递。如果配置选项BR2_ROOTFS_POST_SCRIPT_ARGS不为空这些参数也将传递给脚本。所有脚本都将被传递完全相同的参数集不可能向每个脚本传递不同的参数集。此外还可以使用下面这些环境变量:
BR2_CONFIGbuildroot配置文件.config的路径。CONFIG_DIR包含.config文件的目录对应顶级buildroot Makefile使用的配置文件(对于树内和树外构建都是正确的)。HOST_DIR, STAGING_DIR, TARGET_DIR分别对应全局host、staging、target目录路径。BUILD_DIR软件包实际源文件和编译目录。BINARIES_DIR存储所有二进制文件(又名映像)的位置。BASE_DIR基本输出目录。
下面将描述另外三种定制目标文件系统的方法但不推荐使用。
(1) Direct modification of the target filesystem对于临时修改可以直接修改目标文件系统并重新构建映像。目标文件系统在output/target/下可用。在进行更改之后运行make来重新构建目标文件系统映像。
该方法允许对目标文件系统执行任何操作但是如果需要使用make clean清理Buildroot树那么这些更改将丢失。这种make clean在一些情况下是必要的因此此解决方案仅对快速测试有用: 更改无法在make clean命令下存活。一旦验证了更改应该确保它们在make clean(使用根文件系统覆盖或构建后脚本)之后将持续存在。
(2) Custom target skeleton (BR2_ROOTFS_SKELETON_CUSTOM)根文件系统映像是从目标框架创建的所有包都在其上安装它们的文件。在构建和安装任何包之前文件框架(skeleton)被复制到目标目录output/target。默认的目标框架提供标准的Unix文件系统布局和一些基本的初始化脚本和配置文件。
如果默认框架(在system/skeleton下可用)不符合需求通常会使用根文件系统覆盖或构建后脚本来调整它。但是如果默认框架与需要的框架完全不同那么使用自定义框架可能更合适。
要启用此特性请启用配置选项br2_rootfs_skeleton并将BR2_ROOTFS_SKELETON_CUSTOM设置为自定义框架的路径。这两个选项在System configuration菜单中都可用。如果指定一个相对路径它将相对于Buildroot树的根目录。
自定义框架不需要包含/bin、/lib或/sbin目录因为它们是在构建过程中自动创建的。当启用BR2_ROOTFS_MERGED_USR时自定义框架必须不包含/bin、/lib或/sbin目录因为builroot会将它们创建为指向/usr中相关文件夹的符号链接。在这种情况下如果框架有任何程序或库它们应该放在/usr/bin、/usr/sbin和/usr/lib中。
不推荐使用这种方法因为它会复制整个框架这会妨碍利用在以后的builroot版本中对默认框架所做的修复或改进。
(3) Post-fakeroot scripts (BR2_ROOTFS_POST_FAKEROOT_SCRIPT)当聚合最终映像时该过程的某些部分需要root权限:在/dev中创建设备节点设置文件和目录的权限或所有权。为了避免需要实际的根权限builroot使用fakeroot来模拟根权限。这并不能完全替代实际的root身份但足以满足Buildroot的需要。
Post-fakeroot scripts脚本是在fakeroot阶段结束时调用的shell脚本就在调用文件系统映像生成器之前。因此它们在fakeroot上下文中被调用。如果您需要调整文件系统以进行通常只有root用户才能进行的修改那么Post-fakeroot脚本可能非常有用。
建议使用现有的机制来设置文件权限或在/dev中创建条目或创建用户。 post-build脚本和fakeroot脚本的区别在于post-build脚本不会在fakeroot上下文中调用。
使用fakeroot并不能完全替代实际的root身份。Fakeroot只获取文件访问权限和类型(常规、块或字符设备…)以及uid/gid这些是在内存中模拟的。
1.6 设置文件权限和归属
添加自定义设备节点有时需要在文件或设备节点上设置特定的权限或所有权。例如某些文件可能需要由root拥有。由于后构建脚本不是以root身份运行的因此不能从那里进行此类更改除非在后构建脚本中使用显式的fakeroot。
相反builroot提供了对所谓的权限表的支持。要使用此特性请将配置选项BR2_ROOTFS_DEVICE_TABIE设置为一个以空格分隔的权限表列表即遵循makedev语法的常规文本文件。如果使用的是静态设备表(即不使用devtmpfs、mdev或eudev)那么可以使用相同的语法在所谓的设备表中添加设备节点。要使用此特性请将配置选项BR2_ROOTFS_STATIC_DEVICE_TABLE设置为一个以空格分隔的设备表列表。
这些文件的推荐位置是board/company/boardname/。应该注意的是如果特定的权限或设备节点与特定的应用程序相关则应该在包的.mk文件中设置变量FOO_PERMISSIONS和FOO_DEVICES。
makedev语法通常形式如下(可在buildroot maunal手册第25章中浏览详细描述):
name type mode uid gid major minor start inc count
/dev/hda b 640 root root 3 1 1 1 151.7 设置自定义用户
有时需要在目标系统中添加特定的用户。为了满足这一需求builroot提供了对所谓用户表的支持。要使用此特性请将配置选项BR2_ROOTFS_USERS_TABLES设置为一个以空格分隔的用户表列表即遵循makeusers语法的常规文本文件。
这些文件的推荐位置是board/company/boardname/。应该注意的是如果自定义用户与特定的应用程序相关则应该在包的.mk文件中设置变量FOO_USERS。
makeusers语法通常形式如下(可在buildroot maunal手册第26章中浏览详细描述)
username uid group gid password home shell groups comment
foo -1 bar -1 !blabla /home/foo /bin/sh alpha,bravo Foo user1.8 镜像后处理操作
在构建文件系统映像、内核和引导加载程序之前可以运行后构建(post-build)脚本但在创建所有映像之后还可以使用后镜像(post-image)脚本执行一些特定的操作。
例如后镜像脚本可用于自动提取NFS服务器导出位置中的根文件系统tarball或创建一个特殊的固件映像将根文件系统和内核映像捆绑在一起或用于项目所需的任何其他自定义操作。
要启用此功能请在配置选项BR2_ROOTFS_POST_IMAGE_SCRIPT(在系统配置菜单中)中指定一个以空格分隔的后映像脚本列表。如果指定一个相对路径它将相对于Buildroot树的根目录。就像后期构建脚本一样后期镜像脚本以主Buildroot树作为当前工作目录运行。
镜像输出目录(output/images)的路径作为每个脚本的第一个参数传递。如果配置选项BR2_ROOTFS_POST_SCRIPT_ARGS不为空这些参数也将传递给脚本。所有脚本都将被传递完全相同的参数集不可能向每个脚本传递不同的参数集。同样就像构建后脚本一样脚本可以访问环境变量BR2_CONFIG、HOST_DIR、STAGING_DIR、TARGET_DIR、BUILD_DIR、BINARIES_DIR、CONFIG_DIR和BASE_DIR。
后镜像(post-image)脚本将作为执行builroot的用户执行通常不应该是根用户。因此在这些脚本中任何需要root权限的操作都需要特殊处理(使用fakeroot或sudo)这将留给脚本开发人员。
1.9 提供patch补丁文件
在builroot中提供的补丁之上有时对包应用额外的补丁是有用的。例如这可能用于支持项目中的自定义特性或者在处理新体系结构时。BR2_GLOBAL_PATCH_DIR配置选项可用于指定包含包补丁的一个或多个目录的空格分隔列表。
对于特定包package name的特定版本 packag version 补丁从BR2_GLOBAL_PATCT应用如下: 首先尝试BR2_GLOBAL_PATCH_DIR定义的全局补丁目录(可有多个)即global-patch-dir中确定package-patch-dir目录。 (1) 如果global-patch-dir/package name/package version/目录存在该目录作为package-patch-dir目录。 (2) 否则尝试使用global-patch-dir/packagename目录作为package-patch-dir目录。 然后尝试使用package-patch-dir目录下的补丁。 (1) 如果包目录中存在序列补丁文件(series files)则按照系列文件的顺序应用补丁; (2) 否则*.patch文件将按字母顺序应用补丁。因此为了确保它们以正确的顺序应用强烈建议将补丁文件命名为: number-description.patch # 其中number指的是应用顺序BR2_GLOBAL_PATCH_DIR选项是为包指定自定义补丁目录的首选方法。它可用于为built_root中的任何包指定补丁目录。它还应该用来代替自定义补丁目录选项这些选项可用于U-Boot和Barebox等软件包。通过这样做它将允许用户从一个顶层目录管理他们的补丁。
除了BR2_GLOBAL_PATCH_DIR是指定自定义补丁的首选方法之外也可用BR2_LINUX_KERNEL_PATCH来指定在URL上可用的内核补丁。BR2_LINUX_KERNEL_PATCH指定在BR2_GLOBAL_PATCH_DIR中可用的补丁之后应用的内核补丁因为它是从Linux包的补丁后钩子(post-patch)完成的。
1.10 提供hash文件
builroot捆绑了一个哈希列表根据它来检查下载存档的完整性或者从VCS签出本地生成的完整性。然而它只能对已知的版本这样做对于可以指定自定义版本的包(例如自定义版本、远程tarball URL或VCS存储库位置和变更集)builroot不能为这些包携带哈希值。
对于关心此类下载完整性的用户可以提供一个哈希列表Buildroot可以使用它来检查任意下载的文件。这些额外的哈希与上面的额外补丁相似。
对于BR2_GLOBAL_PATCH_DIR中的每个目录第一个存在的文件用于检查包下载:
global-patch-dir/packagename/packageversion/packagename.hashglobal-patch-dir/packagename/packagename.hash
utils/add-custom-hashes脚本可用于生成这些文件。
1.11 添加自定义包
通常任何新包都应该直接添加到包目录中并提交给builroot上游项目。项目可能需要一些专有的软件包而这些软件包不能被上游化因此这些特定项目的包需要保存在特定项目的目录中
项目特定包的推荐位置是package/company/。如果正在使用br2-external树特性建议将它们放在br2-external树中名为package/的子目录中。
但是除非执行一些额外的步骤否则buildrot将不会知道这个位置中的包。在Buildroot中的包基本上由两个文件组成.mk文件(描述如何构建包)和一个Config.in文件(描述这个包的配置选项)。
builroot会自动将.mk文件包含在包目录的第一级子目录中(使用模式匹配package/*/*.mk)。如果我们想要Buildroot从更深的子目录(如package/company/packagel)中包含.mk文件只需要在第一级子目录中添加一个.mk件其中包括这些额外的内层.mk文件。因此创建一个package/company/company.mk中包含以下内容(假设在package/company/下面只有一个额外的目录级别):
include $(sort $(wildcard package/company/*/*.mk))对于Config.in文件创建一个package/company/Config.in其中包括在所有软件包中的Config.in文件。由于kconfig的源命令中不支持通配符因此必须提供详尽的列表。例如:
source package/company/package1/Config.in
source package/company/package2/Config.in1.12 操作快速指南
前面已经描述了进行自定义项目的不同方法。本节将通过提供存储自定义项目的分步操作说明来总结所有这些内容。 make menuconfig配置toolchainpackages和kernel。 make linux-menuconfig更新Linux内核配置其他工具busybox/uclibc都可以类似操作。 mkdir -p board/manufacturer/boardname创建自定义项目的目录。 board/manufacturer/boardname/package.config在该文件里配置一下参数(如果用到的话)。 BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE
BR2_PACKAGE_BUSYBOX_CONFIG
BR2_UCLIBC_CONFIG
BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_CONFIG_FILE
BR2_TARGET_BAREBOX_CUSTOM_CONFIG_FILE
BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE执行make xxx-config写入对应软件配置到步骤4中指定配置文件中去如下: make linux-update-defconfig
make busybox-update-config
make uclibc-update-config
cp output/build/at91bootstrap3-*/.config board/manufacturer/boardname/at91bootstrap3.config
make barebox-update-defconfig
make uboot-update-defconfig创建目录board/manufacturer/boardname/rootfs-overlay/然后按需填充该目录例如添加etc/inittab文件。同时需要把BR2_ROOTFS_OVERLAY变量值设置为该目录。 创建post-build脚本board/manufacturer/boardname/post_build.sh同时设置BR2_ROOTFS_POST_BUILD_SCRIPT值为该脚本的路径。 如果必须设置额外的setuid权限或必须创建设备节点请创建board/manufacturer/boardname/device_table.txt并将该路径添加到BR2_ROOTFS_DEVICE_TABLE中。 如果需要添加自定义的用户账户请创建board/manufacturer/boardname/users_table.txt并添加该路径到BR2_ROOTFS_USERS_TABLES中。 BR2_GLOBAL_PATCH_DIR设置为board/manufacturer/boardname/patches/并在以包命名的子目录中为每个包添加补丁。每个补丁应该命名为packagename-num-description.patch。 特别是对于Linux内核还存在BR2_LINUX_KERNEL_PATCH选项其主要优点是它也可以从URL下载补丁。如果不需要首选BR2_GLOBAL_PATCH_DIR。UBoot, Barebox, at91bootstrap和at91bootstrap3也有单独的选项但这些没有提供任何优于BR2_GLOBAL_PATCH_DIR的优势将来可能会被删除。 如果需要添加特定项目的包请创建package/manufacturer/并将包放在该目录中。创建一个整体manufacturer.mk文件包含所有包的.mk文件。创建一个整体Config.in文件并包含所有包的Config.in文件。在Buildroot的package/Config.in文件里包含这个整体Config.in文件。 make savedefconfig保存以上定制的buildroot配置。 cp defconfig configs/_defconfig拷贝该配置文件到预期目录中保存起来。
2. 杂项问题
2.1 NFS引导镜像启动
要实现nfs引导在filesystem images菜单中启用tar root filesystem。完成构建后只需运行以下命令来设置NFS-root目录:
sudo tar -xavf /path/to/output_dir/rootfs.tar -C /path/to/nfs_root_dir记得把这个路径添加到/etc/exports然后可以从目标执行NFS-boot。
2.2 Live CD引导镜像启动
要构建live CD映像请在Filesystem images菜单中启用iso image选项。请注意此选项仅在x86和x86-64体系结构上可用且使用builroot构建内核。
可以使用IsoLinux、Grub或Grub 2作为引导加载程序来构建live CD映像但是只有IsoLinux支持将该映像既可用作live CD又可用作live USB(通过构建混合映像(hybrid image)选项)。
可以使用QEMU测试live CD映像:
Qemu-system-i386 -cdrom output/images/rootfs.iso9660或者使用它作为一个硬盘驱动器镜像如果它是一个混合的ISO:
Qemu-system-i386 -hda output/images/rootfs.iso9660它可以很容易地用dd保存到USB驱动器:
Qemu-system-i386 -hda output/images/rootfs.iso96603. 附加信息
3.1 fakeroot介绍
Fakeroot 是一个 Linux 工具它允许用户执行一些需要 root 权限的操作尽管用户实际上并没有 root 权限。它通过提供一个虚假的 root 环境来达到这个目的使得在这个环境中的命令行操作看起来好像是由 root 用户执行的。
Fakeroot 通过拦截系统调用并修改相关的返回值来工作让调用者认为他们具有真正的 root 权限。例如一个普通用户通常无法更改只读文件的所有者但在 fakeroot 环境中用户可以执行此操作尽管实际上并未发生改变。
Fakeroot 的一个常见用途是在软件包制作过程中。许多 Linux 发行版的软件包管理系统要求软件包文件和目录拥有特定的所有者和权限。使用 fakeroot包维护者可以创建看似具有这些所有者和权限的文件和目录然后将它们打包成一个软件包。这样用户在安装软件包时就会看到正确的所有者和权限。
简单的使用示例如下
fakeroot bash # 进入一个新的 bash shell该 shell 会提供一个虚假的 root 环境在此环境中用户可以执行需要 root 权限的命令例如 chown 和 chmod。
尽管 fakeroot 可以模拟 root 用户的行为但它并不能提供真正的 root 权限。如果用户试图执行真正需要 root 权限的操作例如安装全局软件或更改系统文件这些操作将会失败。
此外fakeroot 也不会提供任何额外的安全或隔离。所有在 fakeroot 环境中执行的操作都是在用户的实际权限下进行的。所以fakeroot 不应被视为一种安全工具或用于沙箱环境。
3.2 序列补丁文件(series files)
在 Linux 和 Unix 系统中series 文件通常用于描述一系列补丁的应用顺序。这个文件通常存在于用于源代码包管理的情况尤其是在 Slackware Linux 发行版及其衍生版本中。
series 文件位于 /patches 目录中其中列出的每一行通常代表一个补丁文件。在构建过程中这些补丁会按照在 series 文件中的顺序被逐个应用到源代码上。
这是一个简单的 series 文件示例
patch1.diff
patch2.diff
patch3.diff在这个例子中patch1.diff 补丁会首先被应用然后是 patch2.diff 和 patch3.diff。这样可以确保补丁以正确的顺序被应用特别是当某些补丁依赖于其他补丁的情况下。
注意series 文件并不是所有 Linux 或 Unix 系统都会使用它主要出现在一些特定的源代码包管理环境中。
3.3 NFS-boot引导
NFS-boot 是一种在网络上启动和运行系统的方法通常用于无盘工作站或者网络启动。NFS 是 Network File System网络文件系统的缩写它允许一台计算机在网络上共享它的文件系统。在 NFS-boot 的情况下操作系统的根文件系统root filesystem实际上位于网络上的另一台计算机上并通过 NFS 共享。
具体来说当一台计算机进行 NFS-boot 时它会通过网络启动协议如 BOOTP 或 DHCP获取其 IP 地址和其他网络设置。然后它会使用这些信息来通过 NFS 挂载其根文件系统。此时所有的文件操作如读取、写入实际上是在远程的 NFS 服务器上执行的。
NFS-boot 的主要优点是你可以在没有本地存储或者只有有限的本地存储的计算机上运行完整的操作系统。此外由于文件系统位于网络服务器上所以在多台计算机之间共享文件和应用程序相对较为简单。
然而NFS-boot 也有一些缺点。首先网络性能可能会影响到系统的整体性能尤其是在网络带宽有限或网络延迟较高的情况下。其次如果网络连接中断或者 NFS 服务器出现问题那么 NFS-boot 的计算机可能会无法正常运行。
在设置 NFS-boot 时通常需要在 NFS 服务器上配置共享的文件系统并在客户端上配置网络启动。具体的设置步骤可能会根据使用的操作系统和网络环境的不同而有所不同。
3.4 Live CD启动
Live CD 是一种包含完整操作系统的光盘它可以在不改变计算机硬盘上的数据的情况下直接从光盘启动操作系统。这种技术不仅适用于 CD也可以用于 DVD、USB 驱动器等可启动的媒体。
Live CD 在启动时通常会在 RAM 中创建一个临时的、可写的文件系统所以用户可以正常地使用操作系统而不会影响计算机的硬盘。当用户关闭系统时所有的更改包括系统设置和用户数据都会丢失除非特别地保存到其他的存储设备上。
Live CD 的一些常见用途包括 故障恢复当计算机的主要操作系统无法启动或者有问题时可以使用 Live CD 来修复系统或者恢复数据。 系统测试和演示可以通过 Live CD 来尝试新的操作系统或者软件而不需要实际地安装到计算机上。 安全和隐私由于 Live CD 不会保存任何数据所以它们经常被用于处理敏感信息例如在线银行或者密码管理。 安装系统许多操作系统的安装程序都是通过 Live CD 提供的用户可以先在 Live CD 中体验系统然后再决定是否要安装到硬盘上。
统并在客户端上配置网络启动。具体的设置步骤可能会根据使用的操作系统和网络环境的不同而有所不同。
