After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
This is the error message on fail:
> qemu-system-aarch64: -device canokey,file=/tmp/canokey-file: Warning:
> speed mismatch trying to attach usb device "CanoKey QEMU" (full
> speed) to bus "usb0.0", port "3" (high speed)
My Understanding of the Issue is: The test failed because
qemu-system-aarch64 apparently has different USB controllers enabled by
default, resulting in a "speed mismatch" between the USB controller and
CanoKey that only occurred on aarch64.
I could reproduce the issue on x86_64 by enabling the EHCI controller
and then fix the issue by specifying which USB bus to use for the
CanoKey.
This didn't fully fix the issue on my first attempt, because the UCHI
controller enabled by -usb doesn't have the same bus name on aarch64
and x86_64.
While bus=usb-bus.0 worked on x86_64, on aarch64 i get this message:
> qemu-system-aarch64: -device canokey,bus=usb-bus.0,file=
> /tmp/canokey-file: Bus 'usb-bus.0' not found
The final solution now manually enables the OHCI controller (which may
be similar to UHCI, but i really have no idea other than it works) and
assigns it the id aka bus name "usb-bus", so it works the same under
both architectures.
Given that we were overriding qemu_test to enable this anyway,
enabling this by default saves Hydra a QEMU build.
There's also clear demand from users[1] for this feature, so our
alternatives are:
- Offer a qemu-canokey attribute. I don't want to do this, because I
don't think there's any reason to make Hydra build an extra QEMU.
- Enable it only for qemu_test. I don't want to do this, because it
will lead to users using qemu_test without understanding its
subtleties.
- Force users to build from source. I don't think there's any reason
to do this when it's unlikely to hurt anybody having it enabled by
default. There's no reason to single out canokey to be disabled by
default in spite of users' needs given that we enable so many other
optional QEMU features.
[1]: https://github.com/canokeys/canokey-qemu/issues/6
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.
