NixOS has traditionally enabled the `ext` family of file systems by
default. Originally, when switching to systemd initrd, we wanted to
transition to making this explicit so that initrds could be made
without `ext`. The problem is that anyone with `fsType = "auto";` for
an `ext` file system in initrd will fail to boot, which is not really
an acceptable regression as we switch to systemd initrd by default.
By removing `default = "auto"` from `fsType`, we rule out the vast
majority of these regressions as eval errors, since most users of
`fsType = "auto"` for ext file systems are using it because of the
default value.
In hindsight, this is probably what #225352 was really about.
We use `mkImageMediaOverride` to ensure that GRUB is actually disabled
if a user enables it using the default priority but still allows them to
enable it using `mkForce`.
GNOME in particular just breaks if plymouth isn't disabled, because
GDM takes on the role of quitting plymouth in a GNOME
configuration. But if we're disabling the DM, we should disable
plymouth too anyway.
While switching from isoImage.baseName to the unified image.baseName,
I accidentaly dropped label and system information from the iso filename.
This fixes it by including isoImage.edition in the default baseName for
all our isos. Resulting in filenames such as
`nixos-minimal-25.05beta708350.1d95cb5-x86_64-linux.iso` again instead
of just nixos-minimal.iso.
I have no idea what this escape sequence even is, but it breaks the nix parser with cryptic errors if not used in a comment.
A friend let me know MacOS is prone to input weird spaces, not sure if that is the source.
Candidates were located and created with:
chr="$(echo -e '\xc2\xa0')"; rg -F "$chr" -l | xe sd -F "$chr" " "
There are some examples left, most being example output from `tree` in various markdown documents, some patches which we can't really touch, and `pkgs/tools/nix/nixos-render-docs/src/tests/test_commonmark.py` which I'm not sure if should be addressed
4b836fb680 added `pkgs.grub2_efi` to `environment.systemPackages` so that it would be in the Nix store and available for install. But `pkgs.grub2` is already in the list. This causes the various paths of the two GRUB2 versions to collide. To fix this, put `pkgs.grub2_efi` into `system.extraDependencies` instead. This should achieve the same effect of adding the second GRUB2 version to the Nix store without the paths colliding in the environment.
To reproduce the problem, execute `nix-build nixos -I nixos-config=nixos/modules/installer/cd-dvd/iso-image.nix -A config.system.build.isoImage` and look for messages like
```
warning: collision between `/nix/store/9jk1p9n5dl431lcm4w9p6x6x8a00dm0q-grub-2.12/bin/grub-install' and `/nix/store/809l0i6aydg4zhn3kqf723brjyp2qm8h-grub-2.12/bin/grub-install'
```
these changes were generated with nixq 0.0.2, by running
nixq ">> lib.mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> Inherit >> mdDoc[remove]" --batchmode nixos/**.nix
two mentions of the mdDoc function remain in nixos/, both of which
are inside of comments.
Since lib.mdDoc is already defined as just id, this commit is a no-op as
far as Nix (and the built manual) is concerned.
Right now the worst case chain of events for building an ISO on Hydra is
- copy everything to squashfs builder
- run squashfs builder
- download squashfs from builder
- compress squashfs
- upload squashfs to S3
- copy squashfs to ISO builder
- run ISO builder
- download ISO from builder
- compress ISO
- upload ISO to S3
This inlines the squashfs build into the ISO build, which makes it
- copy everything to ISO builder
- run ISO builder
- download ISO from builder
- compress ISO
- upload ISO to S3
Which should reduce queue runner load by $alot per ISO, which we have four of on small channels
(one release, one test per arch) and a lot more than four of on large channels (with various desktops)
Relying on the built-in UEFI console here was already necessary, so we
are losing nothing by removing the needless `serial` call, which hung
some systems.
This also makes the implementation much easier to understand.
Also, no ugly-font menu anymore!
This helps keep logic simpler, as what we do is forcing text mode, which
means the non-default case is `truthy`, making things easier to digest
in the config file.
Also renaming this option is considered "internal", since it lives only
within the `iso-image` namespace, and also not a breaking change since
it was not part of a stable release.
Which ***anyway*** was not disabled correctly. Following changes will
actually disable it.
What this did was disable the "themed" menu driver, but still continued
relying on the gfxterm infra, which in itself is why things were ugly
and weird.
The `serial` console hangs on some systems. Unknown why.
Anyway, the way this worked right now relied on it telling the user on
the UEFI console how to enable it. So if I understand it correctly, it
will not cause any regression there.
