Building a python environment with python3Minimal requires hydra
to bootstrap pip and build all packages used in the environment
which would otherwise not be built. This reduces cache re-use and duplicates things.
Also common dependencies normally included in python itself
are not properly checked and can cause hard to debug errors
because everyone just assumes those modules are there.
Let's test / on ZFS and /boot on ZFS in separate tests since the GRUB integration for ZFS seems to be not very well maintained.
If the test breaks in the future it's easier to figure out that ZFS on /boot is at fault and either fix the issue or disable the test.
The new test creates a ZFS pool where all features not compatible with GRUB2 are disabled. The dataset is then mounted on /boot and we check that the installer correctly generates a bootable configuration.
Try to use as many ZFS features as possible to verify that GRUB can handle them.
This change removes the bespoke logic around identifying block devices.
Instead of trying to find the right device by iterating over
`qemu.drives` and guessing the right partition number (e.g.
/dev/vda{1,2}), devices are now identified by persistent names provided
by udev in /dev/disk/by-*.
Before this change, the root device was formatted on demand in the
initrd. However, this makes it impossible to use filesystem identifiers
to identify devices. Now, the formatting step is performed before the VM
is started. Because some tests, however, rely on this behaviour, a
utility function to replace this behaviour in added in
/nixos/tests/common/auto-format-root-device.nix.
Devices that contain neither a partition table nor a filesystem are
identified by their hardware serial number which is injecetd via QEMU
(and is thus persistent and predictable). PCI paths are not a reliably
way to identify devices because their availability and numbering depends
on the QEMU machine type.
This change makes the module more robust against changes in QEMU and the
kernel (non-persistent device naming) and by decoupling abstractions
(i.e. rootDevice, bootPartition, and bootLoaderDevice) enables further
improvement down the line.
it is now possible to supply a stratis pool uuid
for every filesystem, and if that filesystem
is required for boot, the relevant pool will be
started in the initramfs.
Hydra Eval has been throwing these eval errors for the past four
months, which makes the yellow "Eval Errors" bubble pretty useless:
https://hydra.nixos.org/eval/1790611#tabs-errors
```
in job ‘nixos.tests.installer.separateBoot.aarch64-linux’:
error: Non-EFI boot methods are only supported on i686 / x86_64
in job ‘nixos.tests.installer.simple.aarch64-linux’:
error: Non-EFI boot methods are only supported on i686 / x86_64
in job ‘nixos.tests.installer.lvm.aarch64-linux’:
error: Non-EFI boot methods are only supported on i686 / x86_64
```
This PR moves the failure for the `!isEfi &&
!pkgs.stdenv.hostPlatform.isx86` case from eval-time to runtime, so
the failure gets categorized under the test that produced it, rather
than just being lumped in to the catch-all Eval Errors pile
which... apparently nobody cares about.
