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...
The value of du output depends on the underlying file system, and thus is not fully deterministic. This workaround rounds up the disk usage size to the nearest multiple of 1MB, to increase the probability that two du output values on two different file systems fall within the same 1MB window. Note that this workaround won't make du output 100% reproducible, but will increase the probability of getting deterministic builds across different file systems.
mcopy file globbing is non-deterministic with respect to the underlying file
system. As a result, the current mcopy approach is less likely to reproduce
efi.img on different machines. We replace mcopy file globbing with
fixed-order mmd and mcopy operations for better determinism. We also use
faketime on mmd for the same reason. We use faketime, mmd, and mcopy
directly, becase they are already in PATH.
Thank misuzu@ for the feedback.
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.
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.
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
we use stdenv.hostPlatform.uname.processor, which I believe is just like
`uname -p`.
Example values:
```
(import <nixpkgs> { system = "x86_64-linux"; }).stdenv.hostPlatform.uname.processor
"x86_64"
(import <nixpkgs> { system = "aarch64-linux"; }).stdenv.hostPlatform.uname.processor
aarch64
(import <nixpkgs> { system = "armv7l-linux"; }).stdenv.hostPlatform.uname.processor
"armv7l"
```
The volumeID will now be in the format of:
nixos-$EDITON-$RELEASE-$ARCH
an example for the minimal image would look like:
nixos-minimal-20.09-x86-64-linux
In 87a19e9048 I merged staging-next into master using the GitHub gui as intended.
In ac241fb7a5 I merged master into staging-next for the next staging cycle, however, I accidentally pushed it to master.
Thinking this may cause trouble, I reverted it in 0be87c7979. This was however wrong, as it "removed" master.
This reverts commit 0be87c7979.
I merged master into staging-next but accidentally pushed it to master.
This should get us back to 87a19e9048.
This reverts commit ac241fb7a5, reversing
changes made to 76a439239e.
When 'grafting' '/nix/store/<hash>-loopback.cfg' from disk onto
'/boot/grub/loopback.cfg' on the iso, the parent 'grub' directory does not
exist yet. In this case it is automatically created and inherits its
attributes, including timestamp, from /nix/store.
This is correct/expected/intentional behavior of xorriso, but has the
undesired result of leaking the timestamps of /nix/store into the iso. For
this reason we put the loopback.cfg in a
'/nix/store/<hash>-loopback.cfg/grub/loopback.cfg' instead, so it will inherit
the attributes from the correctly-timestamped
'/nix/store/<hash>-loopback.cfg/grub' directory.
For the same reason we move '/EFI/boot/efi-background.png' down in the list
so it is grafted after its parent '/EFI/boot' directory is created with
the correct timestamp.
fixes#74944
Prior to this commit an installation over serial via syslinux would
involve:
1. setting bitrate to BIOS's bitrate (typically 115200)
2. setting bitrate to syslinux's bitrate (38400)
3. setting bitrate to stty's bitrate (115200)
By changing syslinux's bitrate to 115200, an installation over serial
is a smoother experience, and consistent with the GRUB2 installation
which is also 115200 bps.
[root@nixos:~]# stty
speed 115200 baud; line = 0;
-brkint ixoff iutf8
-iexten
In a future commit I will add default serial terminals to the syslinux
kernel lines.
```
b Batch mode. Optimized for huge recursive copies, but less secure if a crash happens during the copy.
```
It seems the "less secure if a crash happens" does not need a crash to
happen.
With batch mode:
```
/[...]/.
Start (0) does not point to parent (___)
```
For pretty much everything copied in.
Without batch mode, everything passes `fsck`.
See #51150
This is a 277K (as of right now) addition that can greatly help in some
last recourse scenarios. The specific rEFInd setup will not be able to
boot the installer image, but this is not why it has been added. It has
been added to make use of its volumes scanning capabilities to boot
existing EFI images on the target computer, which is sometimes necessary
with buggy EFI. While is isn't NixOS's job to fix buggy EFI, shipping
this small bit with the installer will help the unlucky few.
Example scenario: two wildly different EFI implementation I have
encountered have fatal flaws in which they sometimes will lose all the
settings, this includes boot configuration. This is compounded by the
fact that the two specific and distinct implementation do not allow
manually adding ESP paths from their interface. The only recourse is to
let the EFI boot the default paths, EFI/boot/boot{platform}.efi, which
is not a default location used by the NixOS bootloaders. rEFInd is able
to scan the volumes and detect the existing efi bootloaders, and boot
them successfully.
Following up https://github.com/NixOS/nixpkgs/pull/23665
Bootable USB-drives are not limited to ISO-images, there can be "normal" MBR/GPT-partitioned disk connected via USB-rack.
Also, "uas" implies "usb-storage", so there is no need to mention both.
Add another option for debugging instead. Lots of users have been
complaining about this default behaviour.
This patch also cleans up the EFI bootloader entries in the ISO.
Allow usage of list of strings instead of a comma-separated string
for filesystem options. Deprecate the comma-separated string style
with a warning message; convert this to a hard error after 16.09.
15.09 was just released, so this provides a deprecation period during
the 16.03 release.
closes#10518
Signed-off-by: Robin Gloster <mail@glob.in>
Setting nixosVersion to something custom is useful for meaningful GRUB
menus and /nix/store paths, but actuallly changing it rebulids the
whole system path (because of `nixos-version` script and manual
pages). Also, changing it is not a particularly good idea because you
can then be differentitated from other NixOS users by a lot of
programs that read /etc/os-release.
This patch introduces an alternative option that does all you want
from nixosVersion, but rebuilds only the very top system level and
/etc while using your label in the names of system /nix/store paths,
GRUB and other boot loaders' menus, getty greetings and so on.
We seem to be in an unfortunate situation: booting without 'nomodeset'
causes hangs when booting on some NVIDIA cards (6948c3ab80), but on the
other hand adding 'nomodeset' prevents X from starting on other hardware
(e.g. issue #10381 and my Thinkpad X250 with an integrated Broadwell GPU).
Attempt to remedy this situation a bit by adding a separate entry in the
ISOLINUX menu (with the non-'nomodeset' being the default).
It comes in handy to alter the menu label if you're not building a NixOS
installer image but for example if you want to build a live system and
still want to re-use the iso-image.nix module.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes#6795.
This was co-authored with @bobvanderlinden.
(cherry picked from commit e19ac248ae59fd327c32b1ae3e37792c22a7c7ac)
Signed-off-by: Domen Kožar <domen@dev.si>
Conflicts:
nixos/modules/installer/cd-dvd/iso-image.nix
There are a number of hidden restrictions on the syslinux
configuration file that come into play when UNetbootin
compatiblity is desired. With this commit these are documented.
This changes the bootloader for iso generation from Grub to
syslinux. In addition this adds USB booting support, so that
"dd" can be used to burn the generated ISO to USB thumbdrives
instead of needing applications like UnetBootin.
This changes the bootloader for iso generation from Grub to
syslinux. In addition this adds USB booting support, so that
"dd" can be used to burn the generated ISO to USB thumbdrives
instead of needing applications like UnetBootin.
Should bring most of the examples into a better consistency regarding
syntactic representation in the manual.
Thanks to @devhell for reporting.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
