2010-12-05 21:52:44 +01:00
|
|
|
menu "System configuration"
|
2009-09-30 21:53:22 +02:00
|
|
|
|
2020-10-14 00:36:03 +02:00
|
|
|
# Note on package/skeleton: usually, it is not safe to 'select' a
|
|
|
|
|
# provider of a virtual package. But below we have an exception: each
|
|
|
|
|
# init system may select one of the virtual skeleton-init-* packages.
|
|
|
|
|
# As only one init system may be enabled, only one skeleton-init-* may
|
|
|
|
|
# be selected. So this is a safe situation.
|
2016-07-17 10:44:26 +02:00
|
|
|
choice
|
|
|
|
|
prompt "Root FS skeleton"
|
|
|
|
|
|
|
|
|
|
config BR2_ROOTFS_SKELETON_DEFAULT
|
|
|
|
|
bool "default target skeleton"
|
|
|
|
|
help
|
2020-10-14 00:36:03 +02:00
|
|
|
Use default target skeleton for selected init system.
|
2016-07-17 10:44:26 +02:00
|
|
|
|
|
|
|
|
config BR2_ROOTFS_SKELETON_CUSTOM
|
|
|
|
|
bool "custom target skeleton"
|
package/skeleton: split out into skeleton-custom
For the custom skeleton, we practicaly do nothing, except ensure it
contains the basic, required directories, and that those are properly
setup wrt. merged /usr.
Furthermore, our current skeleton is not fit for systemd, and we'll
have to split things out into various skeletons.
So, off-load the custom skeleton into its own package.
Thus, the existing skeleton package is now limited to:
- when using our default skeleton, install and tweak it properly;
- when using a custom skeleton, do nothing except for depending on
the skeleton-custom package.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Arnout: split off in a separate patch doing only this]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-08-02 00:52:12 +02:00
|
|
|
select BR2_PACKAGE_SKELETON_CUSTOM
|
2016-07-17 10:44:26 +02:00
|
|
|
help
|
|
|
|
|
Use custom target skeleton.
|
|
|
|
|
|
2020-10-14 00:36:01 +02:00
|
|
|
# skeleton from br2-external trees, if any
|
|
|
|
|
source "$BR2_BASE_DIR/.br2-external.in.skeleton"
|
|
|
|
|
|
2016-07-17 10:44:26 +02:00
|
|
|
endchoice
|
|
|
|
|
|
|
|
|
|
if BR2_ROOTFS_SKELETON_CUSTOM
|
|
|
|
|
|
|
|
|
|
config BR2_ROOTFS_SKELETON_CUSTOM_PATH
|
|
|
|
|
string "custom target skeleton path"
|
|
|
|
|
help
|
|
|
|
|
Path to custom target skeleton.
|
|
|
|
|
|
|
|
|
|
endif
|
|
|
|
|
|
2016-07-17 10:44:28 +02:00
|
|
|
if BR2_ROOTFS_SKELETON_DEFAULT
|
|
|
|
|
|
2009-09-30 21:53:22 +02:00
|
|
|
config BR2_TARGET_GENERIC_HOSTNAME
|
2013-11-11 17:23:23 +01:00
|
|
|
string "System hostname"
|
|
|
|
|
default "buildroot"
|
|
|
|
|
help
|
|
|
|
|
Select system hostname to be stored in /etc/hostname.
|
2009-09-30 21:53:22 +02:00
|
|
|
|
2014-01-07 23:46:07 +01:00
|
|
|
Leave empty to not create /etc/hostname, or to keep the
|
|
|
|
|
one from a custom skeleton.
|
|
|
|
|
|
2009-09-30 21:53:22 +02:00
|
|
|
config BR2_TARGET_GENERIC_ISSUE
|
2013-11-11 17:23:23 +01:00
|
|
|
string "System banner"
|
|
|
|
|
default "Welcome to Buildroot"
|
|
|
|
|
help
|
|
|
|
|
Select system banner (/etc/issue) to be displayed at login.
|
2009-09-30 21:53:22 +02:00
|
|
|
|
2014-01-07 23:46:07 +01:00
|
|
|
Leave empty to not create /etc/issue, or to keep the
|
|
|
|
|
one from a custom skeleton.
|
|
|
|
|
|
2016-07-17 10:44:28 +02:00
|
|
|
endif
|
|
|
|
|
|
2013-01-05 05:52:03 +01:00
|
|
|
choice
|
|
|
|
|
bool "Passwords encoding"
|
2018-12-06 03:06:28 +01:00
|
|
|
default BR2_TARGET_GENERIC_PASSWD_SHA256
|
2013-01-05 05:52:03 +01:00
|
|
|
help
|
|
|
|
|
Choose the password encoding scheme to use when Buildroot
|
|
|
|
|
needs to encode a password (eg. the root password, below).
|
2013-04-29 12:29:33 +02:00
|
|
|
|
2013-01-05 05:52:03 +01:00
|
|
|
Note: this is used at build-time, and *not* at runtime.
|
|
|
|
|
|
|
|
|
|
config BR2_TARGET_GENERIC_PASSWD_SHA256
|
|
|
|
|
bool "sha-256"
|
|
|
|
|
help
|
2018-12-06 03:06:27 +01:00
|
|
|
Use SHA256 to encode passwords which is stronger than MD5.
|
2013-01-05 05:52:03 +01:00
|
|
|
|
|
|
|
|
config BR2_TARGET_GENERIC_PASSWD_SHA512
|
|
|
|
|
bool "sha-512"
|
|
|
|
|
help
|
2018-12-06 03:06:27 +01:00
|
|
|
Use SHA512 to encode passwords which is stronger than SHA256
|
2013-01-05 05:52:03 +01:00
|
|
|
|
|
|
|
|
endchoice # Passwd encoding
|
|
|
|
|
|
|
|
|
|
config BR2_TARGET_GENERIC_PASSWD_METHOD
|
|
|
|
|
string
|
|
|
|
|
default "sha-256" if BR2_TARGET_GENERIC_PASSWD_SHA256
|
|
|
|
|
default "sha-512" if BR2_TARGET_GENERIC_PASSWD_SHA512
|
|
|
|
|
|
2020-10-14 00:36:03 +02:00
|
|
|
# See comment at the top of the file, about selecting individual
|
|
|
|
|
# skeletons, which are providers of the virtual skeleton package.
|
2012-07-28 09:21:20 +02:00
|
|
|
choice
|
|
|
|
|
prompt "Init system"
|
|
|
|
|
default BR2_INIT_BUSYBOX
|
|
|
|
|
|
|
|
|
|
config BR2_INIT_BUSYBOX
|
2014-05-31 09:55:35 +02:00
|
|
|
bool "BusyBox"
|
2012-07-28 09:21:20 +02:00
|
|
|
select BR2_PACKAGE_BUSYBOX
|
2015-07-13 23:00:08 +02:00
|
|
|
select BR2_PACKAGE_INITSCRIPTS
|
2020-10-14 00:36:03 +02:00
|
|
|
select BR2_PACKAGE_SKELETON_INIT_SYSV if BR2_ROOTFS_SKELETON_DEFAULT
|
2012-07-28 09:21:20 +02:00
|
|
|
|
|
|
|
|
config BR2_INIT_SYSV
|
|
|
|
|
bool "systemV"
|
2016-08-13 18:57:21 +02:00
|
|
|
depends on BR2_USE_MMU # sysvinit
|
2014-01-13 23:31:20 +01:00
|
|
|
select BR2_PACKAGE_BUSYBOX_SHOW_OTHERS # sysvinit
|
2015-07-13 23:00:08 +02:00
|
|
|
select BR2_PACKAGE_INITSCRIPTS
|
2012-07-28 09:21:20 +02:00
|
|
|
select BR2_PACKAGE_SYSVINIT
|
2020-10-14 00:36:03 +02:00
|
|
|
select BR2_PACKAGE_SKELETON_INIT_SYSV if BR2_ROOTFS_SKELETON_DEFAULT
|
2012-07-28 09:21:20 +02:00
|
|
|
|
2019-05-12 21:55:40 +02:00
|
|
|
config BR2_INIT_OPENRC
|
|
|
|
|
bool "OpenRC"
|
|
|
|
|
depends on BR2_USE_MMU
|
|
|
|
|
depends on !BR2_STATIC_LIBS
|
2023-11-29 08:46:35 +01:00
|
|
|
depends on !BR2_TOOLCHAIN_USES_UCLIBC # openrc
|
2019-05-12 21:55:40 +02:00
|
|
|
select BR2_PACKAGE_OPENRC
|
2020-10-14 00:36:03 +02:00
|
|
|
select BR2_PACKAGE_SKELETON_INIT_OPENRC if BR2_ROOTFS_SKELETON_DEFAULT
|
2019-05-12 21:55:40 +02:00
|
|
|
|
2023-11-28 20:46:47 +01:00
|
|
|
comment "openrc needs a glibc or musl toolchain w/ dynamic library"
|
2019-05-12 21:55:40 +02:00
|
|
|
depends on BR2_USE_MMU
|
2023-11-29 08:46:35 +01:00
|
|
|
depends on BR2_STATIC_LIBS && BR2_TOOLCHAIN_USES_UCLIBC
|
2019-05-12 21:55:40 +02:00
|
|
|
|
system: add options for /bin /sbin and /lib to be symlinks into /usr
systemd is increasingly expecting things to live in /usr/bin, /usr/sbin
or /usr/lib nad not in /bin, /sbin or /lib. It has inherited those
expectations from a Fedora change:
https://fedoraproject.org/wiki/Features/UsrMove
Note however, that systemd does support /usr being on a separate
filesystem; it just expects an initramfs to mount it before the final
switchroot over to the actual rootfs.
But the traditional use-case for Buildroot is not to boot with an
initramfs; although that is totally feasible, that's probably not what
is commonly done in the vast majority of cases.
However, a lot of packages still install stuff directly into /bin,
/sbin or /lib, which systemd may need early-on in the boot process,
even before it may have a chance to mount /usr. Even though we can
tell systemd, at configure-time, where it should expect programs to
be at runtime, it does not make sense to go head-first against an
upstream wa^Hill.
Add an option so that /bin, /sbin and /lib be symlinks to /usr/bin
and /usr/sbin. That option is forcibly enabled when the init system
is systemd.
Note: we need not handle /lib32 or /lib64, as they already are symlinks
to /lib, which means they will automatically be redirected to /usr/lib,
as /usr/lib32 and /usr/lib64 already are.
Furthermore, this means we're no longer supporting a split-usr setup, so
the corresponding configure options have been removed as well for
systemd and, when using a merged /usr, for eudev as well.
In Buildroot, we decided (with this patch) not to support a split-usr
when systemd is used as an init system. This is a design decision, not
a systemd issue. Thus the select is with BR2_INIT_SYSTEMD rather than
with BR2_PACKAGE_SYSTEMD.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Mike Williams <mike@mikebwilliams.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Tested-by: Mike Williams <mike@mikebwilliams.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-09-04 22:17:32 +02:00
|
|
|
# In Buildroot, we decided not to support a split-usr when systemd is
|
|
|
|
|
# used as an init system. This is a design decision, not a systemd
|
|
|
|
|
# issue. Thus the select is with BR2_INIT_SYSTEMD (below) rather than
|
|
|
|
|
# with BR2_PACKAGE_SYSTEMD.
|
2012-07-28 09:21:20 +02:00
|
|
|
config BR2_INIT_SYSTEMD
|
|
|
|
|
bool "systemd"
|
2014-03-28 17:31:06 +01:00
|
|
|
depends on BR2_PACKAGE_SYSTEMD_ARCH_SUPPORTS
|
2012-11-17 13:24:08 +01:00
|
|
|
depends on BR2_USE_MMU
|
2014-12-03 22:41:29 +01:00
|
|
|
depends on !BR2_STATIC_LIBS
|
package/systemd: make sure init choice and package have same dependencies
Currently, the dependencies for the init system choice, and the
dependencies for the package, are slightly different, and not in the
same order, the latter making it difficult to assess consistency between
the two.
Fix all that, by cross-duplicating dependencies from the init choice and
the package, and order the dependencies according to the manual (arch
first, toolchain, then the others).
Note that some dependencies are redundant, but kept nonetheless for
correctness:
- BR2_USE_MMU is implied by BR2_TOOLCHAIN_USES_GLIBC, but systemd does
use fork();
- !BR2_STATIC_LIBS is also implied by BR2_TOOLCHAIN_USES_GLIBC, but it
is also inherited from kmod which we select;
- BR2_TOOLCHAIN_HAS_THREADS is also implied by BR2_TOOLCHAIN_USES_GLIBC,
but systemd does use pthread_*() functions.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-04-05 19:55:05 +02:00
|
|
|
depends on BR2_TOOLCHAIN_USES_GLIBC
|
|
|
|
|
depends on BR2_TOOLCHAIN_HAS_SSP
|
|
|
|
|
depends on BR2_TOOLCHAIN_HAS_THREADS
|
2023-08-02 18:46:28 +02:00
|
|
|
depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_14
|
2020-04-05 00:08:42 +02:00
|
|
|
depends on BR2_TOOLCHAIN_GCC_AT_LEAST_5
|
|
|
|
|
depends on BR2_HOST_GCC_AT_LEAST_5
|
2015-11-09 21:40:32 +01:00
|
|
|
select BR2_ROOTFS_MERGED_USR
|
2012-07-28 09:21:20 +02:00
|
|
|
select BR2_PACKAGE_SYSTEMD
|
2020-10-14 00:36:03 +02:00
|
|
|
select BR2_PACKAGE_SKELETON_INIT_SYSTEMD if BR2_ROOTFS_SKELETON_DEFAULT
|
2012-07-28 09:21:20 +02:00
|
|
|
|
2023-08-02 18:46:28 +02:00
|
|
|
comment "systemd needs a glibc toolchain w/ SSP, headers >= 4.14, host and target gcc >= 5"
|
2018-09-12 16:17:54 +02:00
|
|
|
depends on BR2_PACKAGE_SYSTEMD_ARCH_SUPPORTS
|
|
|
|
|
depends on BR2_USE_MMU
|
2018-11-21 22:05:56 +01:00
|
|
|
depends on !BR2_TOOLCHAIN_USES_GLIBC || \
|
2018-09-12 16:17:54 +02:00
|
|
|
!BR2_TOOLCHAIN_HAS_SSP || \
|
2023-08-02 18:46:28 +02:00
|
|
|
!BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_14 || \
|
2020-04-05 00:08:42 +02:00
|
|
|
!BR2_TOOLCHAIN_GCC_AT_LEAST_5 || \
|
|
|
|
|
!BR2_HOST_GCC_AT_LEAST_5
|
2012-07-28 09:21:20 +02:00
|
|
|
|
2023-01-15 12:48:39 +01:00
|
|
|
comment "systemd highly recommends Linux >= 4.15"
|
|
|
|
|
depends on BR2_INIT_SYSTEMD
|
|
|
|
|
depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_15
|
|
|
|
|
|
2012-08-13 01:53:49 +02:00
|
|
|
config BR2_INIT_NONE
|
|
|
|
|
bool "None"
|
2020-10-14 00:36:03 +02:00
|
|
|
select BR2_PACKAGE_SKELETON_INIT_NONE if BR2_ROOTFS_SKELETON_DEFAULT
|
2016-05-27 22:53:53 +02:00
|
|
|
help
|
|
|
|
|
Buildroot will not install any init system. You will
|
|
|
|
|
have to provide your own, either with a new package
|
|
|
|
|
or with a rootfs-overlay.
|
2012-08-13 01:53:49 +02:00
|
|
|
|
2020-10-14 00:36:04 +02:00
|
|
|
# Init systems from br2-external trees, if any
|
|
|
|
|
source "$BR2_BASE_DIR/.br2-external.in.init"
|
|
|
|
|
|
2012-07-28 09:21:20 +02:00
|
|
|
endchoice
|
|
|
|
|
|
system: add options for /var factory and tmpfiles pre-seed
Currently, when one does not enable remounting the rootfs read-write,
i.e. keep it read-only, for example because the filesystem is actually
read-only by design, like squashfs, then two things happen:
- we create a factory from the content of /var at build time, register
tmpfiles entries for it, and mount a tmpfs on /var at runtime, so
that systemd-tmpfiles does populate /var from the factory; this is
only done when the rootfs is not remounted r/w;
- we trigger systemd-tmpfiles at build time, which uses the tmpfiles
db, of which our /var entries, to pre-populate the filesystem; this
is always done, whether the rootfs is remounted r/w or not.
Note that Buildroot mounts a tmpfs on /var, and leaves to the integrator
to care for providing an actual filesystem, as there are too many
variants and is very specific to each use-case.
These two mechanisms are conflicting, semantically, but also
technically: the files from the factory will be duplicated, but that
may help in some situations when the actual /var filesystem is not
mountable.
In some cases, it might be preferable to have none, either, or both
mechanisms enabled; it highly depends on the ultimate integration scheme
chosen for a device.
For example, some people will be very happy with a /var that is actually
on a tmpfs and that it gets reseeded form scratch at every boot, while
others may want to ensure that their system continue to work even when
they can't mount something that makes /var writable.
YMMV, as they used to say back in the day...
So, we introduce two new options, in the system sub-menu, each to drive
each mechanism. We default those options to y, to keep the previous
behaviour by default, except the var factory is only available when the
rootfs is not remounted r/w, as it were so far.
We still hint in the help text that there might be some conflict between
the two mechanisms, but since it has been that way for some time, it
does not look too broken for most people.
Since that introduces more options related to systemd being chosen as an
init system, we gather those two options and the existing one inside a
if-endif block, rather than adding more 'depends on' on each options.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Norbert Lange <nolange79@gmail.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Romain Naour <romain.naour@smile.fr>
Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
Cc: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-10-18 21:43:07 +02:00
|
|
|
if BR2_INIT_SYSTEMD
|
|
|
|
|
|
2023-01-15 13:52:46 +01:00
|
|
|
choice
|
|
|
|
|
bool "/var management"
|
|
|
|
|
default BR2_INIT_SYSTEMD_VAR_FACTORY # legacy
|
system: add options for /var factory and tmpfiles pre-seed
Currently, when one does not enable remounting the rootfs read-write,
i.e. keep it read-only, for example because the filesystem is actually
read-only by design, like squashfs, then two things happen:
- we create a factory from the content of /var at build time, register
tmpfiles entries for it, and mount a tmpfs on /var at runtime, so
that systemd-tmpfiles does populate /var from the factory; this is
only done when the rootfs is not remounted r/w;
- we trigger systemd-tmpfiles at build time, which uses the tmpfiles
db, of which our /var entries, to pre-populate the filesystem; this
is always done, whether the rootfs is remounted r/w or not.
Note that Buildroot mounts a tmpfs on /var, and leaves to the integrator
to care for providing an actual filesystem, as there are too many
variants and is very specific to each use-case.
These two mechanisms are conflicting, semantically, but also
technically: the files from the factory will be duplicated, but that
may help in some situations when the actual /var filesystem is not
mountable.
In some cases, it might be preferable to have none, either, or both
mechanisms enabled; it highly depends on the ultimate integration scheme
chosen for a device.
For example, some people will be very happy with a /var that is actually
on a tmpfs and that it gets reseeded form scratch at every boot, while
others may want to ensure that their system continue to work even when
they can't mount something that makes /var writable.
YMMV, as they used to say back in the day...
So, we introduce two new options, in the system sub-menu, each to drive
each mechanism. We default those options to y, to keep the previous
behaviour by default, except the var factory is only available when the
rootfs is not remounted r/w, as it were so far.
We still hint in the help text that there might be some conflict between
the two mechanisms, but since it has been that way for some time, it
does not look too broken for most people.
Since that introduces more options related to systemd being chosen as an
init system, we gather those two options and the existing one inside a
if-endif block, rather than adding more 'depends on' on each options.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Norbert Lange <nolange79@gmail.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Romain Naour <romain.naour@smile.fr>
Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
Cc: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-10-18 21:43:07 +02:00
|
|
|
depends on !BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW
|
2023-01-15 13:52:46 +01:00
|
|
|
help
|
|
|
|
|
Select how Buildroot provides a read-write /var when the
|
|
|
|
|
rootfs is not remounted read-write.
|
|
|
|
|
|
package/skeleton-init-systemd: add option to use overlayfs on /var
Systemd requires /var to be writeable [1]. With read-only rootfs, we
need a solution that makes sure /var is writeable. We already have a
solution using a factory, with systemd-tmpfiles. This approach has a few
limitations:
- The behaviour of what happens when the rootfs is updated and the
contents of the factory /var changes are not very intuitive.
- systemd-tmpfiles is not started super early in the boot, so there's a
relatively long time that /var is not writeable. There is also no easy
way in systemd to express dependencies on the subdirectories of /var
to have been populated from the factory.
- The contents of /var is duplicated. If it is big, the rootfs size
increases unnecessarily and it takes a long time before the copying is
done. This is also not done atomically.
This commit adds an alternative using an overlay filesystem that has the
following characteristics:
- Don't depend on anything being available, except the
API File Systems [2]. In other words, this can be done very early in
the boot process. This is useful because /var is meant to be
available before normal and even some early services are running.
- Be a clean drop-in, that can be trivially added / removed.
- Make sure that overlayfs is available in the kernel.
- Units are (partially) reusable for custom solutions. This goal is
actually not fully reached yet: for that the service file should be
converted into a template, and the mount unit should use a specifier
for all repeated references to /var.
Mounting the overlay is slightly acrobatic and requires a few steps:
- First, we have to make sure the directories for overlayfs's upper,
lower and work directories are available on a tmpfs. Note that
"upper" and "work" must be on the same filesystem.
- The writeable overlay upper directory must be mounted.
- The original contents of /var must be bind-mounted to the overlay
lower directory.
- Finally, the overlay must be mounted on /var.
For the overlayfs directories, we create a tree on /run. Since there is
no standard name convention for this, we create a new directory
"/run/buildroot" with subdirectory "mounts" for everything
mount-related. Below that, a subdirectory is created for every mount
point that needs helper directories. Thus, we arrive to
/run/buildroot/mounts/var as the base directory for the overlay. Below
this, the directories lower, upper and work are created.
The bind-mount of /var is done in the same service as the one creating
the overlay lower, upper and work directories. Creating those
directories can't be done in a mount unit, and bind-mounting /var in a
mount unit would create a circular dependency. Indeed, if we had a mount
unit to do the bind mount, then it sould look like:
# run-buildroot-mounts-var-lower.mount
[Mount]
What=/var
Where=/run/buildroot/mounts/var/lower
Options=bind
and then the var.mount unit would need to have a dependency on that
unit:
# var.mount
[Unit]
After=run-buildroot-mounts-var-lower.mount
[Mount]
Where=/var
However, the What=/var of the first unit automatically adds an implicit
dependency on /var, and since there is a unit providing Where=/var, we
would have run-buildroot-mounts-var-lower.mount depend on var.mount, but
we need var.mount to depend on run-buildroot-mounts-var-lower.mount, so
this is a circular dependency. There is no way to tell systemd no to add
the implicit dependency. So we do the bind mont manually in the service
unit that prepares the overlay structure.
For the writeable upper layer, we don't need to do anything. In the
default configuration, the upper layer is supposed to be a tmpfs, and
/run/buildroot/mounts/var/upper is already a tmpfs so it can serve as
is. To make it persistent, we suggest to the user to mount a writeable,
persistent filesystem on /run/buildroot/mounts/var. The
RequiresMountsFor dependency in the prepare-var-overlay service makes
sure that that mount is performed before the overlay is started. Using
/run/buildroot/mounts/var/upper as the mount point sounds more logical
at first, but since the work directory is supposed to be on the same
filesystem as the upper directory, this wouldn't work very well.
As example, consider using /dev/sdc1 as upper layer for var, this can be
achieved by adding the following line to fstab:
/dev/sdc1 /run/buildroot/mounts/var ext4 defaults
Systemd will convert this into a mount unit with all the proper
dependencies.
Norbert provided some systemd units as a starting point, and that was
quite a huge help in understanding how to fit all those things together.
[1] - https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems/
Co-authored-by: Norbert Lange <nolange79@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Norbert Lange <nolange79@gmail.com>
Cc: Romain Naour <romain.naour@smile.fr>
Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
[Arnout:
- Merge commit messages from Yann and from Norbert.
- Remove the run-buildroot-mounts-var.mount unit; instead, just reuse
the existing tmpfs for the upper layer in the default case.
- Update the help text to explain how to mount a custom upper layer
with fstab.
]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
2022-10-18 21:43:09 +02:00
|
|
|
Note: Buildroot uses a tmpfs, either as a mount point or as
|
|
|
|
|
the upper of an overlayfs, so as to at least make the system
|
|
|
|
|
bootable out of the box; mounting a filesystem from actual
|
|
|
|
|
storage is left to the integration, as it is too specific and
|
|
|
|
|
may need preparatory work like partitionning a device and/or
|
|
|
|
|
formatting a filesystem first, which falls out of the scope
|
|
|
|
|
of Buildroot.
|
|
|
|
|
|
2023-01-15 13:52:46 +01:00
|
|
|
config BR2_INIT_SYSTEMD_VAR_FACTORY
|
|
|
|
|
bool "build a factory to populate a tmpfs"
|
system: add options for /var factory and tmpfiles pre-seed
Currently, when one does not enable remounting the rootfs read-write,
i.e. keep it read-only, for example because the filesystem is actually
read-only by design, like squashfs, then two things happen:
- we create a factory from the content of /var at build time, register
tmpfiles entries for it, and mount a tmpfs on /var at runtime, so
that systemd-tmpfiles does populate /var from the factory; this is
only done when the rootfs is not remounted r/w;
- we trigger systemd-tmpfiles at build time, which uses the tmpfiles
db, of which our /var entries, to pre-populate the filesystem; this
is always done, whether the rootfs is remounted r/w or not.
Note that Buildroot mounts a tmpfs on /var, and leaves to the integrator
to care for providing an actual filesystem, as there are too many
variants and is very specific to each use-case.
These two mechanisms are conflicting, semantically, but also
technically: the files from the factory will be duplicated, but that
may help in some situations when the actual /var filesystem is not
mountable.
In some cases, it might be preferable to have none, either, or both
mechanisms enabled; it highly depends on the ultimate integration scheme
chosen for a device.
For example, some people will be very happy with a /var that is actually
on a tmpfs and that it gets reseeded form scratch at every boot, while
others may want to ensure that their system continue to work even when
they can't mount something that makes /var writable.
YMMV, as they used to say back in the day...
So, we introduce two new options, in the system sub-menu, each to drive
each mechanism. We default those options to y, to keep the previous
behaviour by default, except the var factory is only available when the
rootfs is not remounted r/w, as it were so far.
We still hint in the help text that there might be some conflict between
the two mechanisms, but since it has been that way for some time, it
does not look too broken for most people.
Since that introduces more options related to systemd being chosen as an
init system, we gather those two options and the existing one inside a
if-endif block, rather than adding more 'depends on' on each options.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Norbert Lange <nolange79@gmail.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Romain Naour <romain.naour@smile.fr>
Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
Cc: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-10-18 21:43:07 +02:00
|
|
|
help
|
|
|
|
|
Build a factory of the content of /var as installed by
|
|
|
|
|
packages, mount a tmpfs on /var at runtime, so that
|
|
|
|
|
systemd-tmpfiles can populate it from the factory.
|
|
|
|
|
|
|
|
|
|
This may help on a read-only rootfs.
|
|
|
|
|
|
|
|
|
|
It probably does not play very well with triggering a call
|
|
|
|
|
to systemd-tmpfiles at build time (below).
|
|
|
|
|
|
|
|
|
|
To use persistent storage, provide a systemd dropin for the
|
|
|
|
|
var.mount unit, that overrides the What and Type, and possibly
|
|
|
|
|
the Options and After, fields.
|
|
|
|
|
|
package/skeleton-init-systemd: add option to use overlayfs on /var
Systemd requires /var to be writeable [1]. With read-only rootfs, we
need a solution that makes sure /var is writeable. We already have a
solution using a factory, with systemd-tmpfiles. This approach has a few
limitations:
- The behaviour of what happens when the rootfs is updated and the
contents of the factory /var changes are not very intuitive.
- systemd-tmpfiles is not started super early in the boot, so there's a
relatively long time that /var is not writeable. There is also no easy
way in systemd to express dependencies on the subdirectories of /var
to have been populated from the factory.
- The contents of /var is duplicated. If it is big, the rootfs size
increases unnecessarily and it takes a long time before the copying is
done. This is also not done atomically.
This commit adds an alternative using an overlay filesystem that has the
following characteristics:
- Don't depend on anything being available, except the
API File Systems [2]. In other words, this can be done very early in
the boot process. This is useful because /var is meant to be
available before normal and even some early services are running.
- Be a clean drop-in, that can be trivially added / removed.
- Make sure that overlayfs is available in the kernel.
- Units are (partially) reusable for custom solutions. This goal is
actually not fully reached yet: for that the service file should be
converted into a template, and the mount unit should use a specifier
for all repeated references to /var.
Mounting the overlay is slightly acrobatic and requires a few steps:
- First, we have to make sure the directories for overlayfs's upper,
lower and work directories are available on a tmpfs. Note that
"upper" and "work" must be on the same filesystem.
- The writeable overlay upper directory must be mounted.
- The original contents of /var must be bind-mounted to the overlay
lower directory.
- Finally, the overlay must be mounted on /var.
For the overlayfs directories, we create a tree on /run. Since there is
no standard name convention for this, we create a new directory
"/run/buildroot" with subdirectory "mounts" for everything
mount-related. Below that, a subdirectory is created for every mount
point that needs helper directories. Thus, we arrive to
/run/buildroot/mounts/var as the base directory for the overlay. Below
this, the directories lower, upper and work are created.
The bind-mount of /var is done in the same service as the one creating
the overlay lower, upper and work directories. Creating those
directories can't be done in a mount unit, and bind-mounting /var in a
mount unit would create a circular dependency. Indeed, if we had a mount
unit to do the bind mount, then it sould look like:
# run-buildroot-mounts-var-lower.mount
[Mount]
What=/var
Where=/run/buildroot/mounts/var/lower
Options=bind
and then the var.mount unit would need to have a dependency on that
unit:
# var.mount
[Unit]
After=run-buildroot-mounts-var-lower.mount
[Mount]
Where=/var
However, the What=/var of the first unit automatically adds an implicit
dependency on /var, and since there is a unit providing Where=/var, we
would have run-buildroot-mounts-var-lower.mount depend on var.mount, but
we need var.mount to depend on run-buildroot-mounts-var-lower.mount, so
this is a circular dependency. There is no way to tell systemd no to add
the implicit dependency. So we do the bind mont manually in the service
unit that prepares the overlay structure.
For the writeable upper layer, we don't need to do anything. In the
default configuration, the upper layer is supposed to be a tmpfs, and
/run/buildroot/mounts/var/upper is already a tmpfs so it can serve as
is. To make it persistent, we suggest to the user to mount a writeable,
persistent filesystem on /run/buildroot/mounts/var. The
RequiresMountsFor dependency in the prepare-var-overlay service makes
sure that that mount is performed before the overlay is started. Using
/run/buildroot/mounts/var/upper as the mount point sounds more logical
at first, but since the work directory is supposed to be on the same
filesystem as the upper directory, this wouldn't work very well.
As example, consider using /dev/sdc1 as upper layer for var, this can be
achieved by adding the following line to fstab:
/dev/sdc1 /run/buildroot/mounts/var ext4 defaults
Systemd will convert this into a mount unit with all the proper
dependencies.
Norbert provided some systemd units as a starting point, and that was
quite a huge help in understanding how to fit all those things together.
[1] - https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems/
Co-authored-by: Norbert Lange <nolange79@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Norbert Lange <nolange79@gmail.com>
Cc: Romain Naour <romain.naour@smile.fr>
Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
[Arnout:
- Merge commit messages from Yann and from Norbert.
- Remove the run-buildroot-mounts-var.mount unit; instead, just reuse
the existing tmpfs for the upper layer in the default case.
- Update the help text to explain how to mount a custom upper layer
with fstab.
]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
2022-10-18 21:43:09 +02:00
|
|
|
config BR2_INIT_SYSTEMD_VAR_OVERLAYFS
|
|
|
|
|
bool "mount an overlayfs backed by a tmpfs"
|
|
|
|
|
select BR2_INIT_SYSTEMD_POPULATE_TMPFILES
|
|
|
|
|
help
|
|
|
|
|
Mount an overlayfs on /var, with the upper as a tmpfs.
|
|
|
|
|
|
|
|
|
|
To use a persistent storage, provide either a mount unit or a
|
|
|
|
|
fstab line to mount it on /run/buildroot/mounts/var, e.g.
|
|
|
|
|
|
|
|
|
|
/dev/sdc1 /run/buildroot/mounts/var ext4 defaults
|
|
|
|
|
|
2023-01-15 13:52:46 +01:00
|
|
|
config BR2_INIT_SYSTEMD_VAR_NONE
|
|
|
|
|
bool "do nothing"
|
|
|
|
|
help
|
|
|
|
|
Choose this if you have custom dispositions (like one or more
|
|
|
|
|
of a post-build script, a fakeroot script, systemd units, an
|
|
|
|
|
initramfs, or something else) that prepare /var to be writable
|
|
|
|
|
on a read-only rootfs.
|
|
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
system: add options for /var factory and tmpfiles pre-seed
Currently, when one does not enable remounting the rootfs read-write,
i.e. keep it read-only, for example because the filesystem is actually
read-only by design, like squashfs, then two things happen:
- we create a factory from the content of /var at build time, register
tmpfiles entries for it, and mount a tmpfs on /var at runtime, so
that systemd-tmpfiles does populate /var from the factory; this is
only done when the rootfs is not remounted r/w;
- we trigger systemd-tmpfiles at build time, which uses the tmpfiles
db, of which our /var entries, to pre-populate the filesystem; this
is always done, whether the rootfs is remounted r/w or not.
Note that Buildroot mounts a tmpfs on /var, and leaves to the integrator
to care for providing an actual filesystem, as there are too many
variants and is very specific to each use-case.
These two mechanisms are conflicting, semantically, but also
technically: the files from the factory will be duplicated, but that
may help in some situations when the actual /var filesystem is not
mountable.
In some cases, it might be preferable to have none, either, or both
mechanisms enabled; it highly depends on the ultimate integration scheme
chosen for a device.
For example, some people will be very happy with a /var that is actually
on a tmpfs and that it gets reseeded form scratch at every boot, while
others may want to ensure that their system continue to work even when
they can't mount something that makes /var writable.
YMMV, as they used to say back in the day...
So, we introduce two new options, in the system sub-menu, each to drive
each mechanism. We default those options to y, to keep the previous
behaviour by default, except the var factory is only available when the
rootfs is not remounted r/w, as it were so far.
We still hint in the help text that there might be some conflict between
the two mechanisms, but since it has been that way for some time, it
does not look too broken for most people.
Since that introduces more options related to systemd being chosen as an
init system, we gather those two options and the existing one inside a
if-endif block, rather than adding more 'depends on' on each options.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Norbert Lange <nolange79@gmail.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Romain Naour <romain.naour@smile.fr>
Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
Cc: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-10-18 21:43:07 +02:00
|
|
|
config BR2_INIT_SYSTEMD_POPULATE_TMPFILES
|
|
|
|
|
bool "trigger systemd-tmpfiles during build"
|
|
|
|
|
default y # legacy
|
|
|
|
|
help
|
|
|
|
|
Act on the systemd-tmpfiles.d database at build time, when
|
|
|
|
|
assembling the root filesystems.
|
|
|
|
|
|
|
|
|
|
This may help on a read-only filesystem.
|
|
|
|
|
|
|
|
|
|
It probably does not play very well with the /var factory
|
|
|
|
|
(above).
|
|
|
|
|
|
2022-04-26 23:43:12 +02:00
|
|
|
config BR2_PACKAGE_SYSTEMD_DEFAULT_TARGET
|
|
|
|
|
string "The default unit systemd starts at bootup"
|
|
|
|
|
default "multi-user.target"
|
|
|
|
|
help
|
|
|
|
|
Specify the name of the unit configuration file to be started
|
|
|
|
|
at bootup by systemd. Should end in ".target".
|
|
|
|
|
ex: multi-user.target
|
|
|
|
|
|
|
|
|
|
https://www.freedesktop.org/software/systemd/man/systemd.special.html#default.target
|
|
|
|
|
|
system: add options for /var factory and tmpfiles pre-seed
Currently, when one does not enable remounting the rootfs read-write,
i.e. keep it read-only, for example because the filesystem is actually
read-only by design, like squashfs, then two things happen:
- we create a factory from the content of /var at build time, register
tmpfiles entries for it, and mount a tmpfs on /var at runtime, so
that systemd-tmpfiles does populate /var from the factory; this is
only done when the rootfs is not remounted r/w;
- we trigger systemd-tmpfiles at build time, which uses the tmpfiles
db, of which our /var entries, to pre-populate the filesystem; this
is always done, whether the rootfs is remounted r/w or not.
Note that Buildroot mounts a tmpfs on /var, and leaves to the integrator
to care for providing an actual filesystem, as there are too many
variants and is very specific to each use-case.
These two mechanisms are conflicting, semantically, but also
technically: the files from the factory will be duplicated, but that
may help in some situations when the actual /var filesystem is not
mountable.
In some cases, it might be preferable to have none, either, or both
mechanisms enabled; it highly depends on the ultimate integration scheme
chosen for a device.
For example, some people will be very happy with a /var that is actually
on a tmpfs and that it gets reseeded form scratch at every boot, while
others may want to ensure that their system continue to work even when
they can't mount something that makes /var writable.
YMMV, as they used to say back in the day...
So, we introduce two new options, in the system sub-menu, each to drive
each mechanism. We default those options to y, to keep the previous
behaviour by default, except the var factory is only available when the
rootfs is not remounted r/w, as it were so far.
We still hint in the help text that there might be some conflict between
the two mechanisms, but since it has been that way for some time, it
does not look too broken for most people.
Since that introduces more options related to systemd being chosen as an
init system, we gather those two options and the existing one inside a
if-endif block, rather than adding more 'depends on' on each options.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Norbert Lange <nolange79@gmail.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Romain Naour <romain.naour@smile.fr>
Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
Cc: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-10-18 21:43:07 +02:00
|
|
|
endif # BR2_INIT_SYSTEMD
|
|
|
|
|
|
2013-11-06 16:34:34 +01:00
|
|
|
choice
|
2014-02-07 14:21:34 +01:00
|
|
|
prompt "/dev management" if !BR2_INIT_SYSTEMD
|
2013-11-06 16:34:34 +01:00
|
|
|
default BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_DEVTMPFS
|
|
|
|
|
|
|
|
|
|
config BR2_ROOTFS_DEVICE_CREATION_STATIC
|
|
|
|
|
bool "Static using device table"
|
|
|
|
|
|
|
|
|
|
config BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_DEVTMPFS
|
|
|
|
|
bool "Dynamic using devtmpfs only"
|
|
|
|
|
|
|
|
|
|
config BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV
|
2015-10-04 11:43:35 +02:00
|
|
|
bool "Dynamic using devtmpfs + mdev"
|
2013-11-06 16:34:34 +01:00
|
|
|
select BR2_PACKAGE_BUSYBOX
|
|
|
|
|
|
2014-02-07 14:21:32 +01:00
|
|
|
config BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV
|
2015-10-04 11:43:35 +02:00
|
|
|
bool "Dynamic using devtmpfs + eudev"
|
2016-12-26 16:22:35 +01:00
|
|
|
depends on BR2_USE_WCHAR # eudev
|
2014-12-03 22:41:29 +01:00
|
|
|
depends on !BR2_STATIC_LIBS
|
2014-02-28 14:30:23 +01:00
|
|
|
depends on BR2_USE_MMU # eudev
|
2014-02-07 14:21:32 +01:00
|
|
|
select BR2_PACKAGE_EUDEV
|
2013-11-06 16:34:34 +01:00
|
|
|
|
2015-03-30 23:07:28 +02:00
|
|
|
comment "eudev needs a toolchain w/ wchar, dynamic library"
|
2014-02-28 14:30:23 +01:00
|
|
|
depends on BR2_USE_MMU
|
2015-03-30 23:07:28 +02:00
|
|
|
depends on !BR2_USE_WCHAR || BR2_STATIC_LIBS
|
2013-11-06 16:34:34 +01:00
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
2014-02-07 14:21:34 +01:00
|
|
|
comment "/dev management using udev (from systemd)"
|
|
|
|
|
depends on BR2_INIT_SYSTEMD
|
|
|
|
|
|
2011-05-12 23:37:35 +02:00
|
|
|
config BR2_ROOTFS_DEVICE_TABLE
|
2011-07-25 00:09:33 +02:00
|
|
|
string "Path to the permission tables"
|
2012-11-04 13:00:25 +01:00
|
|
|
default "system/device_table.txt"
|
2011-07-25 00:09:33 +02:00
|
|
|
help
|
|
|
|
|
Specify a space-separated list of permission table locations,
|
|
|
|
|
that will be passed to the makedevs utility to assign
|
|
|
|
|
correct owners and permissions on various files in the
|
|
|
|
|
target filesystem.
|
|
|
|
|
|
|
|
|
|
See package/makedevs/README for details on the usage and
|
|
|
|
|
syntax of these files.
|
|
|
|
|
|
|
|
|
|
config BR2_ROOTFS_STATIC_DEVICE_TABLE
|
2011-05-12 23:37:35 +02:00
|
|
|
string "Path to the device tables"
|
2012-11-04 13:00:25 +01:00
|
|
|
default "system/device_table_dev.txt"
|
2011-07-25 00:09:33 +02:00
|
|
|
depends on BR2_ROOTFS_DEVICE_CREATION_STATIC
|
2011-05-12 23:37:35 +02:00
|
|
|
help
|
|
|
|
|
Specify a space-separated list of device table locations,
|
|
|
|
|
that will be passed to the makedevs utility to create all
|
2011-07-25 00:09:33 +02:00
|
|
|
the special device files under /dev.
|
2011-05-12 23:37:35 +02:00
|
|
|
|
|
|
|
|
See package/makedevs/README for details on the usage and
|
|
|
|
|
syntax of these files.
|
|
|
|
|
|
2016-06-29 17:19:44 +02:00
|
|
|
config BR2_ROOTFS_DEVICE_TABLE_SUPPORTS_EXTENDED_ATTRIBUTES
|
|
|
|
|
bool "support extended attributes in device tables"
|
|
|
|
|
help
|
|
|
|
|
Support extended attributes handling in device tables
|
|
|
|
|
|
system: add options for /bin /sbin and /lib to be symlinks into /usr
systemd is increasingly expecting things to live in /usr/bin, /usr/sbin
or /usr/lib nad not in /bin, /sbin or /lib. It has inherited those
expectations from a Fedora change:
https://fedoraproject.org/wiki/Features/UsrMove
Note however, that systemd does support /usr being on a separate
filesystem; it just expects an initramfs to mount it before the final
switchroot over to the actual rootfs.
But the traditional use-case for Buildroot is not to boot with an
initramfs; although that is totally feasible, that's probably not what
is commonly done in the vast majority of cases.
However, a lot of packages still install stuff directly into /bin,
/sbin or /lib, which systemd may need early-on in the boot process,
even before it may have a chance to mount /usr. Even though we can
tell systemd, at configure-time, where it should expect programs to
be at runtime, it does not make sense to go head-first against an
upstream wa^Hill.
Add an option so that /bin, /sbin and /lib be symlinks to /usr/bin
and /usr/sbin. That option is forcibly enabled when the init system
is systemd.
Note: we need not handle /lib32 or /lib64, as they already are symlinks
to /lib, which means they will automatically be redirected to /usr/lib,
as /usr/lib32 and /usr/lib64 already are.
Furthermore, this means we're no longer supporting a split-usr setup, so
the corresponding configure options have been removed as well for
systemd and, when using a merged /usr, for eudev as well.
In Buildroot, we decided (with this patch) not to support a split-usr
when systemd is used as an init system. This is a design decision, not
a systemd issue. Thus the select is with BR2_INIT_SYSTEMD rather than
with BR2_PACKAGE_SYSTEMD.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Mike Williams <mike@mikebwilliams.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Tested-by: Mike Williams <mike@mikebwilliams.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-09-04 22:17:32 +02:00
|
|
|
config BR2_ROOTFS_MERGED_USR
|
|
|
|
|
bool "Use symlinks to /usr for /bin, /sbin and /lib"
|
|
|
|
|
help
|
|
|
|
|
If you say 'n' here, then /bin, /sbin and /lib and their
|
|
|
|
|
counterparts in /usr will be separate directories. This
|
|
|
|
|
is the historical UNIX way. In this case, /usr can be a
|
|
|
|
|
filesystem on a partition separate from / .
|
|
|
|
|
|
2018-04-01 07:08:44 +02:00
|
|
|
If you say 'y' here, then /bin, /sbin and /lib will be
|
|
|
|
|
symlinks to their counterparts in /usr. In this case, /usr can
|
|
|
|
|
not be a separate filesystem.
|
system: add options for /bin /sbin and /lib to be symlinks into /usr
systemd is increasingly expecting things to live in /usr/bin, /usr/sbin
or /usr/lib nad not in /bin, /sbin or /lib. It has inherited those
expectations from a Fedora change:
https://fedoraproject.org/wiki/Features/UsrMove
Note however, that systemd does support /usr being on a separate
filesystem; it just expects an initramfs to mount it before the final
switchroot over to the actual rootfs.
But the traditional use-case for Buildroot is not to boot with an
initramfs; although that is totally feasible, that's probably not what
is commonly done in the vast majority of cases.
However, a lot of packages still install stuff directly into /bin,
/sbin or /lib, which systemd may need early-on in the boot process,
even before it may have a chance to mount /usr. Even though we can
tell systemd, at configure-time, where it should expect programs to
be at runtime, it does not make sense to go head-first against an
upstream wa^Hill.
Add an option so that /bin, /sbin and /lib be symlinks to /usr/bin
and /usr/sbin. That option is forcibly enabled when the init system
is systemd.
Note: we need not handle /lib32 or /lib64, as they already are symlinks
to /lib, which means they will automatically be redirected to /usr/lib,
as /usr/lib32 and /usr/lib64 already are.
Furthermore, this means we're no longer supporting a split-usr setup, so
the corresponding configure options have been removed as well for
systemd and, when using a merged /usr, for eudev as well.
In Buildroot, we decided (with this patch) not to support a split-usr
when systemd is used as an init system. This is a design decision, not
a systemd issue. Thus the select is with BR2_INIT_SYSTEMD rather than
with BR2_PACKAGE_SYSTEMD.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Mike Williams <mike@mikebwilliams.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Tested-by: Mike Williams <mike@mikebwilliams.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-09-04 22:17:32 +02:00
|
|
|
|
2018-05-07 16:44:31 +02:00
|
|
|
if BR2_ROOTFS_SKELETON_DEFAULT
|
|
|
|
|
|
system: allow/disallow root login, accept encoded passwords
Currently, there are only two possibilities regarding the root account:
- it is enabled with no password (the default)
- it is enabled, using a clear-text, user-provided password
This is deemed insufficient in many cases, especially when the .config
file has to be published (e.g. for the GPL compliance, or any other
reason.).
Fix that in two ways:
- add a boolean option that allows/disallows root login altogether,
which defaults to 'y' to keep backward compatibility;
- accept already-encoded passwords, which we recognise as starting
with either of $1$, $5$ or $6$ (resp. for md5, sha256 or sha512).
Signed-off-by: Lorenzo M. Catucci <lorenzo@sancho.ccd.uniroma2.it>
[yann.morin.1998@free.fr:
- don't add a choice to select between clear-text/encoded password,
use a single prompt;
- differentiate in the password hook itself;
- rewrite parts of the help entry;
- rewrite and expand the commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: "Lorenzo M. Catucci" <lorenzo@sancho.ccd.uniroma2.it>
Acked-by: "Lorenzo M. Catucci" <lorenzo@sancho.ccd.uniroma2.it>
Tested-by: Gergely Imreh <imrehg@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-02 22:00:05 +02:00
|
|
|
config BR2_TARGET_ENABLE_ROOT_LOGIN
|
|
|
|
|
bool "Enable root login with password"
|
|
|
|
|
default y
|
package/skeleton: drop dependency on host-mkpasswd
Setting the root pasword is done in a target-finalize hook, so we do not
need to enforce a dependency from the skeleton onto host-mkpasswd.
Dropping that dependency will simplify making skeleton a virtual
package (in up-coming changes).
Instead, it is now selected as any other package. As such, it is
guaranteed to be built before target-finalize.
This however introduces a slight change in behaviour: previously,
host-mkpasswd would only be built if we needed to hash the root password
from its plain-text value. Now, host-mkpasswd is always built as soon as
the root password is non-empty, even if already pre-hashed.
Since host-mkpasswd is a really tiny weeny package bundled in Buildroot,
with only two C files, built as a single unit with a single gcc call,
the overhead is really minimal. Compared to the simplifications this
will allow in the skeleton packages (plural: common, sysv, systemd,
custom) to come, this overhead is acceptable.
Yet another simplification, even if small, to ease providing multiple
skeletons.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-25 23:14:23 +02:00
|
|
|
select BR2_PACKAGE_HOST_MKPASSWD if BR2_TARGET_GENERIC_ROOT_PASSWD != ""
|
system: allow/disallow root login, accept encoded passwords
Currently, there are only two possibilities regarding the root account:
- it is enabled with no password (the default)
- it is enabled, using a clear-text, user-provided password
This is deemed insufficient in many cases, especially when the .config
file has to be published (e.g. for the GPL compliance, or any other
reason.).
Fix that in two ways:
- add a boolean option that allows/disallows root login altogether,
which defaults to 'y' to keep backward compatibility;
- accept already-encoded passwords, which we recognise as starting
with either of $1$, $5$ or $6$ (resp. for md5, sha256 or sha512).
Signed-off-by: Lorenzo M. Catucci <lorenzo@sancho.ccd.uniroma2.it>
[yann.morin.1998@free.fr:
- don't add a choice to select between clear-text/encoded password,
use a single prompt;
- differentiate in the password hook itself;
- rewrite parts of the help entry;
- rewrite and expand the commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: "Lorenzo M. Catucci" <lorenzo@sancho.ccd.uniroma2.it>
Acked-by: "Lorenzo M. Catucci" <lorenzo@sancho.ccd.uniroma2.it>
Tested-by: Gergely Imreh <imrehg@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-02 22:00:05 +02:00
|
|
|
help
|
|
|
|
|
Allow root to log in with a password.
|
|
|
|
|
|
2018-04-01 07:08:44 +02:00
|
|
|
If not enabled, root will not be able to log in with a
|
|
|
|
|
password. However, if you have an ssh server and you add an
|
|
|
|
|
ssh key, you can still allow root to log in. Alternatively,
|
|
|
|
|
you can use sudo to become root.
|
system: allow/disallow root login, accept encoded passwords
Currently, there are only two possibilities regarding the root account:
- it is enabled with no password (the default)
- it is enabled, using a clear-text, user-provided password
This is deemed insufficient in many cases, especially when the .config
file has to be published (e.g. for the GPL compliance, or any other
reason.).
Fix that in two ways:
- add a boolean option that allows/disallows root login altogether,
which defaults to 'y' to keep backward compatibility;
- accept already-encoded passwords, which we recognise as starting
with either of $1$, $5$ or $6$ (resp. for md5, sha256 or sha512).
Signed-off-by: Lorenzo M. Catucci <lorenzo@sancho.ccd.uniroma2.it>
[yann.morin.1998@free.fr:
- don't add a choice to select between clear-text/encoded password,
use a single prompt;
- differentiate in the password hook itself;
- rewrite parts of the help entry;
- rewrite and expand the commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: "Lorenzo M. Catucci" <lorenzo@sancho.ccd.uniroma2.it>
Acked-by: "Lorenzo M. Catucci" <lorenzo@sancho.ccd.uniroma2.it>
Tested-by: Gergely Imreh <imrehg@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-02 22:00:05 +02:00
|
|
|
|
2013-01-05 05:52:02 +01:00
|
|
|
config BR2_TARGET_GENERIC_ROOT_PASSWD
|
|
|
|
|
string "Root password"
|
|
|
|
|
default ""
|
system: allow/disallow root login, accept encoded passwords
Currently, there are only two possibilities regarding the root account:
- it is enabled with no password (the default)
- it is enabled, using a clear-text, user-provided password
This is deemed insufficient in many cases, especially when the .config
file has to be published (e.g. for the GPL compliance, or any other
reason.).
Fix that in two ways:
- add a boolean option that allows/disallows root login altogether,
which defaults to 'y' to keep backward compatibility;
- accept already-encoded passwords, which we recognise as starting
with either of $1$, $5$ or $6$ (resp. for md5, sha256 or sha512).
Signed-off-by: Lorenzo M. Catucci <lorenzo@sancho.ccd.uniroma2.it>
[yann.morin.1998@free.fr:
- don't add a choice to select between clear-text/encoded password,
use a single prompt;
- differentiate in the password hook itself;
- rewrite parts of the help entry;
- rewrite and expand the commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: "Lorenzo M. Catucci" <lorenzo@sancho.ccd.uniroma2.it>
Acked-by: "Lorenzo M. Catucci" <lorenzo@sancho.ccd.uniroma2.it>
Tested-by: Gergely Imreh <imrehg@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-02 22:00:05 +02:00
|
|
|
depends on BR2_TARGET_ENABLE_ROOT_LOGIN
|
2013-01-05 05:52:02 +01:00
|
|
|
help
|
system: allow/disallow root login, accept encoded passwords
Currently, there are only two possibilities regarding the root account:
- it is enabled with no password (the default)
- it is enabled, using a clear-text, user-provided password
This is deemed insufficient in many cases, especially when the .config
file has to be published (e.g. for the GPL compliance, or any other
reason.).
Fix that in two ways:
- add a boolean option that allows/disallows root login altogether,
which defaults to 'y' to keep backward compatibility;
- accept already-encoded passwords, which we recognise as starting
with either of $1$, $5$ or $6$ (resp. for md5, sha256 or sha512).
Signed-off-by: Lorenzo M. Catucci <lorenzo@sancho.ccd.uniroma2.it>
[yann.morin.1998@free.fr:
- don't add a choice to select between clear-text/encoded password,
use a single prompt;
- differentiate in the password hook itself;
- rewrite parts of the help entry;
- rewrite and expand the commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: "Lorenzo M. Catucci" <lorenzo@sancho.ccd.uniroma2.it>
Acked-by: "Lorenzo M. Catucci" <lorenzo@sancho.ccd.uniroma2.it>
Tested-by: Gergely Imreh <imrehg@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-02 22:00:05 +02:00
|
|
|
Set the initial root password.
|
2013-04-29 12:29:33 +02:00
|
|
|
|
2018-04-01 07:08:44 +02:00
|
|
|
If set to empty (the default), then no root password will be
|
|
|
|
|
set, and root will need no password to log in.
|
2013-04-29 12:29:33 +02:00
|
|
|
|
2018-04-01 07:08:44 +02:00
|
|
|
If the password starts with any of $1$, $5$ or $6$, it is
|
|
|
|
|
considered to be already crypt-encoded with respectively md5,
|
|
|
|
|
sha256 or sha512. Any other value is taken to be a clear-text
|
|
|
|
|
value, and is crypt-encoded as per the "Passwords encoding"
|
|
|
|
|
scheme, above.
|
system: allow/disallow root login, accept encoded passwords
Currently, there are only two possibilities regarding the root account:
- it is enabled with no password (the default)
- it is enabled, using a clear-text, user-provided password
This is deemed insufficient in many cases, especially when the .config
file has to be published (e.g. for the GPL compliance, or any other
reason.).
Fix that in two ways:
- add a boolean option that allows/disallows root login altogether,
which defaults to 'y' to keep backward compatibility;
- accept already-encoded passwords, which we recognise as starting
with either of $1$, $5$ or $6$ (resp. for md5, sha256 or sha512).
Signed-off-by: Lorenzo M. Catucci <lorenzo@sancho.ccd.uniroma2.it>
[yann.morin.1998@free.fr:
- don't add a choice to select between clear-text/encoded password,
use a single prompt;
- differentiate in the password hook itself;
- rewrite parts of the help entry;
- rewrite and expand the commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: "Lorenzo M. Catucci" <lorenzo@sancho.ccd.uniroma2.it>
Acked-by: "Lorenzo M. Catucci" <lorenzo@sancho.ccd.uniroma2.it>
Tested-by: Gergely Imreh <imrehg@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-02 22:00:05 +02:00
|
|
|
|
2018-04-01 07:08:44 +02:00
|
|
|
Note: "$" signs in the hashed password must be doubled. For
|
|
|
|
|
example, if the hashed password is
|
|
|
|
|
"$1$longsalt$v35DIIeMo4yUfI23yditq0", then you must enter it
|
|
|
|
|
as "$$1$$longsalt$$v35DIIeMo4yUfI23yditq0" (this is necessary
|
|
|
|
|
otherwise make would attempt to interpret the $ as a variable
|
|
|
|
|
expansion).
|
2013-04-29 12:29:33 +02:00
|
|
|
|
2013-01-05 05:52:02 +01:00
|
|
|
WARNING! WARNING!
|
system: allow/disallow root login, accept encoded passwords
Currently, there are only two possibilities regarding the root account:
- it is enabled with no password (the default)
- it is enabled, using a clear-text, user-provided password
This is deemed insufficient in many cases, especially when the .config
file has to be published (e.g. for the GPL compliance, or any other
reason.).
Fix that in two ways:
- add a boolean option that allows/disallows root login altogether,
which defaults to 'y' to keep backward compatibility;
- accept already-encoded passwords, which we recognise as starting
with either of $1$, $5$ or $6$ (resp. for md5, sha256 or sha512).
Signed-off-by: Lorenzo M. Catucci <lorenzo@sancho.ccd.uniroma2.it>
[yann.morin.1998@free.fr:
- don't add a choice to select between clear-text/encoded password,
use a single prompt;
- differentiate in the password hook itself;
- rewrite parts of the help entry;
- rewrite and expand the commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: "Lorenzo M. Catucci" <lorenzo@sancho.ccd.uniroma2.it>
Acked-by: "Lorenzo M. Catucci" <lorenzo@sancho.ccd.uniroma2.it>
Tested-by: Gergely Imreh <imrehg@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-02 22:00:05 +02:00
|
|
|
The password appears as-is in the .config file, and may appear
|
2018-04-01 07:08:44 +02:00
|
|
|
in the build log! Avoid using a valuable password if either
|
|
|
|
|
the .config file or the build log may be distributed, or at
|
|
|
|
|
the very least use a strong cryptographic hash for your
|
|
|
|
|
password!
|
2013-01-05 05:52:02 +01:00
|
|
|
|
2014-10-12 15:36:22 +02:00
|
|
|
choice
|
|
|
|
|
bool "/bin/sh"
|
|
|
|
|
default BR2_SYSTEM_BIN_SH_DASH if !BR2_PACKAGE_BUSYBOX
|
|
|
|
|
help
|
|
|
|
|
Select which shell will provide /bin/sh.
|
|
|
|
|
|
|
|
|
|
# busybox has shells that work on noMMU
|
|
|
|
|
config BR2_SYSTEM_BIN_SH_BUSYBOX
|
|
|
|
|
bool "busybox' default shell"
|
|
|
|
|
depends on BR2_PACKAGE_BUSYBOX
|
|
|
|
|
|
|
|
|
|
config BR2_SYSTEM_BIN_SH_BASH
|
|
|
|
|
bool "bash"
|
|
|
|
|
depends on BR2_USE_MMU # bash
|
|
|
|
|
depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS
|
|
|
|
|
select BR2_PACKAGE_BASH
|
|
|
|
|
|
|
|
|
|
config BR2_SYSTEM_BIN_SH_DASH
|
|
|
|
|
bool "dash"
|
|
|
|
|
depends on BR2_USE_MMU # dash
|
|
|
|
|
depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS
|
|
|
|
|
select BR2_PACKAGE_DASH
|
|
|
|
|
|
2016-09-28 15:58:51 +02:00
|
|
|
config BR2_SYSTEM_BIN_SH_MKSH
|
|
|
|
|
bool "mksh"
|
|
|
|
|
depends on BR2_USE_MMU # mksh
|
|
|
|
|
depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS
|
|
|
|
|
select BR2_PACKAGE_MKSH
|
|
|
|
|
|
2014-10-12 15:36:22 +02:00
|
|
|
config BR2_SYSTEM_BIN_SH_ZSH
|
|
|
|
|
bool "zsh"
|
|
|
|
|
depends on BR2_USE_MMU # zsh
|
|
|
|
|
depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS
|
|
|
|
|
select BR2_PACKAGE_ZSH
|
|
|
|
|
|
2016-09-28 15:58:51 +02:00
|
|
|
comment "bash, dash, mksh, zsh need BR2_PACKAGE_BUSYBOX_SHOW_OTHERS"
|
2014-10-12 15:36:22 +02:00
|
|
|
depends on !BR2_PACKAGE_BUSYBOX_SHOW_OTHERS && BR2_PACKAGE_BUSYBOX
|
|
|
|
|
|
|
|
|
|
config BR2_SYSTEM_BIN_SH_NONE
|
|
|
|
|
bool "none"
|
|
|
|
|
|
|
|
|
|
endchoice # /bin/sh
|
|
|
|
|
|
|
|
|
|
config BR2_SYSTEM_BIN_SH
|
|
|
|
|
string
|
2015-06-16 22:42:28 +02:00
|
|
|
default "bash" if BR2_SYSTEM_BIN_SH_BASH
|
|
|
|
|
default "dash" if BR2_SYSTEM_BIN_SH_DASH
|
2016-09-28 15:58:51 +02:00
|
|
|
default "mksh" if BR2_SYSTEM_BIN_SH_MKSH
|
2015-06-16 22:42:28 +02:00
|
|
|
default "zsh" if BR2_SYSTEM_BIN_SH_ZSH
|
2014-10-12 15:36:22 +02:00
|
|
|
|
2015-09-02 01:10:34 +02:00
|
|
|
menuconfig BR2_TARGET_GENERIC_GETTY
|
2013-11-11 17:23:23 +01:00
|
|
|
bool "Run a getty (login prompt) after boot"
|
2023-10-09 17:17:27 +02:00
|
|
|
default y if !BR2_PACKAGE_PETITBOOT
|
2013-09-15 08:20:48 +02:00
|
|
|
|
|
|
|
|
if BR2_TARGET_GENERIC_GETTY
|
2009-03-20 22:59:43 +01:00
|
|
|
config BR2_TARGET_GENERIC_GETTY_PORT
|
2013-09-15 08:20:48 +02:00
|
|
|
string "TTY port"
|
2014-12-23 13:06:13 +01:00
|
|
|
default "console"
|
2010-12-05 21:53:14 +01:00
|
|
|
help
|
2013-09-15 08:20:48 +02:00
|
|
|
Specify a port to run a getty on.
|
2009-03-20 22:59:43 +01:00
|
|
|
|
|
|
|
|
choice
|
2013-09-15 08:20:48 +02:00
|
|
|
prompt "Baudrate"
|
2014-12-23 13:06:13 +01:00
|
|
|
default BR2_TARGET_GENERIC_GETTY_BAUDRATE_KEEP
|
2009-03-20 22:59:43 +01:00
|
|
|
help
|
|
|
|
|
Select a baudrate to use.
|
|
|
|
|
|
2009-04-15 15:42:12 +02:00
|
|
|
config BR2_TARGET_GENERIC_GETTY_BAUDRATE_KEEP
|
2013-11-11 17:23:23 +01:00
|
|
|
bool "keep kernel default"
|
2009-03-20 22:59:43 +01:00
|
|
|
config BR2_TARGET_GENERIC_GETTY_BAUDRATE_9600
|
|
|
|
|
bool "9600"
|
|
|
|
|
config BR2_TARGET_GENERIC_GETTY_BAUDRATE_19200
|
|
|
|
|
bool "19200"
|
|
|
|
|
config BR2_TARGET_GENERIC_GETTY_BAUDRATE_38400
|
|
|
|
|
bool "38400"
|
|
|
|
|
config BR2_TARGET_GENERIC_GETTY_BAUDRATE_57600
|
|
|
|
|
bool "57600"
|
|
|
|
|
config BR2_TARGET_GENERIC_GETTY_BAUDRATE_115200
|
|
|
|
|
bool "115200"
|
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
|
|
config BR2_TARGET_GENERIC_GETTY_BAUDRATE
|
|
|
|
|
string
|
2009-04-15 15:42:12 +02:00
|
|
|
default "0" if BR2_TARGET_GENERIC_GETTY_BAUDRATE_KEEP
|
2009-03-20 22:59:43 +01:00
|
|
|
default "9600" if BR2_TARGET_GENERIC_GETTY_BAUDRATE_9600
|
|
|
|
|
default "19200" if BR2_TARGET_GENERIC_GETTY_BAUDRATE_19200
|
|
|
|
|
default "38400" if BR2_TARGET_GENERIC_GETTY_BAUDRATE_38400
|
|
|
|
|
default "57600" if BR2_TARGET_GENERIC_GETTY_BAUDRATE_57600
|
|
|
|
|
default "115200" if BR2_TARGET_GENERIC_GETTY_BAUDRATE_115200
|
|
|
|
|
|
2012-12-13 01:28:11 +01:00
|
|
|
config BR2_TARGET_GENERIC_GETTY_TERM
|
2013-09-15 08:20:48 +02:00
|
|
|
string "TERM environment variable"
|
2012-12-13 01:28:11 +01:00
|
|
|
default "vt100"
|
package/openrc: add support for spawning getty
We install a template getty service, and we 'instantiate' it in the
default runlevel, using the configured tty.
Ideally, packages that provide a getty program would be responsible
for installing the corresponding service file. However, to keep
consistency with the existing init systems (busybox, systemd, and
sysv), so we do provide it from the openrc package itself.
OpenRC only acts on the files in a runlevel sub-directory, but the
documentation [0] actually suggests that the instance symlink be done
in init.d, and then again symlinked into the actual runlevel
sub-directory. So, we abide by the rules.
Also, to be noted, the getty service file is installed without ensuring
that a getty command is available. This again is not unlike other init
systems, sysvinit and busybox, which behave the same.
[0] https://wiki.gentoo.org/wiki/OpenRC
Signed-off-by: Michał Łyszczek <michal.lyszczek@bofc.pl>
[yann.morin.1998@free.fr:
- move getty template to openrc package (Thomas)
- fix namespace of the vaiables (Thomas)
- simplify creation of the defaults file
- rewrite commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-08-04 14:14:17 +02:00
|
|
|
# currently observed by all but systemd
|
|
|
|
|
depends on !BR2_INIT_SYSTEMD
|
2012-12-13 01:28:11 +01:00
|
|
|
help
|
|
|
|
|
Specify a TERM type.
|
2013-09-15 08:20:49 +02:00
|
|
|
|
|
|
|
|
config BR2_TARGET_GENERIC_GETTY_OPTIONS
|
|
|
|
|
string "other options to pass to getty"
|
|
|
|
|
default ""
|
package/openrc: add support for spawning getty
We install a template getty service, and we 'instantiate' it in the
default runlevel, using the configured tty.
Ideally, packages that provide a getty program would be responsible
for installing the corresponding service file. However, to keep
consistency with the existing init systems (busybox, systemd, and
sysv), so we do provide it from the openrc package itself.
OpenRC only acts on the files in a runlevel sub-directory, but the
documentation [0] actually suggests that the instance symlink be done
in init.d, and then again symlinked into the actual runlevel
sub-directory. So, we abide by the rules.
Also, to be noted, the getty service file is installed without ensuring
that a getty command is available. This again is not unlike other init
systems, sysvinit and busybox, which behave the same.
[0] https://wiki.gentoo.org/wiki/OpenRC
Signed-off-by: Michał Łyszczek <michal.lyszczek@bofc.pl>
[yann.morin.1998@free.fr:
- move getty template to openrc package (Thomas)
- fix namespace of the vaiables (Thomas)
- simplify creation of the defaults file
- rewrite commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-08-04 14:14:17 +02:00
|
|
|
# currently observed by all but systemd
|
|
|
|
|
depends on !BR2_INIT_SYSTEMD
|
2013-09-15 08:20:49 +02:00
|
|
|
help
|
|
|
|
|
Any other flags you want to pass to getty,
|
|
|
|
|
Refer to getty --help for details.
|
2013-09-15 08:20:48 +02:00
|
|
|
endif
|
2012-12-13 01:28:11 +01:00
|
|
|
|
2014-07-27 19:24:11 +02:00
|
|
|
config BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW
|
|
|
|
|
bool "remount root filesystem read-write during boot"
|
|
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
The root filesystem is typically mounted read-only at boot.
|
2018-04-01 07:08:44 +02:00
|
|
|
By default, buildroot remounts it in read-write mode early
|
|
|
|
|
during the boot process.
|
|
|
|
|
Say no here if you would rather like your root filesystem to
|
|
|
|
|
remain read-only.
|
2014-07-27 19:24:11 +02:00
|
|
|
If unsure, say Y.
|
|
|
|
|
|
2015-01-16 14:08:39 +01:00
|
|
|
config BR2_SYSTEM_DHCP
|
|
|
|
|
string "Network interface to configure through DHCP"
|
|
|
|
|
default ""
|
2019-08-04 14:14:19 +02:00
|
|
|
depends on BR2_PACKAGE_BUSYBOX || BR2_PACKAGE_IFUPDOWN || \
|
|
|
|
|
BR2_PACKAGE_SYSTEMD_NETWORKD || BR2_PACKAGE_NETIFRC
|
2015-01-16 14:08:39 +01:00
|
|
|
help
|
|
|
|
|
Enter here the name of the network interface (E.G. eth0) to
|
|
|
|
|
automatically configure through DHCP at bootup.
|
|
|
|
|
|
|
|
|
|
If left empty, no automatic DHCP requests will take place.
|
|
|
|
|
|
2018-04-01 07:08:44 +02:00
|
|
|
For more complicated network setups use an overlay to
|
|
|
|
|
overwrite /etc/network/interfaces or add a networkd
|
|
|
|
|
configuration file.
|
2015-01-16 14:08:39 +01:00
|
|
|
|
2019-08-04 14:14:19 +02:00
|
|
|
comment "automatic network configuration via DHCP needs ifupdown or busybox or networkd or netifrc"
|
|
|
|
|
depends on !(BR2_PACKAGE_BUSYBOX || BR2_PACKAGE_IFUPDOWN || \
|
|
|
|
|
BR2_PACKAGE_SYSTEMD_NETWORKD || BR2_PACKAGE_NETIFRC)
|
2015-01-16 14:08:39 +01:00
|
|
|
|
2016-07-17 10:44:27 +02:00
|
|
|
endif # BR2_ROOTFS_SKELETON_DEFAULT
|
|
|
|
|
|
2018-12-20 18:58:11 +01:00
|
|
|
config BR2_SYSTEM_DEFAULT_PATH
|
|
|
|
|
string "Set the system's default PATH"
|
2020-08-08 17:55:27 +02:00
|
|
|
default "/usr/bin:/usr/sbin" if BR2_ROOTFS_MERGED_USR
|
|
|
|
|
default "/bin:/sbin:/usr/bin:/usr/sbin" if !BR2_ROOTFS_MERGED_USR
|
2018-12-20 18:58:11 +01:00
|
|
|
help
|
|
|
|
|
Sets the system's default PATH. It is being used in
|
|
|
|
|
/etc/profile in the skeleton-init-common package and by some
|
|
|
|
|
daemons.
|
|
|
|
|
|
|
|
|
|
The default should work in most cases.
|
|
|
|
|
|
2016-08-03 00:19:40 +02:00
|
|
|
config BR2_ENABLE_LOCALE_PURGE
|
|
|
|
|
bool "Purge unwanted locales"
|
|
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
Explicitly specify what locales to install on target. If N
|
|
|
|
|
then all locales supported by packages are installed.
|
|
|
|
|
|
|
|
|
|
config BR2_ENABLE_LOCALE_WHITELIST
|
|
|
|
|
string "Locales to keep"
|
|
|
|
|
default "C en_US"
|
|
|
|
|
depends on BR2_ENABLE_LOCALE_PURGE
|
|
|
|
|
help
|
2022-11-27 14:07:15 +01:00
|
|
|
Whitespace separated list of locales to allow on target.
|
2016-08-03 00:19:40 +02:00
|
|
|
Locales not listed here will be removed from the target.
|
|
|
|
|
See 'locale -a' on your host for a list of locales available
|
|
|
|
|
on your build host, or have a look in /usr/share/locale in
|
|
|
|
|
the target file system for available locales.
|
|
|
|
|
|
|
|
|
|
Notice that listing a locale here doesn't guarantee that it
|
|
|
|
|
will be available on the target - That purely depends on the
|
|
|
|
|
support for that locale in the selected packages.
|
|
|
|
|
|
|
|
|
|
config BR2_GENERATE_LOCALE
|
|
|
|
|
string "Generate locale data"
|
|
|
|
|
default ""
|
|
|
|
|
depends on \
|
|
|
|
|
(BR2_TOOLCHAIN_BUILDROOT_UCLIBC && BR2_ENABLE_LOCALE) || \
|
|
|
|
|
BR2_TOOLCHAIN_USES_GLIBC
|
|
|
|
|
help
|
|
|
|
|
Generate support for a list of locales. Locales can be
|
|
|
|
|
specified with or without encoding, when no encoding is
|
|
|
|
|
specified, UTF-8 is assumed. Examples of locales: en_US,
|
|
|
|
|
fr_FR.UTF-8.
|
|
|
|
|
|
system: introduce BR2_SYSTEM_ENABLE_NLS
Until now, the option BR2_ENABLE_LOCALE was more-or-less controlling
whether NLS support was enabled in packages. More precisely, if
BR2_ENABLE_LOCALE=y, we were not doing anything (so some packages
could have NLS support enabled, some not). And only when
BR2_ENABLE_LOCALE was disabled we were explicitly passing
--disable-nls to packages.
This doesn't make much sense, and there is no reason to tie NLS
support to locale support. You may want locale support, but not
necessarily NLS support. Therefore, this commit introduces
BR2_SYSTEM_ENABLE_NLS, which allows to enable/disable NLS support
globally. When this option is enabled, we pass --enable-nls to
packages, otherwise we pass --disable-nls.
In addition, when this option is enabled and the C library doesn't
provide a full-blown implementation of gettext, we select the gettext
package, which will provide the full blown implementation.
It is worth mentioning that this commit has a visible impact for users:
- Prior to this commit, as soon as BR2_ENABLE_LOCALE=y, packages
*could* provide NLS support. It was up to each package to decide
whether they wanted to provide NLS support or not (we were not
passing --enable-nls nor --disable-nls).
- After this commit, it's BR2_SYSTEM_ENABLE_NLS that controls whether
NLS is enabled or disabled, and this option is disabled by default.
Bottom line: with the default of BR2_SYSTEM_ENABLE_NLS disabled, some
packages may lose NLS support that they used to provide. But we
believe it's a reasonable default behavior for Buildroot, where
generally NLS support is not necessary.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-04 16:47:49 +02:00
|
|
|
config BR2_SYSTEM_ENABLE_NLS
|
|
|
|
|
bool "Enable Native Language Support (NLS)"
|
|
|
|
|
depends on BR2_USE_WCHAR
|
|
|
|
|
# - glibc has built-in NLS support, but anyway doesn't
|
|
|
|
|
# support static linking
|
|
|
|
|
# - musl and uclibc support static linking, but they don't
|
|
|
|
|
# have built-in NLS support, which is provided by the
|
|
|
|
|
# libintl library from gettext. The fact that it is a
|
|
|
|
|
# separate library causes too many problems for static
|
|
|
|
|
# linking.
|
|
|
|
|
depends on !BR2_STATIC_LIBS
|
|
|
|
|
select BR2_PACKAGE_GETTEXT if !BR2_TOOLCHAIN_HAS_FULL_GETTEXT
|
|
|
|
|
help
|
|
|
|
|
This option will enable Native Language Support, which will
|
|
|
|
|
allow software packages to support translations.
|
|
|
|
|
|
|
|
|
|
comment "NLS support needs a toolchain w/ wchar, dynamic library"
|
|
|
|
|
depends on !BR2_USE_WCHAR || BR2_STATIC_LIBS
|
|
|
|
|
|
2014-04-07 21:58:03 +02:00
|
|
|
config BR2_TARGET_TZ_INFO
|
|
|
|
|
bool "Install timezone info"
|
2014-04-07 21:58:08 +02:00
|
|
|
select BR2_PACKAGE_TZDATA if BR2_TOOLCHAIN_USES_GLIBC
|
2016-08-09 22:25:55 +02:00
|
|
|
select BR2_PACKAGE_TZDATA if BR2_TOOLCHAIN_USES_MUSL
|
2014-04-07 21:58:08 +02:00
|
|
|
select BR2_PACKAGE_TZ if BR2_TOOLCHAIN_USES_UCLIBC
|
2014-04-07 21:58:03 +02:00
|
|
|
help
|
|
|
|
|
Say 'y' here to install timezone info.
|
|
|
|
|
|
|
|
|
|
if BR2_TARGET_TZ_INFO
|
|
|
|
|
|
|
|
|
|
config BR2_TARGET_TZ_ZONELIST
|
|
|
|
|
string "timezone list"
|
|
|
|
|
default "default"
|
|
|
|
|
help
|
|
|
|
|
Space-separated list of time zones to compile.
|
|
|
|
|
|
2018-04-01 07:08:44 +02:00
|
|
|
The value "default" includes all commonly used time zones.
|
|
|
|
|
Note that this set consumes around 5.5M for glibc and 2.1M for
|
|
|
|
|
uClibc.
|
2014-04-07 21:58:03 +02:00
|
|
|
|
2018-04-01 07:08:44 +02:00
|
|
|
The full list is the list of files in the time zone database
|
|
|
|
|
source, not including the build and .tab files.
|
2014-04-07 21:58:03 +02:00
|
|
|
|
2014-04-07 21:58:04 +02:00
|
|
|
config BR2_TARGET_LOCALTIME
|
|
|
|
|
string "default local time"
|
2015-02-12 14:49:31 +01:00
|
|
|
default "Etc/UTC"
|
2014-04-07 21:58:04 +02:00
|
|
|
help
|
2018-04-01 07:08:44 +02:00
|
|
|
The time zone to install as the default local time, expressed
|
|
|
|
|
as a tzdata location, such as:
|
2017-07-04 08:56:39 +02:00
|
|
|
Etc/UTC (the default)
|
2014-04-07 21:58:04 +02:00
|
|
|
GMT
|
|
|
|
|
Europe/Paris
|
|
|
|
|
America/New_York
|
|
|
|
|
Pacific/Wallis
|
|
|
|
|
...
|
|
|
|
|
|
2019-11-16 10:10:04 +01:00
|
|
|
Set to empty to not install a default time zone.
|
|
|
|
|
|
2014-04-07 21:58:03 +02:00
|
|
|
endif # BR2_TARGET_TZ_INFO
|
|
|
|
|
|
2014-04-20 19:33:09 +02:00
|
|
|
config BR2_ROOTFS_USERS_TABLES
|
|
|
|
|
string "Path to the users tables"
|
|
|
|
|
help
|
|
|
|
|
Specify a space-separated list of users table locations,
|
|
|
|
|
that will be passed to the mkusers utility to create
|
|
|
|
|
users on the system, with home directory, password, etc.
|
|
|
|
|
|
|
|
|
|
See manual for details on the usage and syntax of these files.
|
|
|
|
|
|
2013-02-05 08:16:00 +01:00
|
|
|
config BR2_ROOTFS_OVERLAY
|
|
|
|
|
string "Root filesystem overlay directories"
|
|
|
|
|
default ""
|
|
|
|
|
help
|
|
|
|
|
Specify a list of directories that are copied over the target
|
|
|
|
|
root filesystem after the build has finished and before it is
|
|
|
|
|
packed into the selected filesystem images.
|
|
|
|
|
|
2018-04-01 07:08:44 +02:00
|
|
|
They are copied as-is into the rootfs, excluding files ending
|
|
|
|
|
with ~ and .git, .svn and .hg directories.
|
2013-02-05 08:16:00 +01:00
|
|
|
|
2020-01-22 00:09:56 +01:00
|
|
|
config BR2_ROOTFS_PRE_BUILD_SCRIPT
|
|
|
|
|
string "Custom scripts to run before commencing the build"
|
|
|
|
|
default ""
|
|
|
|
|
help
|
|
|
|
|
Specify a space-separated list of scripts to be run before the
|
|
|
|
|
build commences.
|
|
|
|
|
|
|
|
|
|
This gives users the opportunity to do board-specific
|
|
|
|
|
preparations before starting the build.
|
|
|
|
|
|
2011-05-12 23:37:35 +02:00
|
|
|
config BR2_ROOTFS_POST_BUILD_SCRIPT
|
2013-02-07 12:58:48 +01:00
|
|
|
string "Custom scripts to run before creating filesystem images"
|
2011-05-12 23:37:35 +02:00
|
|
|
default ""
|
|
|
|
|
help
|
2018-04-01 07:08:44 +02:00
|
|
|
Specify a space-separated list of scripts to be run after the
|
|
|
|
|
build has finished and before Buildroot starts packing the
|
|
|
|
|
files into selected filesystem images.
|
2011-05-12 23:37:35 +02:00
|
|
|
|
2018-04-01 07:08:44 +02:00
|
|
|
This gives users the opportunity to do board-specific
|
|
|
|
|
cleanups, add-ons and the like, so the generated files can be
|
|
|
|
|
used directly without further processing.
|
2011-05-12 23:37:35 +02:00
|
|
|
|
2018-04-01 07:08:44 +02:00
|
|
|
These scripts are called with the target directory name as
|
|
|
|
|
first argument. Make sure the exit code of those scripts are
|
|
|
|
|
0, otherwise make will stop after calling them.
|
2011-05-12 23:37:35 +02:00
|
|
|
|
2016-07-03 17:08:19 +02:00
|
|
|
config BR2_ROOTFS_POST_FAKEROOT_SCRIPT
|
|
|
|
|
string "Custom scripts to run inside the fakeroot environment"
|
|
|
|
|
default ""
|
|
|
|
|
help
|
|
|
|
|
Specify a space-separated list of scripts to be run at the end
|
|
|
|
|
of the fakeroot script right before the image(s) are actually
|
|
|
|
|
generated.
|
|
|
|
|
|
|
|
|
|
This gives users the opportunity to do customisations of the
|
|
|
|
|
content of the rootfs, which would otherwise require root
|
2016-10-10 15:45:59 +02:00
|
|
|
rights.
|
2016-07-03 17:08:19 +02:00
|
|
|
|
|
|
|
|
These scripts are called with the target directory name as
|
|
|
|
|
first argument. The build will fail on the first scripts that
|
|
|
|
|
exits with a non-zero exit code.
|
|
|
|
|
|
|
|
|
|
Note that Buildroot already provides mechanisms to customise
|
|
|
|
|
the content of the rootfs:
|
|
|
|
|
|
|
|
|
|
- BR2_ROOTFS_STATIC_DEVICE_TABLE
|
|
|
|
|
to create arbitrary entries statically in /dev
|
|
|
|
|
|
|
|
|
|
- BR2_ROOTFS_DEVICE_TABLE
|
2018-04-01 07:08:44 +02:00
|
|
|
to set arbitrary permissions as well as extended
|
|
|
|
|
attributes (such as capabilities) on files and
|
|
|
|
|
directories,
|
2016-07-03 17:08:19 +02:00
|
|
|
|
|
|
|
|
- BR2_ROOTFS_USERS_TABLES:
|
|
|
|
|
to create arbitrary users and their home directories
|
|
|
|
|
|
|
|
|
|
It is highly recommended to use those mechanisms if possible,
|
|
|
|
|
rather than using custom fakeroot scripts.
|
|
|
|
|
|
2013-02-07 12:58:43 +01:00
|
|
|
config BR2_ROOTFS_POST_IMAGE_SCRIPT
|
|
|
|
|
string "Custom scripts to run after creating filesystem images"
|
|
|
|
|
default ""
|
|
|
|
|
help
|
|
|
|
|
Specify a space-separated list of scripts to be run after
|
|
|
|
|
the build has finished and after Buildroot has packed the
|
|
|
|
|
files into selected filesystem images.
|
|
|
|
|
|
|
|
|
|
This can for example be used to call a tool building a
|
|
|
|
|
firmware image from different images generated by Buildroot,
|
|
|
|
|
or automatically extract the tarball root filesystem image
|
|
|
|
|
into some location exported by NFS, or any other custom
|
|
|
|
|
action.
|
|
|
|
|
|
|
|
|
|
These scripts are called with the images directory name as
|
2013-07-10 00:00:31 +02:00
|
|
|
first argument. The script is executed from the main Buildroot
|
|
|
|
|
source directory as the current directory.
|
|
|
|
|
|
|
|
|
|
config BR2_ROOTFS_POST_SCRIPT_ARGS
|
2016-07-03 17:08:19 +02:00
|
|
|
string "Extra arguments passed to custom scripts"
|
2024-03-28 21:32:31 +01:00
|
|
|
depends on BR2_ROOTFS_PRE_BUILD_SCRIPT != "" \
|
|
|
|
|
|| BR2_ROOTFS_POST_BUILD_SCRIPT != "" \
|
2016-07-03 17:08:19 +02:00
|
|
|
|| BR2_ROOTFS_POST_FAKEROOT_SCRIPT != "" \
|
|
|
|
|
|| BR2_ROOTFS_POST_IMAGE_SCRIPT != ""
|
2013-07-10 00:00:31 +02:00
|
|
|
help
|
2024-03-28 21:32:31 +01:00
|
|
|
Pass these additional arguments to each pre-build, post-build,
|
|
|
|
|
post-fakeroot and post-image scripts.
|
2013-07-10 00:00:31 +02:00
|
|
|
|
2018-04-01 07:08:44 +02:00
|
|
|
Note that all the post-build and post-image scripts will be
|
|
|
|
|
passed the same set of arguments, you can not pass different
|
|
|
|
|
arguments to each script.
|
2013-07-10 00:00:31 +02:00
|
|
|
|
2018-04-01 07:08:44 +02:00
|
|
|
Note also, as stated in their respective help text, that the
|
|
|
|
|
first argument to each post-build or post-image script is the
|
|
|
|
|
target directory / images directory. The arguments in this
|
|
|
|
|
option will be passed *after* those.
|
2013-02-07 12:58:43 +01:00
|
|
|
|
2010-12-05 21:52:44 +01:00
|
|
|
endmenu
|
