This is copied from isoImage.squashfsCompression. It's useful to be
able to customise, as iteration cycles are very slow with xz, and
subjectively systems booted with less efficiently compressed squashfs
stores appear to have faster reads (although I didn't test that
scientificly so there could be other factors).
The single option tries to do too much work, which just ends up confusing people.
So:
- don't force the console font, the kernel can figure this out as of #210205
- don't force the systemd-boot mode, it's an awkward mode that's not supported
on most things and will break flicker-free boot
- add a separate option for the xorg cursor scaling trick and move it under the xorg namespace
- add a general `fonts.optimizeForVeryHighDPI` option that explicitly says what it does
- alias the old option to that
- don't set any of those automatically in nixos-generate-config
Guest operating systems inside VMs or containers can't update the host CPU's microcode for obvious security reasons, so setting the `hardware.cpu.*.updateMicrocode` options is pointless.
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.
adding two graphical programs makes a strong assmuption that users will
use a graphical environment.
add a command line program as an alternative suggestion that is easy to
comment in as a first-steps measure.
This builds on top of nixpkgs mainline 00d83471803a8a308a52fc4b09b6ec41dfb36453
with the following two PRs cherry-picked:
- https://github.com/NixOS/nixpkgs/pull/192670
- https://github.com/NixOS/nixpkgs/pull/192668
using the following command:
```
nix build -f nixos -L \
-I nixos-config=nixos/modules/installer/sd-card/sd-image-powerpc64le.nix \
config.system.build.sdImage
```
I was able to successfully boot the image, although it boots to a login prompt
rather than a shell, and won't accept the empty password for `root`. I guess
I'll have to figure out why that is.
To boot the image: `zstd`-decompress the it, mount it, and use `kexec`:
```
cd boot/nixos
kexec -l \
*-vmlinux \
--initrd *-initrd \
--dt-no-old-root \
--command-line="$(grep APPEND ../extlinux/extlinux.conf | sed 's_^ *APPEND *__')"
```
The machine I used for testing has only one storage device which is completely
allocated to LVM. It appears that the NixOS ISO loader doesn't look for
partition tables within LVM volumes. To work aroundn this, I had to extract the
`ext4` image within the partition table within the `sd-card` image and put that
in its own LVM volume. This likely won't be an obstacle for users who write the
image to a USB stick or similar.
According to the Unicode Standard, you should use U+2019 RIGHT SINGLE
QUOTATION MARK for apostrophes [1]. Before this change, some of the text
in this repo would use U+2018 LEFT SINGLE QUOTATION MARKs instead.
[1]: https://www.unicode.org/versions/Unicode15.0.0/ch06.pdf#G12411
This moves the creation of the bind mount inside the `nixos-enter`
invocation. The command are executed in an unshared mount namespace, so
they can be run as an unprivileged user.
Although we don't really need HTML documentation in the minimal installer,
not including it may cause annoying cache misses in the case of the NixOS manual.
When installing NixOS in the target filesystem /mnt, paths relative to
configuration.nix in `initrd.secrets` are turned by Nix into absolute
paths that reference /mnt. While building the system derivation works,
installing the bootloader fails because the latter process takes place
inside the chroot environment where /mnt does not exist.
Ideally, we would also build the system within chroot, but this greatly
complicates the matter as it requires manually copying over Nix, its
runtime dependencies and all channels. Possibly, this would also break
several assumptions users have about how nixos-install works.
A simpler and safer (but less neat) solution is to temporarily bind
mount all mount points in /mnt under /mnt/mnt to keep the paths
functional while the bootloader is being installed.
This is essentially the workaround described in issue #73404.
