so the underlaying use case of the preceding commit is so
generic, that we gain a lot in reasoning to give it an
appropriate name.
As the comment states:
image media needs to override host config short of mkForce
https://github.com/NixOS/nixpkgs/pull/131760 was made to avo
a speicific configuration conflict that errored out for multiple definitions of "/" when the installer where overlayed
on any existing host configuration.
---
Problem 1: It turns out that in also other mountpoints can coflict.
Solution 1: use `mkOverride 60` for all mountpoints (even for the ones unlikely causing confilct for consistency sake)
---
Problem 2: It turns out that on an installation media for a fresh machine (before formatting), we usually don't have any devices yet formatted. However defining for example `fileSystems.<nme>.device = "/dev/disk/by-label/...", in newer versions of nixos, seems to make the system startup fail. Similarily waiting for a non-existent swap device does not make the startup fail, but has a 1:30 min timeout.
Solution 2: For an installation medium, soft-override ("unless users know what they are doing") the entire `fileSystems` and `swapDevices` definitions.
installer media can be used on top of existing host configs. In such
scenarions, root fs types will already be defined.
Before this change, this will inevitably lead to the following error:
```console
error: The option `fileSystems./.fsType' has conflicting definition values:
- In `/nix/store/2nl5cl4mf6vnldpbxhrbzfh0n8rsv9fm-source/DevOS/os/hardware/common.nix': "ext4"
- In `/nix/store/jbch90yqx6gg1h3fq30jjj2b6h6jfjgs-source/nixos/modules/installer/cd-dvd/iso-image.nix': "tmpfs"
```
With this patch, the installers will override those values according to
their own local requirement.
Use `mkOverride 60` so that conscientious overriding specially targeted
at the installer, e.g. with `mkForce` is still straight forward.
Different boards using u-boot SPL require to write to different
locations. Sometimes, the 8MiB gap isn't sufficient - rk3399 boards
write to 0x16384 for example, which is at 8MiB, thus overriding the
fat32 partition with the SPL.
This should help in rare hardware-specific situations where the root is
not automatically detected properly.
We search using a marker file. This should help some weird UEFI setups
where the root is set to `(hd0,msdos2)` by default.
Defaulting to `(hd0)` by looking for the ESP **will break themeing**. It
is unclear why, but files in `(hd0,msdos2)` are not all present as they
should be.
This also fixes an issue introduced with cb5c4fcd3c
where rEFInd stopped booting in many cases. This is because it ended up
using (hd0) rather than using the `search` which was happening
beforehand, which in turn uses (hd0,msdos2), which is the ESP.
Putting back the `search` here fixes that.
This technically changes nothing. In practice `$root` is always the
"CWD", whether searched for automatically or not.
But this serves to announce we are relying on `$root`... I guess...
The value of du output depends on the underlying file system, and thus is not fully deterministic. This workaround rounds up the disk usage size to the nearest multiple of 1MB, to increase the probability that two du output values on two different file systems fall within the same 1MB window. Note that this workaround won't make du output 100% reproducible, but will increase the probability of getting deterministic builds across different file systems.
mcopy file globbing is non-deterministic with respect to the underlying file
system. As a result, the current mcopy approach is less likely to reproduce
efi.img on different machines. We replace mcopy file globbing with
fixed-order mmd and mcopy operations for better determinism. We also use
faketime on mmd for the same reason. We use faketime, mmd, and mcopy
directly, becase they are already in PATH.
Thank misuzu@ for the feedback.
This reverts commit 6f6b2cdc98.
Version wasn't updated, and apparently a patch didn't apply. Let's do
this upgrade properly, in a PR, but for now I'm reverting so we don't
have a broken nix package in master.
Looks like GRUB has issues loading EFI binaries from (cd0), which is
what would be used in e.g. qemu with OVMF with `-cdrom`. Apparently also
what is used with AArch64 + U-Boot USB.
The serial output (but it's named console, not serial actually) causes
issues on U-Boot's EFI, at the very least.
This is inspired by OpenSUSE's approach:
* https://build.opensuse.org/package/view_file/Base:System/grub2/grub2-SUSE-Add-the-t-hotkey.patch
Where they add a hidden menu entry, which can be used to force the
console output.
The `echo` will be visible on the serial terminal (grub "console"),
while the graphical interface is shown. Note that input in the serial
terminal (grub "console") will continue controlling the graphical
interface. Useful if you have an SBC connectedinto an HDMI monitor, but
no keyboard connected to it.
This is supeer useful to allow the normal sd-image code to be used by
someone who wants to setup multiple partitions with a sd-image.
Currently I'm manually copying the sd-image file and modifying it
instead.
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/
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
