Looks like GRUB has issues loading EFI binaries from (cd0), which is
what would be used in e.g. qemu with OVMF with `-cdrom`. Apparently also
what is used with AArch64 + U-Boot USB.
The serial output (but it's named console, not serial actually) causes
issues on U-Boot's EFI, at the very least.
This is inspired by OpenSUSE's approach:
* https://build.opensuse.org/package/view_file/Base:System/grub2/grub2-SUSE-Add-the-t-hotkey.patch
Where they add a hidden menu entry, which can be used to force the
console output.
The `echo` will be visible on the serial terminal (grub "console"),
while the graphical interface is shown. Note that input in the serial
terminal (grub "console") will continue controlling the graphical
interface. Useful if you have an SBC connectedinto an HDMI monitor, but
no keyboard connected to it.
This is supeer useful to allow the normal sd-image code to be used by
someone who wants to setup multiple partitions with a sd-image.
Currently I'm manually copying the sd-image file and modifying it
instead.
Since 03eaa48 added perl.withPackages, there is a canonical way to
create a perl interpreter from a list of libraries, for use in script
shebangs or generic build inputs. This method is declarative (what we
are doing is clear), produces short shebangs[1] and needs not to wrap
existing scripts.
Unfortunately there are a few exceptions that I've found:
1. Scripts that are calling perl with the -T switch. This makes perl
ignore PERL5LIB, which is what perl.withPackages is using to inform
the interpreter of the library paths.
2. Perl packages that depends on libraries in their own path. This
is not possible because perl.withPackages works at build time. The
workaround is to add `-I $out/${perl.libPrefix}` to the shebang.
In all other cases I propose to switch to perl.withPackages.
[1]: https://lwn.net/Articles/779997/
It was introduced in c10fe14 but removed in c4f910f.
It remained such that people with older generations in their boot
entries could still boot those. Given that the parameter hasn't had any
use in quite some years, it seems safe to remove now.
Fixes#60184
The `platform` field is pointless nesting: it's just stuff that happens
to be defined together, and that should be an implementation detail.
This instead makes `linux-kernel` and `gcc` top level fields in platform
configs. They join `rustc` there [all are optional], which was put there
and not in `platform` in anticipation of a change like this.
`linux-kernel.arch` in particular also becomes `linuxArch`, to match the
other `*Arch`es.
The next step after is this to combine the *specific* machines from
`lib.systems.platforms` with `lib.systems.examples`, keeping just the
"multiplatform" ones for defaulting.
Minimal ISO:
1m21 -> 2m25
625M -> 617M
Plasma5 ISO:
2m45 -> 5m18
1.4G -> 1.3G
Decompression speed stays about the same. It's just a few seconds for the whole
image anyways and, with that kind of speed, you're going to be bottlenecked by
IO long before the CPU.
It's been 8.5 years since NixOS used mingetty, but the option was
never renamed (despite the file definining the module being renamed in
9f5051b76c ("Rename mingetty module to agetty")).
I've chosen to rename it to services.getty here, rather than
services.agetty, because getty is implemantation-neutral and also the
name of the unit that is generated.
As per the in-line comment, this is where distros should configure it.
Not via kernel command line parameters.
As found by looking at the implementation, while exploring the cause of
a bug on the Raspberry Pi 4, it was found that `cma=` on the command
line parameters will overwrite the values a device tree will have
configured for a given platform.
With this, the more recent 5.4 vendor kernel boots just fine on the
Raspberry Pi 4 using our common configuration.
This includes setting up everything for the mainline Raspberry Pi 4
image.
In fact, the only difference left in the Raspberry Pi 4-specific image
is the kernel from the vendor.
Prior to this commit, installation over serial console would requiring
manually having to modify the kernel modeline, as described in
https://github.com/NixOS/nixpkgs/issues/58198 .
This is unnecessarily fiddly, so this commit adds a syslinux boot
entry that has serial enabled.
GRUB already has a serial console entry:
2c07a0800a/nixos/modules/installer/cd-dvd/iso-image.nix (L311-L317)
Why 115200 bps? This is already used in other places, e.g. https://github.com/NixOS/nixpkgs/pull/58196
I tested this change by building the image, booting the image, and
observing the boot process over serial:
$ cd nixos/
$ nix-build -A config.system.build.isoImage -I nixos-config=modules/installer/cd-dvd/installation-cd-minimal.nix default.nix
$ sudo cp /nix/store/arcl702c3z8xlndlvnfplq9yhixjvs9k-nixos-20.09pre-git-x86_64-linux.iso/iso/nixos-20.09pre-git-x86_64-linux.iso /dev/sdb
$ picocom -b 115200 /dev/ttyUSB0
This reverts commit aab534b894 & uses the
driverInteractive attribute for the test driver instead.
This has the same effect but removes the extra module in the
nixos-build-vms code.
When I test a change e.g. in the module system manually, I usually use
`nixos-build-vms(8)` which also gives me a QEMU window where I can play
around in the freshly built VM.
It seems as this has changed recently when the default package for
non-interactive VM tests using the same framework was switched to
`pkgs.qemu_test` to reduce the closure size. While this is a reasonable
decision for our CI tests, I think that you really want a QEMU window of
the VM by default when using `nixos-build-vms(8)`.
[1] bc2188b083
