Before this patch, the entry match condition always fails, causing all
entries being removed. The error is not noticed because later they are
re-generated.
Before this patch, the gen_number found by regex contains
"-specialisation-foo" if specialisation is used. As a result, applying
int() to gen_number raises ValueError, causing entries containing
a specialisation part not being removed.
mostly no rendering changes. some lists (like simplelist) don't have an
exact translation to markdown, so we use a comma-separated list of
literals instead.
our xslt already replaces double line breaks with a paragraph close and
reopen. not using explicit para tags lets nix-doc-munge convert more
descriptions losslessly.
only whitespace changes to generated documents, except for two
strongswan options gaining paragraph two breaks they arguably should've
had anyway.
the conversion procedure is simple:
- find all things that look like options, ie calls to either `mkOption`
or `lib.mkOption` that take an attrset. remember the attrset as the
option
- for all options, find a `description` attribute who's value is not a
call to `mdDoc` or `lib.mdDoc`
- textually convert the entire value of the attribute to MD with a few
simple regexes (the set from mdize-module.sh)
- if the change produced a change in the manual output, discard
- if the change kept the manual unchanged, add some text to the
description to make sure we've actually found an option. if the
manual changes this time, keep the converted description
this procedure converts 80% of nixos options to markdown. around 2000
options remain to be inspected, but most of those fail the "does not
change the manual output check": currently the MD conversion process
does not faithfully convert docbook tags like <code> and <package>, so
any option using such tags will not be converted at all.
Handling of the string length condition in should_update
was broken, as evident with the log message
> leaving systemd-boot 246 in place (250.4 is not newer)
Discussion with @mweinelt came to the conclusion
that Python's "<" operator already does what we need,
so the should_update function can be dropped.
Fixes a30de3b849
Since, 4ddc78818e systemd-boot-builder
is broken in two ways:
* if no systemd-boot is currently installed *and* the NIXOS_INSTALL_BOOTLOADER
env variable is not set, it will try to run "bootctl update", which will fail
* if the currently installed systemd-boot version is newer than the version
we're about to install, it will also try to run "bootctl update", which will fail
This patch changes the behaviour,
* for the first case to still fail, but not even bother to try running
"bootctl update" and instead erroring out with an exception
* for the second case to leave the newer version in place, restoring
the pre - 4ddc78818e behaviour
To do the proper version check a new "should_update" helper function was introduced,
mimicing the compare_product C function from bootctl. If the following systemd
issue gets resolved, we would have a nice way to get rid of this function:
> https://github.com/systemd/systemd/issues/23450
This change allows to again switch to a different NixOS configuration which contains
an older systemd-boot.
Co-authored-by: Martin Weinelt <mweinelt@users.noreply.github.com>
People running nixos-install in non-NixOS environments
occasionally run into the mktemp builtin not being loaded
into bash (yes, even NixOS' bash). Rather than try and
figure out why exactly that is happening, just use a known
good mktemp from coreutils.
The regexp was only matching numbers and not the '.', so everyone using
systemd-boot would always see `could not find any previously installed
systemd-boot` on a `nixos-rebuild`.
Some specialisations (such as those which affect various boot-time
attributes) cannot be switched to at runtime. This allows picking the
specialisation at boot time.
On some systems bootctl cannot write the `LoaderSystemToken` EFI variable
during installation, which results in a failure to install the boot
loader. Upstream provides a flag (--graceful) to ignore such write failures -
this change exposes it as a configuration option.
As the exact semantics of this option appear to be somewhat volatile it
should be used only if systemd-boot otherwise fails to install.
os.readlink only resolves one layer of symlinks. This script explicitly relies on the real path of a file for deduplication, hence symlink resolution should recurse.
Since 03eaa48 added perl.withPackages, there is a canonical way to
create a perl interpreter from a list of libraries, for use in script
shebangs or generic build inputs. This method is declarative (what we
are doing is clear), produces short shebangs[1] and needs not to wrap
existing scripts.
Unfortunately there are a few exceptions that I've found:
1. Scripts that are calling perl with the -T switch. This makes perl
ignore PERL5LIB, which is what perl.withPackages is using to inform
the interpreter of the library paths.
2. Perl packages that depends on libraries in their own path. This
is not possible because perl.withPackages works at build time. The
workaround is to add `-I $out/${perl.libPrefix}` to the shebang.
In all other cases I propose to switch to perl.withPackages.
[1]: https://lwn.net/Articles/779997/
Catch and ignore errors during writing of the boot entries. These
errors could stem from profile names that are not valid filenames on
vfat filesystems.
fixes#114552
It was introduced in c10fe14 but removed in c4f910f.
It remained such that people with older generations in their boot
entries could still boot those. Given that the parameter hasn't had any
use in quite some years, it seems safe to remove now.
Fixes#60184
The `platform` field is pointless nesting: it's just stuff that happens
to be defined together, and that should be an implementation detail.
This instead makes `linux-kernel` and `gcc` top level fields in platform
configs. They join `rustc` there [all are optional], which was put there
and not in `platform` in anticipation of a change like this.
`linux-kernel.arch` in particular also becomes `linuxArch`, to match the
other `*Arch`es.
The next step after is this to combine the *specific* machines from
`lib.systems.platforms` with `lib.systems.examples`, keeping just the
"multiplatform" ones for defaulting.
This is a temporary fix for #97433. A more proper fix has been
implemented upstream in systemd/systemd#17001, however until it gets
backported, we are stuck with ignoring the error.
After the backport lands, this commit should be reverted.
For UEFI setups, "device" will generally be the special value "nodev"
which represents not running grub-install at all. Using "nodev" for
boot mirrors should therefore be allowed.
The commit enforces buildPackages in the builder but neglects
the fact that the builder is intended to run on the target system.
Because of that, the builder will fail when remotely building a
configuration eg. with nixops or nix-copy-closure.
This reverts commit a6ac6d00f9.
Fixes error
Can't use an undefined value as an ARRAY reference at /nix/store/...-install-grub.pl line 642, <FILE> line 5.
with `/boot/grub/state` being:
```
grub
2.04
no
/dev/sda
/boot
```
I am not sure where the trailing empty line can come from; the script does not
seem to write it. In any case, now we handle that situation as well.
Further, ensure that `extraGrubInstallArgs` defaults to the empty array
if its key is not present in the `jsonState`.
For example, turns the error
cannot copy /nix/store/g24xsmmsz46hzi6whv7qwwn17myn3jfq-grub-2.04/share/grub/unicode.pf2 to /boot
into the more useful
cannot copy /nix/store/g24xsmmsz46hzi6whv7qwwn17myn3jfq-grub-2.04/share/grub/unicode.pf2 to /boot: Read-only file system
Useful for when you need to build grub modules into your grub kernel
to get a working boot, as shown in the added example.
To store this new value, we switch to more structural JSON approach.
Using one line per value to store in `/boot/grub/state` gets really messy when
the values are arrays, or even worse, can contain newlines (escaping would be
needed). Further, removing a value from the file would get extra messy
(empty lines we'd have to keep for backwards compatibility).
Thus, from now on we use JSON to store all values we'll need in the future.
This can be used to explicitly specify a specific dtb file, relative to
the dtb base.
Update the generic-extlinux-compatible module to make use of this option.
Some bootloaders might not properly detect the model.
If the specific model is known by configuration, provide a way to
explicitly point to a specific dtb in the extlinux.conf.
This option exposes the builder command used to populate an image,
honoring all options except the -c <path-to-default-configuration>
argument.
Useful to have for sdImage.populateRootCommands.
Special care needs to be taken w.r.t cross - the populate command runs
on the host platform, the activation script on the build platform (so
the builders differ)
The way this ends up being called with the raspberry pi 4 image builder
ends up not using the `-e` from the shebang.
In turn, the builds fails during cross-compilation. The wrong coreutils
ends up being used, but this is not made apparent.
The issue I faced is already fixed on master, but this ensures no one
ends up with a failed build "succeeding".
Memtest86+ doesn't support EFI, so unfree Memtest86 is used when EFI
support is enabled (systemd-boot currently also uses Memtest86 when
memtest is enabled).
A centralized list for these renames is not good because:
- It breaks disabledModules for modules that have a rename defined
- Adding/removing renames for a module means having to find them in the
central file
- Merge conflicts due to multiple people editing the central file
