Currently, we pass BR2_ROOTFS_POST_SCRIPT_ARGS to each of the scripts in
BR2_ROOTFS_PRE_BUILD_SCRIPT, but the option is not exposed in menuconfig
when only pre-build scripts are used.
Add the pre-build scripts to the condition exposing the extra args
option.
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 96b3295ca1)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix issues spotted by Yann E. Morin in commit
ca169d1d0a:
- BR2_TOOLCHAIN_BUILDROOT_UCLIBC -> BR2_TOOLCHAIN_USES_UCLIBC
- Add dependency to openrc package and not only to init system
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
openrc raises the following uclibc build failures since bump to version
0.51 in commit 730c90faa3:
../src/rc-abort/rc-abort.c: In function 'main':
../src/rc-abort/rc-abort.c:27:21: error: implicit declaration of function 'kill'; did you mean 'killpg'? [-Werror=implicit-function-declaration]
27 | if (kill(pid, SIGUSR1) != 0)
| ^~~~
| killpg
../src/libeinfo/libeinfo.c: In function 'colour_terminal':
../src/libeinfo/libeinfo.c:319:26: error: implicit declaration of function 'fileno' [-Werror=implicit-function-declaration]
319 | if (f && !isatty(fileno(f)))
| ^~~~~~
../src/librc/librc-misc.c: In function 'rc_getfile':
../src/librc/librc-misc.c:79:14: error: implicit declaration of function 'fileno'; did you mean 'd_fileno'? [-Werror=implicit-function-declaration]
79 | fd = fileno(fp);
| ^~~~~~
| d_fileno
../src/librc/librc-daemon.c: In function 'rc_service_daemons_crashed':
../src/librc/librc-daemon.c:633:37: error: implicit declaration of function 'kill'; did you mean 'killpg'? [-Werror=implicit-function-declaration]
633 | if (kill(pid, 0) == -1 && errno == ESRCH)
| ^~~~
| killpg
These build failures could be fixed by patching openrc but upstream
is not happy with this patch: https://github.com/OpenRC/openrc/pull/674.
So, as advised by Yann E. Morin, openrc is hidden away for uClibc, until
upstream has a proper fix.
Fixes:
- http://autobuild.buildroot.org/results/494ef392a971ddb3c5c7b01e0149c6439018dbe7
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Display the petitboot UI instead of a login prompt, allowing the
configuration of custom tty(s) as we do for the login prompt.
petitboot already depends on udev, so let's use it instead of rcS to
launch pb-console. This has the advantage of easily wildcarding the list
of ttys ("hvc*") and enables hotplug devices ("ttyUSB0").
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
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>
Currently, we have a single solution to handle the /var content on a
read-only root filesystem, and users can opt out of using it.
We're going to introduce another solution (based on an overlayfs), which
is incompatible with using the factory, so we'll have a choice of three
mutually exclusive options.
Introduce that choice now with just the existing /var factory, and a new
option to opt out of it.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
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>
Acked-by: Norbert Lange <nolange79@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
The recent update to systemd v254 requires a toolchain w/ linux headers
>= 4.14 to provide LOOP_SET_BLOCK_SIZE [1] (added in systemd v253 [2]).
Note:
Buildroot already warn the user if a toolchain w/ linux headers < 4.15
is used while enabling systemd as init system [3]. It was matter of
time before problem occurs.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=89e4fdecb51cf5535867026274bc97de9480ade5
[2] 1163ddb386
[3] 9a095643b4
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
To quote the README:
> Kernel versions below 4.15 have significant gaps in functionality and
> are not recommended for use with this version of systemd. Taint flag
> 'old-kernel' will be set. Systemd will most likely still function, but
> upstream support and testing are limited.
Signed-off-by: Norbert Lange <nolange79@gmail.com>
Reviewed-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Following files changed *license* from CC0-1.0 to MIT-0:
- src/systemctl/systemd-sysv-install.SKELETON
- config files
- examples under /network
The file LICENSES/MIT-0.txt has been added for this reason,
hashes added, corrected for LICENSES/README.md.
Kernel version 3.15 is now the bare minimum, but only
version 4.15 and higher are fully supported and tested:
- bump kernel header dependencies
- correct kconfig description
- improvements to make the kconfig description better reflect
the information from the README
Set new options to their default, remove -Defi-cc option.
Set -Ddbus=false to ensure dbus dependency is runtime only.
Set -Ddbus-interfaces-dir=no as interface XML file generation is
not supported when cross compiling.
Set -Ddefault-user-shell=/bin/sh to the always available shell.
Signed-off-by: Norbert Lange <nolange79@gmail.com>
Reviewed-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Commit "bf3626002f system cfg: remove mkpasswd MD5 format option", from
release 2019.02, moved the symbol to legacy handling, but the symbol is
still referenced.
Remove the reference to it.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
seperate is a common misspelling of separate
Fix all the typos in the tree that are not related to patch files.
CHANGES
seperate -> separate, in the list of changes
Config.in.legacy
seperate -> separate, in option name and help texts
package/leafnode2/leafnode2.mk
seperate -> separate, in a comment
system/Config.in
seperated -> separated, in a help text
Cc: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
This adds the option to set systemd's default.target in
the System Configuration subheading if systemd is
specified as the init system.
The argument for default.target is specified pre-build
as opposed to overriding the hardcoded "multi-user.target"
symlink with post-build scripts or a rootfs overlay
Signed-off-by: Sen Hastings <sen@phobosdpl.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
We changed the skeletons in bf01e51f3c, so that var/lock
points to run/lock. This resulted in build failures as
some packages want to work with these paths.
- Create run/lock, the run directory will be purged
later anyway (since 5e78e7e97d).
- for init == systemd, create the var/lock symlink early
to prevent packages creating this path as directory.
Fixes:
http://autobuild.buildroot.net/results/3ee/3ee8f9ee55e51af38e9dbe7b9840c9589d88a30f
Signed-off-by: Norbert Lange <nolange79@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Commit eb49354eb3 updated systemd's
minimal kernel headers version to 3.13, but forgot to update the
dependencies of BR2_INIT_SYSTEMD.
Update BR2_INIT_SYSTEMD kernel headers dependency to 3.13.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
We introduce the concept of a pre-build script that works similar to
the already existing post-build and post-image scripts.
The pre-build script(s) are executed before the build commences. This
allows a user to run some preperatory tasks prior to the build.
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Some externals may wish to provide custom init systems for tightly
integrated boot. This has been supported through the BR2_INIT_NONE,
however a downside to the BR2_INIT_NONE is it forces the custom init
system to use either skeleton-custom and roll a custom skeleton for
each target, or skeleton-init-none which isn't a complete skeleton.
Allowing br2-external to define custom BR2_INIT_* means they can now
safely 'select' the BR2_PACKAGE_SKELETON_INIT_*, and re-use any of the
skeletons in Buildroot, or one from a br2-external tree.
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
In preparation for supporting br2-external inits, move the 'select' for
the BR2_PACKAGE_SKELETON_INIT_* to their respective init systems. This
will allow a br2-external init to 'select' which skeleton it needs as a
default skeleton.
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
[yann.morin.1998@free.fr:
- add comment to init choice, to remind why selecting skeletons is OK
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Today, the BR2_ROOTFS_SKELETON_CUSTOM is the only way to build a custom
skeleton. But it's limiting as users must provide a pre-built skeleton
for each target. Supporting a br2-external package allows users to build
up a skeleton and customize it with their own KConfig options.
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Use "/usr/bin:/usr/sbin" as the default path if BR2_ROOTFS_MERGED_USR
is enabled, otherwise use "/bin:/sbin:/usr/bin:/usr/sbin".
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Currently, we define the so-called "overflow group" as 'nogroup'.
However, one practical issue is that systemd-sysusers will otherwise
create a 'nobody' group with gid 999, because that's is what is usual to
define the overflow group: users and groups are defined in LSB (Linux
Standard Base):
https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/usernames.html
Quoting: "If the username exists on a system,then they should be in the
suggested corresponding group".
Only Debian and derivatives depart from this custom, naming it 'nogroup'
(hence the rationale for commit 908198e756 (system/skeleton: remove
spurious group 'nobody').
See also commit 9c67af2c52 (system/skeleton: use uid/gid 65534 for
nobody/nogroup), and a related discussion on LWN.net (key is "overflow
UID" which also applies to GID):
https://lwn.net/Articles/695478/
Use the recommended groupname 'nobody'. Adapt packages accordingly.
Signed-off-by: Norbert Lange <nolange79@gmail.com>
[yann.morin.1998@free.fr:
- reword commit log
- extend commit log with more references (commits and LWN)
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
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>
The default inittab files added by busybox and sysvinit run 'swapon -a'
during init and 'swapoff -a' during shutdown.
But, the swapon/swapoff programs are not guaranteed to be
available. For the busybox versions, it is steered by
CONFIG_SWAPON/CONFIG_SWAPOFF. For the util-linux versions, it is steered by
BR2_PACKAGE_UTIL_LINUX_BINARIES.
In a case where swapon/swapoff is not available but the inittab tries to
execute them, the boot log would be polluted by error messages like:
swapon: not found
Avoid this by commenting out the swapon/swapoff lines if the swapon/swapoff
binaries are not available.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
[Peter: test with -x]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In gcc 5.1.0, a change was introduced which causes internal search paths
inside the sysroot to be relative to 'lib64' rather than 'lib'. See [1] [2]
and [3].
For example for dtc:
LD convert-dtsv0
/opt/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64-octeon-linux-gnu/7.3.0/../../../../mips64-octeon-linux-gnu/bin/ld: cannot find crt1.o: No such file or directory
/opt/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64-octeon-linux-gnu/7.3.0/../../../../mips64-octeon-linux-gnu/bin/ld: cannot find crti.o: No such file or directory
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:236: convert-dtsv0] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/opt/buildroot/output/build/dtc-1.4.7'
make: *** [package/pkg-generic.mk:241: /opt/buildroot/output/build/dtc-1.4.7/.stamp_built] Error 2
In this case, crt1.o was searched for in following locations:
16073 access("/opt/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64-octeon-linux-gnu/7.3.0/n32/octeon3/crt1.o", R_OK) = -1 ENOENT (No such file or directory)
16073 access("/opt/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/n32/octeon3/crt1.o", R_OK) = -1 ENOENT (No such file or directory)
16073 access("/opt/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64-octeon-linux-gnu/7.3.0/../../../../mips64-octeon-linux-gnu/lib/mips64-octeon-linux-gnu/7.3.0/n32/octeon3/crt1.o", R_OK) = -1 ENOENT (No such file or directory)
16073 access("/opt/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64-octeon-linux-gnu/7.3.0/../../../../mips64-octeon-linux-gnu/lib/../lib32-fp/crt1.o", R_OK) = -1 ENOENT (No such file or directory)
16073 access("/opt/buildroot/output/host/mips64-buildroot-linux-gnu/sysroot/lib64/mips64-octeon-linux-gnu/7.3.0/n32/octeon3/crt1.o", R_OK) = -1 ENOENT (No such file or directory)
16073 access("/opt/buildroot/output/host/mips64-buildroot-linux-gnu/sysroot/lib64/../lib32-fp/crt1.o", R_OK) = -1 ENOENT (No such file or directory)
16073 access("/opt/buildroot/output/host/mips64-buildroot-linux-gnu/sysroot/usr/lib64/mips64-octeon-linux-gnu/7.3.0/n32/octeon3/crt1.o", R_OK) = -1 ENOENT (No such file or directory)
16073 access("/opt/buildroot/output/host/mips64-buildroot-linux-gnu/sysroot/usr/lib64/../lib32-fp/crt1.o", R_OK) = -1 ENOENT (No such file or directory)
16073 access("/opt/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64-octeon-linux-gnu/7.3.0/crt1.o", R_OK) = -1 ENOENT (No such file or directory)
16073 access("/opt/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/crt1.o", R_OK) = -1 ENOENT (No such file or directory)
16073 access("/opt/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64-octeon-linux-gnu/7.3.0/../../../../mips64-octeon-linux-gnu/lib/mips64-octeon-linux-gnu/7.3.0/crt1.o", R_OK) = -1 ENOENT (No such file or directory)
16073 access("/opt/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/mips64-octeon-linux-gnu/7.3.0/../../../../mips64-octeon-linux-gnu/lib/crt1.o", R_OK) = -1 ENOENT (No such file or directory)
16073 access("/opt/buildroot/output/host/mips64-buildroot-linux-gnu/sysroot/lib64/mips64-octeon-linux-gnu/7.3.0/crt1.o", R_OK) = -1 ENOENT (No such file or directory)
16073 access("/opt/buildroot/output/host/mips64-buildroot-linux-gnu/sysroot/lib64/crt1.o", R_OK) = -1 ENOENT (No such file or directory)
16073 access("/opt/buildroot/output/host/mips64-buildroot-linux-gnu/sysroot/usr/lib64/mips64-octeon-linux-gnu/7.3.0/crt1.o", R_OK) = -1 ENOENT (No such file or directory)
16073 access("/opt/buildroot/output/host/mips64-buildroot-linux-gnu/sysroot/usr/lib64/crt1.o", R_OK) = -1 ENOENT (No such file or directory)
As can be seen above, all attempted paths contain 'lib64' as base,
instead of 'lib' or 'lib32', e.g.
.../sysroot/lib64/../lib32-fp/crt1.o
.../sysroot/lib64/crt1.o
This problem was detected on a gcc 7.x toolchain provided by Marvell as part
of their Octeon SDK. For this toolchain, here are the values of the paths
as detected by the Buildroot toolchain logic, for two different Octeon
processors:
- octeon2 (soft-float) (-mabi=n32 -march=octeon2):
SYSROOT_DIR=/opt/buildroot/output/host/opt/ext-toolchain/mips64-octeon-linux-gnu/sys-root/;
ARCH_SYSROOT_DIR=/opt/buildroot/output/host/opt/ext-toolchain/mips64-octeon-linux-gnu/sys-root/;
ARCH_SUBDIR=;
ARCH_LIB_DIR=lib32/octeon2;
SUPPORT_LIB_DIR=/opt/buildroot/output/host/opt/ext-toolchain/mips64-octeon-linux-gnu/lib32/octeon2/
- octeon3 (hard-float) (-mabi=n32 -march=octeon3):
SYSROOT_DIR=/opt/buildroot/output/host/opt/ext-toolchain/mips64-octeon-linux-gnu/sys-root/;
ARCH_SYSROOT_DIR=/opt/buildroot/output/host/opt/ext-toolchain/mips64-octeon-linux-gnu/sys-root/;
ARCH_SUBDIR=;
ARCH_LIB_DIR=lib32-fp;
SUPPORT_LIB_DIR=/opt/buildroot/output/host/opt/ext-toolchain/mips64-octeon-linux-gnu/lib32-fp/
For both cases (MIPS64n32) Buildroot created a symlink 'lib32->lib', from
SYSTEM_LIB_SYMLINK in system/system.mk. Additionally, the function
create_lib_symlinks in
toolchain/toolchain-external/pkg-toolchain-external.mk will use ARCH_LIB_DIR
and create an additional link $(ARCH_LIB_DIR)->lib.
For the Octeon3 case this thus results in the following symlinks (where the
'lib32' one is normally not needed):
lib32 -> lib/
lib32-fp -> lib/
Since the toolchain is searching based on a 'lib64' component, it will fail
to find its internal paths.
To solve the problem, we need to create an additional symlink 'lib64':
lib64 -> lib/
[1] 257ccd463a
[2] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg03377.html
[3] https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00539.html
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
It is valid that there is no system-wide default time zone defined, in
which case Etc/UTC is assumed.
Fixes: #12316
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Martin Bark <martin@barkynet.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Richard Braun <rbraun@sceen.net>
Cc: Andrew Trapani <andrew.trapani@ontera.bio>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch makes openrc-netifrc package aware of BR2_SYSTEM_DHCP
config, and if set, will start dhcp daemon on configured interface.
Signed-off-by: Michał Łyszczek <michal.lyszczek@bofc.pl>
[yann.morin.1998@free.fr:
- simplify condition for BR2_SYSTEM_DHCP
- reword commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
We couldn't track down the reason why the profile sets $PAGER other
than that it has always been there.
However, it defeats pager autodetection by various tool (systemctl,
nmcli, etc.) that would otherwise prefer less to more, in case both
were available.
Let's drop it. My desktop Linux distro (Fedora) doesn't seem to set it
either and the universe doesn't seem to have collapsed yet.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This is very basic settings for openrc init.
* system/Config.in
Allows to select openrc as init system (which auto selects
openrc-skeleton and openrc package).
* package/ifupdown-scripts/Config.in
openrc has its own service to bring up/down interfaces, so
ifupdown-scripts should not be enabled when openrc is enabled to
prevent service clash.
Signed-off-by: Michał Łyszczek <michal.lyszczek@bofc.pl>
[Thomas: take into account the !BR2_STATIC_LIBS dependency]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The fields in /etc/shadow were set as follows:
root::10933:0:99999:7:::
This sets the date of last password change to Jan 1, 2000, the minimum
password age to 0 days, the maximum password age to near-infinity, and a
warning period of 7 days. In practice, this means the password never
expires. So all of this is quite useless.
On the other hand, mkusers creates lines without all of these options.
It just sets ::::: which disables password expiration completely.
To make things consistent, do the same for the skeleton entries.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
If the user is brave enough to use a custom rootfs skeleton then we must
not prevent using merged /usr too. Actually it is already possible to do
this, although indirectly, by selecting BR2_INIT_SYSTEMD.
Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
We substitute the path specified in system/skeleton/etc/profile with
the path specified in the configuration variable
$(BR2_SYSTEM_DEFAULT_PATH).
$(BR2_SYSTEM_DEFAULT_PATH) is a Kconfig string, so it is already
double quoted. This means that export PATH=value will now be export
PATH="value" in /etc/profile, which is perfectly fine.
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Thomas: rework commit log about the double quoting]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The configuration option BR2_SYSTEM_DEFAULT_PATH allows the user to
override the default path, which can be used by /etc/profile and some
system daemons.
It defaults to the value previously hard-coded in /etc/profile. This
default should be suitable for most users.
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
As SHA256 is now default, removing weak MD5 option. C libraries now
all support the SHA methods.
glibc 2.7+
uclibc (bdd8362a88 package/uclibc: defconfig: enable sha-256...)
musl 1.1.14+
One issue this would prevent, is a host tool issue with a FIPS enabled
system where weak ciphers/methods are disabled. It seems the crypt(3)
call is impacted by /proc/sys/crypto/fips_enabled (per crypt(3) man
page). It results in mkpasswd returning "(EPERM) crypt failed."
Rather then create a Buildroot host dependency check, this patch
removes the potential corner case from being selected.
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch changes the default mkpasswd method to SHA256 from MD5.
The change both improves the quality of the hash used and prepares
for eventually removing MD5 as a option.
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch drops the comment about checking the C libraries version as
they now all support it by default
glibc 2.7+
uclibc (bdd8362a88 package/uclibc: defconfig: enable sha-256...)
musl 1.1.14+
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since version v239, systemd-nspawn unconditioanlly uses prlimit(2),
which is not implemented in uClibc-ng. systemd-nspawn can not be
disabled.
This makes systemd glibc-only again.
After a bit of discussion with upstream (om IRC), it looks very
improbable that they accept a patch making systemd-nspawn optional.
They would probably consider a patch that provides that syscall wrapper
if it is missing, though, but that's less trivial...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Waldemar Brodkorb <wbx@openadk.org>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit 879fa7f82a, the
BR2_INIT_SYSTEMD option was changed to allow selecting with a uClibc
toolchain. Unfortunately, the corresponding Config.in comment, which
was already bogus, was not updated to take into account the numerous
dependencies of BR2_INIT_SYSTEMD.
Due to this, even if you have uClibc enabled, the BR2_INIT_SYSTEMD
option may not be visible, and the Config.in comment may also not be
visible, leaving the user in the dark.
This commit fixes the dependencies of the Config.in comment so that
they match the one of the BR2_INIT_SYSTEMD option.
Reported-by: Raphael Jacob <r.jacob2002@gmail.com>
Cc: Raphael Jacob <r.jacob2002@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The PAGER environment variable is including a blank character at the
end. Remove this.
A for loop has been unsetting the variable inside the loop, this is only
needed once at the end of the loop.
Signed-off-by: Florian La Roche <F.LaRoche@pilz.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Some applications, e.g. bashs process subsitution feature, rely on the
convention of `/dev/fd` being a symbolic link to `/proc/self/fd`.
When a static /dev is used on a readonly rootfs then the runtime ln
invocations in the inittab will fail, so we need to add the symlinks at
build time. Makedevs doesn't support creating symlinks, so instead add the
symlinks to the default skeleton.
For non-static /dev setups, the kernel will mount devtmpfs which shadows the
/dev of the rootfs, but then the runtime ln invocations in inittab will
create the symlinks.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
We need to disable any systemd parts using either IDN, NSS or gshadow.
IDN is only disabled in C library function call to getnameinfo(),
it does not effect libidn/libidn2 usage in systemd.
Tested with qemu-system-arm.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Only busybox and sysvinit handle the BR2_TARGET_GENERIC_GETTY_TERM and
BR2_TARGET_GENERIC_GETTY_OPTIONS options; the other init systems do
not.
So, protect those options behind appropriate dependencies on busybox
or sysvinit.
Fixes#10301.
Reported-by: Michael Heinemann <posted@heine.so>
Suggested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The skeletons are based on the selection of BR2_INIT_*, so add init- to
the package name to make this clearer. While skeleton-sysv is relatively
clear, skeleton-common and skeleton-none are less clear on their
relationship to BR2_INIT_*. So rename skeleton-sysv to conform to a
clearer pattern.
Signed-off-by: Cam Hutchison <camh@xdna.net>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The skeletons are based on the selection of BR2_INIT_*, so add init- to
the package name to make this clearer. While skeleton-systemd is
relatively clear, skeleton-common and skeleton-none are less clear on
their relationship to BR2_INIT_*. So rename skeleton-systemd to conform
to clearer pattern.
Signed-off-by: Cam Hutchison <camh@xdna.net>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The skeletons are based on the selection of BR2_INIT_*, so add init- to
the package name to make this clearer. The name skeleton-none implies no
skeleton at all, not a base skeleton with no init-specific files.
Signed-off-by: Cam Hutchison <camh@xdna.net>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When the rootfs is readonly, systemd will expect /var to be writable.
Because we do not really have a R/W filesystem to mount on /var, we make
it a tmpfs [*], and use the systemd-tmpfiles feature to populate it with
"factory" defaults.
We obtain those factory defaults by redirecting /var to that location at
build time, using a symlink /var -> /usr/share/factory which is the
location in which systemd-tmpfiles will look for when instructed to
"recursively copy" a directory.
With a line like:
C /var/something - - - -
it will look for /usr/share/factory/something and copy it (recursively
if it is a directory) to /var/something, but only if it does not already
exist there.
We also mark this copy with the exclamation mark, as it is only safe to
copy on boot, not when changing targets.
To be noted: the real format for such lines are:
C /var/something - - - - /from/where/to/copy/something
But if the source is not given, then it is implicitly taken from
/usr/share/factory (which in our case is as-good a location as whatever
else, so we use it, and thus we need not specify the source of the
copy).
Note that we treat symlinks a little bit specially, by creating symlinks
to the factory defaults rather than copying them.
Finally, /var at build time is a symlink, but at runtime, it must be a
directory (so we can mount the tmpfs over there). We can't change that
as a target-finalize hook, because:
- some packages may want to set ownership and/or access rights on
files or directories in /var, and that only happens while assembling
the filesystem images; changing /var from a symlink to a (then
empty) directory would break this;
- /var would be a directory on sub-sequent builds (until the next
"make clean").
Instead, we use the newly-introduce pre- and post-rootfs command hooks,
to turn /var into a directory before assembling the image, and back to a
symlink after assembling the image.
[*] People who want the factory-defaults only on first boot will have
to tweak the fstab to mount something else than a tmpfs on /var.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
For systemd, we create a simple /etc/fstab with only an entry for /, as
systemd otherwise automatically mounts what it needs where it needs it.
systemd does not like that the content of /var be symlinks to /tmp,
especially journald that starts before /tmp is mounted, and thus the
journal files are hidden from view, which causes quite a bit of fuss...
Instead, move the current /var to a sysv-only skeleton.
systemd at install time will create the /var content it needs, so we
just create an empty /var for systemd.
systemd would create /home and /srv at runtime if they are missing, but
it is better to create them right now, to simplify supporting systemd on
a RO filesystem in the (near) future.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
