The bootstrap script gets feedback from gen-admin-auth, on error we no
longer bail out but instead log the error and continue booting. This
way a developer build with root login can diagnose the error.
When logging the error we also set /etc/issue, /etc/issue.net for local
and remote login services, as well as the dedicated /etc/banner used by
OpenSSH, to hold the error summary. So when attaching to the console
port, or attempting to log in remotely with SSH, the error is printed
to indicate the device is not healthy.
Finally, since factory-config may be missing we need to bootstrap the
sysrepo db with something else, and fortunately we will always have a
failure-config to fall back on.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Break fallback hash to a separate function and allow gen_qemu_system_file()
to return the status. We'd like to update the qeneth templates to include
the same VPD data as is used with qemu.sh, but for now this is sufficient.
The Qemu detection has been changed to the, slightly more, secure detection
of qemu_fw_cfg filesystem.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This commit does several things. Its end goal is to fetch the admin
password hash from VPD memory during factory bootstrap.
To accomplish this probe creates a new file /run/system.json with
information read from a fw_cfg QEMU partition. The data from
/run/system.json is then later used during config bootstrap to fill in
the factory administrator password.
The idea is to make QEMU behave the same way hardware does, i.e. a
default/factory password should be fetched and used from
"hardware memory". The hardware portion of this is yet to be done.
Signed-off-by: Richard Alpe <richard@bit42.se>
Before this change, the following would happen in /lib/infix/mnt if a
factory-reset was performed:
1. Copy the contents of /var from Squash into /mnt/var and bind mount
/mnt/var over /var
2. Check for factory-reset
3. Clear /mnt/cfg/* and /mnt/var/*
4. Mount overlays
This ordering leaves the system with a completely empty /var on the
boot when a factory-reset is executed. Finit will fixup some of this
via its tmpfiles scripts, but we want the ability to ship files under
/var as part of the Squash and have these be available after the bind
mount, just like what happens at every other boot, when we don't
perform a factory-reset.
We solve this by delaying the bind mount (1) until after the reset has
been performed, together with all the overlays (4). While we're here,
make the fallback case, where no persistent /var is available, use a
bind mount as well. This should allow containers to be tested on such
setups, and it's one less flavor to test.
New order:
1. Check for factory-reset
2. Clear /mnt/cfg/* and /mnt/var/*
3. Mount overlays
4. Copy the contents of /var from Squash into /mnt/var and bind mount
/mnt/var over /var
Now the only difference between a regular boot and a
"factory-reset-boot" is whether (2) executed or not.
Relocate Finit conf to package, like klish and confd. Add condition to
ensure it is not started before mdev/udevd are up and kernel LED modules
have been loaded properly.
Also, add tmpfiles.conf to ensure /run/led is recreated at every boot.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Refactor factory-reset check slightly to check for a Finit condition
from the bootloader, as well as a custom check for br2-externals.
Note, the chgrp call has been extended to ensure admin users have
permission to create any file or directory in any overlay.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Per spec[1], the PRETTY_NAME "May or may not contain a release code name
or OS version of some kind, as suitable." and seeing as this is not only
a common practice, Finit use this string in the heading when booting.
We've had this already in Infix a while back so it must have been lost
in one of many refactoring rounds.
[1]: https://www.freedesktop.org/software/systemd/man/latest/os-release.html
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
A customer specific build required more RAM to boot (bigger image and
more features), but there was no way to modify this as an end user.
This patch opens this up and should give our users a more smooth ride!
We can [skip ci] on this, no functional changes to the OS itself.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Replaced with full build in GitHub Actions. No other use-cases for it,
and too much of a hassle to maintain, so remove.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
If the bootloader knows about a factory-reset or dev-mode button, use
them to allow stopping the boot process, and to signal the
factory-reset condition to infix.
This adds support for the two /etc/os-release variables:
- IMAGE_ID
- IMAGE_VERSION
The former is configurable, with fallback to name-arch, and the latter
is only set for relase builds. During releae builds the release will
be appended to the image name.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Currently does not need any conditions, but may later need to check for
loaded modules and other capabilities.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
- Create per-arch unique distribution file names
- Source .gns3a information from /etc/os-release
Instead of attempting to create unique file names by hard-coding an
'infix-' prefix and extracting the "board" or "arch" part from the
defconfig, let's use the branding information from /etc/os-release
along with $BR2_ARCH.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This makes it possible for projects using Infix as a br2-external to
override lots of OS-specific strings and contact information that
previously was hard coded.
The generated /etc/os-release now takes most of its data from .config
Worth noting is the changes in VERSION and BUILD_ID fields. The former
will be INFIX_RELEASE, during release builds, and the latter is always
the output from `git descibe ...`, or rather GIT_VERSION. This variable
can be overloaded as well.
See the help text and the new doc/branding.md document for details.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The default arch and disk image filename needs to be generated
to be unique per, at least, each architecture build.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Due to problems with using u-boot as loader¹ we decided to start the
system by calling the kernel image directly. The downside to that is
that, even though RAUC upgrades would work, the kernel would remain
the same.
Improvements to this are of course welcome.
________
¹) Must extract the built-in .dtb and merge with the Qemu .dtb at runtime
to be able to boot primary (or secondry) image.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Calling `load_cfg BR2_EXTERNAL_INFIX_PATH` from post-image.sh caused
warnings due to multiple hits in the .config file:
post-image.sh: 12: /tmp/tmp.5a3xhQQVc8: BR2_EXTERNAL_INFIX_PATH: not found
post-image.sh: 13: /tmp/tmp.5a3xhQQVc8: BR2_EXTERNAL_INFIX_PATH: not found
Let's grep for a "key.*=" instead of "key" to drop those warnings, while
still acting as a catch-all for partial matches.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
