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.
At the time of writing, an increased source of failure in our CI is related to i686-linux.
While I do wish to support 32 bits x86 system further, the reality is that we cannot
identify in our community maintainers for `i686-linux` that can provide continuous maintenance
for our i686-linux packages.
As a matter of fact, `i686-linux` is probably broken in nixpkgs, we decide to rip off the band-aid
and drop the support.
Next steps could involve to extract a core package set of nixpkgs / NixOS in an out-of-tree
repository to offer a simple 32 bits NixOS support with a cache or to find maintainers
who are willing to work on i686 support.
The current state is certainly very wrong - testing ZFS only on i686.
I suspect it was a typo (?) in commit 2de3caf011.
The current practical problem is that the test fails,
though in a part that looks cross-platform (which adds confusion):
https://hydra.nixos.org/build/239290208#tabs-buildsteps
This splits the tests into two: one where cups.socket is started
normally, the order with socket activation.
Why? It's almost impossible to follow the test with 4 different
machines printing at the same time. It should also be more efficient
because only two VMs at a time were needed anyway.
The ACME module has long been an important part of every nixos server
deployment and we should therefore make sure the tests are working as
expected before allowing a channel bump to happen.
Related: #197443
Sway is a Wayland compositor. It should have a smaller userbase than
Gnome and KDE but Sway plays an important role in the Wayland ecosystem
(it is e.g. maintained by Simon Ser who also maintains wlroots, Wayland,
and Weston (the reference compositor) and contributes to a lot of
important packages in the Wayland ecosystem). Sway also comes with much
fewer dependencies than large desktop environments.
This should make the Sway VM test an ideal choice for testing updates to
core packages (e.g. wayland, wayland-protocols, wlroots, libdrm, mesa,
and xwayland - I maintain all but XWayland in Nixpkgs) and test failures
should be much easier to debug.
The test is fairly new but so far all 18 Hydra builds on x86_64-linux
have succeeded [0]. I'm actively maintaining the test and can look into
build failures if I'm pinged.
[0]: https://hydra.nixos.org/job/nixos/trunk-combined/nixos.tests.sway.x86_64-linux/all
This reverts commit 2dbd08dcbd.
I've fixed the regression in 8a7a8442c1 and the rest of my
refactorings/improvements shouldn't affect the stability of the test.
Chromium seems to run fine but the VM test fails and prints errors like:
machine # There are no windows in the stack
machine # Invalid window '%1'
machine # Usage: windowfocus [window=%1]
machine # --sync - only exit once the window has focus
This could be due to changes in Chromium's X11 code (or maybe some
changes for Ozone/X11). I'll investigate this but let's temporarily
remove the Chromium test from the tested jobset until I find a proper
solution/fix.
5150378c2f fixed the long-broken
nixosTests.networking.virtual.
With all tests failures fixed, and #79328 making debugging much easier,
let's re-add it to the tested jobset.
These now depend on an external patch set; add them to the release tests
to ensure that the build doesn't break silently as new kernel updates
are merged.
