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'
```
noXLibs is an advanced option for advanced users which know how to recognize and debug build failures which might be caused by the added overlays.
The minimal profile should be minimal but also save to use for many people and not cause build failures in packages it really shouldn't.
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)
this lets us *dis*able filesystem explicitly, as is required by e.g. the
zfs-less installer images. currently that specifically is only easily
possible by adding an overlay that stubs out `zfs`, with the obvious
side-effect of also removing tooling that could run without the kernel
module loaded.
When building kexec-based installer every mb saved will reduce the RAM usage and allow to install NixOS on smaller machines.
It also means that less data has to be downloaded from the network.
When using flakes or niv we no longer rely on nix channels beeing present
and when using something like nixos-anywhere, we no longer need to evaluate anything in the installer at all.
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.
This change adds an option to disable legacy BIOS boot support for ISO
images. The implementation uses syslinux package that currently does not
support non-x86 platforms and thus cannot be cross-compiled, e.g. from
AArch64 system.
