Move already implemented functionality to the upper level so
it could be used in a more generic way.
Signed-off-by: Ivan Nikolaenko <ivan.nikolaenko@unikie.com>
This is image media, so use the override level designed for it. As
detailed in the definition for mkImageMediaOverride:
> image media profiles can be derived by inclusion into host config,
> hence needing to override host config, but do allow user to mkForce
our xslt already replaces double line breaks with a paragraph close and
reopen. not using explicit para tags lets nix-doc-munge convert more
descriptions losslessly.
only whitespace changes to generated documents, except for two
strongswan options gaining paragraph two breaks they arguably should've
had anyway.
Very confusingly, the `isPowerPC` predicate in
`lib/systems/inspect.nix` does *not* match `powerpc64le`!
This is because `isPowerPC` is defined as
isPowerPC = { cpu = cpuTypes.powerpc; };
Where `cpuTypes.powerpc` is:
{ bits = 32; significantByte = bigEndian; family = "power"; };
This means that the `isPowerPC` predicate actually only matches the
subset of machines marketed under this name which happen to be 32-bit
and running in big-endian mode which is equivalent to:
with stdenv.hostPlatform; isPower && isBigEndian && is32bit
This seems like a sharp edge that people could easily cut themselves
on. In fact, that has already happened: in
`linux/kernel/common-config.nix` there is a test which will always
fail:
(stdenv.hostPlatform.isPowerPC && stdenv.hostPlatform.is64bit)
A more subtle case of the strict isPowerPC being used instead of the
moreg general isPower accidentally are the GHC expressions:
Update pkgs/development/compilers/ghc/8.10.7.nix
Update pkgs/development/compilers/ghc/8.8.4.nix
Update pkgs/development/compilers/ghc/9.2.2.nix
Update pkgs/development/compilers/ghc/9.0.2.nix
Update pkgs/development/compilers/ghc/head.nix
Since the remaining legitimate use sites of isPowerPC are so few, remove
the isPowerPC predicate completely. The alternative expression above is
noted in the release notes as an alternative.
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
This includes disabling some features in the initrd by default, this is
only done when the new initrd is used. Namely, ext and bcache are
disabled by default. bcache gets an own enable option while ext is
detected like any other filesystem.
UEFI firmware does not have to be able to read ISO9660 filesystems, so
the El Torito mechanism provides a way to specify an embedded FAT32
image which contains files the UEFI firmware itself must be able to
read, such as UEFI executables. Once GRUB starts and reads its
configuration, it can access the ISO9660 filesystem to load other files.
This change removes the unused kernel, initrd, and GRUB font files from
the El Torito image, but keeps the GRUB configuration and UEFI
executables. These files have been present since EFI support was
originally introduced in commit 097c656. Other distribution ISOs, such
as Ubuntu 20.04, Fedora 35, and Windows 10 work this way too. This saves
24MiB on x86_64 and 61MiB on aarch64 ISOs.
The live image is primarily used for installation so we should make
link to manual as well as other useful tools front and center,
instead of having them buried in the app drawer.
The default GNOME apps can still be found there when the ISO
is used for demonstration purposes.
so the underlaying use case of the preceding commit is so
generic, that we gain a lot in reasoning to give it an
appropriate name.
As the comment states:
image media needs to override host config short of mkForce
https://github.com/NixOS/nixpkgs/pull/131760 was made to avo
a speicific configuration conflict that errored out for multiple definitions of "/" when the installer where overlayed
on any existing host configuration.
---
Problem 1: It turns out that in also other mountpoints can coflict.
Solution 1: use `mkOverride 60` for all mountpoints (even for the ones unlikely causing confilct for consistency sake)
---
Problem 2: It turns out that on an installation media for a fresh machine (before formatting), we usually don't have any devices yet formatted. However defining for example `fileSystems.<nme>.device = "/dev/disk/by-label/...", in newer versions of nixos, seems to make the system startup fail. Similarily waiting for a non-existent swap device does not make the startup fail, but has a 1:30 min timeout.
Solution 2: For an installation medium, soft-override ("unless users know what they are doing") the entire `fileSystems` and `swapDevices` definitions.
installer media can be used on top of existing host configs. In such
scenarions, root fs types will already be defined.
Before this change, this will inevitably lead to the following error:
```console
error: The option `fileSystems./.fsType' has conflicting definition values:
- In `/nix/store/2nl5cl4mf6vnldpbxhrbzfh0n8rsv9fm-source/DevOS/os/hardware/common.nix': "ext4"
- In `/nix/store/jbch90yqx6gg1h3fq30jjj2b6h6jfjgs-source/nixos/modules/installer/cd-dvd/iso-image.nix': "tmpfs"
```
With this patch, the installers will override those values according to
their own local requirement.
Use `mkOverride 60` so that conscientious overriding specially targeted
at the installer, e.g. with `mkForce` is still straight forward.
This should help in rare hardware-specific situations where the root is
not automatically detected properly.
We search using a marker file. This should help some weird UEFI setups
where the root is set to `(hd0,msdos2)` by default.
Defaulting to `(hd0)` by looking for the ESP **will break themeing**. It
is unclear why, but files in `(hd0,msdos2)` are not all present as they
should be.
This also fixes an issue introduced with cb5c4fcd3c
where rEFInd stopped booting in many cases. This is because it ended up
using (hd0) rather than using the `search` which was happening
beforehand, which in turn uses (hd0,msdos2), which is the ESP.
Putting back the `search` here fixes that.
This technically changes nothing. In practice `$root` is always the
"CWD", whether searched for automatically or not.
But this serves to announce we are relying on `$root`... I guess...