This reverts commit 4daccf208f
The reverted commit claims that bootctl fails if machine-id is not set.
I can not reproduce this. I think this has since been fixed now that
bootctl has support for arbtirary entry-tokens and not just machine-id.
In the case of NixOS the entry-token is the string "nixos"
Use the store directory for the devicetree package containing the
desired DTB when installing to the ESP. This allows for more than one
NixOS generation containing differing DTBs to coexist on the same ESP
(similar to how we can have multiple kernels & initrds). This change
removes the assumption that the filepath passed to `copy_from_file` is a
file that lives at the toplevel of a nix output path (which prior to the
systemd-boot DTB support was the case for the kernel and initrd
derivations).
Windows with BitLocker and TPM enabled doesn't support boot chaining.
This option activates a special experimental mode in systemd-boot that
tries to detect such systems and, if detected and selected by the user
at the boot menu, set the BootNext EFI variable to it before resetting.
The [Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification/)
allows for using a key called "devicetree" for specifying which
devicetree the bootloader should use during boot. With regards to
systemd-boot, this key is used to specify which file should be picked up
from the ESP to install to the EFI DTB Configuration Table. Linux then uses
this Configuration Table to setup the machine. This change is similar to
the one done in https://github.com/NixOS/nixpkgs/pull/295096, where that
change was for adding DTB support to systemd-stub, and this is for
systemd-boot.
Fix regular expression used to get bootloader versions from bootctl status.
This avoids problems that occur in minor environments like mine.
References: #296563
we have a zoo of ways to call subprocesses.
Let's just replace this with one function that has reasonable defaults.
i.e. I catched instances where commands where run in a shell.
Without sort-keys specified on entries, the entries are sorted only by
file name (in decreasing order, so starting at the end of the alphabet!),
without taking any other fields into account (see
[the boot loader specification reference][1]).
Moreover, entries without a sort-key are always ordered after all
entries with a sort-key, so by not adding a sort-key to the NixOS ones,
we cannot add a sort-key to any other entry while keeping it below the
NixOS entries.
So currently we have options to set the file names for additional entries like
memtest and netbootxyz.
However, as mentioned above, the sorting by file name is not very intuitive and
actually sorts in the opposite order of what is currently mentioned in the option
descriptions.
With this commit, we set a configurable sort-key on all NixOS entries,
and add options for setting the sort-keys for the memtest and netbootxyz
entries.
The sorting by sort-key is more intuitive (it starts at the start of the
alphabet) and also takes into account the machine-id and version for entries
with identical sort-keys.
We use a bootspec extension to store the sort keys, which allows us to
redefine the sort key for individual specialisations without needing any
special casing.
[1]: https://uapi-group.org/specifications/specs/boot_loader_specification/#sorting
This makes it easier to reason about what variables are inserted during packaging.
We also make sure that template file is also valid python syntax, which makes editor errors go away during development.
A bootspec could remove the `initrdSecrets` attribute and is a perfectly valid bootspec, as can be seen
in the bootspec.cue.
This makes the builder not fail upon missing `initrdSecrets`.
8f2babd032 was partially reverted by mistake. Original message below
---
On some systems, EFI variables are not supported or otherwise wonky.
bootctl attempting to access them causes failures during bootloader
installations and updates. For such systems, NixOS provides the options
`boot.loader.efi.canTouchEfiVariables` and
`boot.loader.systemd-boot.graceful` which pass flags to bootctl that
change whether and how EFI variables are accessed.
Previously, these flags were only passed to bootctl during an install
operation. However, they also apply during an update operation, which
can cause the same sorts of errors. This change passes the flags during
update operations as well to prevent those errors.
Fixes https://github.com/NixOS/nixpkgs/issues/151336
This reverts commit 80665d606a.
Parsing the package version broke our systemd-boot builder test.
i.e. it won't be able to parse systemd-boot efi binaries coming from
ubuntu
We no longer use the faulty systemd-boot version so this code should no
longer be needed.
In order to fix
https://github.com/NixOS/nixpkgs/issues/114552 (profile name with
special characters), all OSError have been ignored while only the OSError
with errno 22 (invalid argument) could has been ignored.
The drawback of ignoring all OSError is that the "No space left on
device" error is also ignored. When the /boot doesn't have enough
available disk space, the switch-to-configuration script succeeds
while the boot menu has not been updated: the user thinks it's system
has been updated, but on the next reboot it is actually rollbacked.
On some systems, EFI variables are not supported or otherwise wonky.
bootctl attempting to access them causes failures during bootloader
installations and updates. For such systems, NixOS provides the options
`boot.loader.efi.canTouchEfiVariables` and
`boot.loader.systemd-boot.graceful` which pass flags to bootctl that
change whether and how EFI variables are accessed.
Previously, these flags were only passed to bootctl during an install
operation. However, they also apply during an update operation, which
can cause the same sorts of errors. This change passes the flags during
update operations as well to prevent those errors.
Fixes https://github.com/NixOS/nixpkgs/issues/151336
That version has a regression that leaves some machines unbootable.
While we wait for the fix (252.2) to land in master, this is a workaround that
should save people some pain.
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.