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 option can be set to disable installer tools like nixos-rebuild,
nixos-install, and nixos-generate-config (as well as more). This is
nice when a system is not expected to be rebuild or reconfigure itself
such as in a stateless PXE setup, as well as other embedded scenarios.
Note, that the system can still be updated, but it must either get
nixos-rebuild from another source, or, for embedded systems, be
upgraded by another machine like:
nix copy "$system" --to "ssh://root@<host>" && ssh "root@<host>"
"nix-env -p /nix/var/nix/profiles/system --set $system && $system/bin/switch-to-configuration switch".
Along with other options, this allows removing Perl from a closure.
For example:
{
boot.enableContainers = false;
environment.defaultPackages = [];
system.disableInstallerTools = true;
}
should not include Perl.
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
The only nix version available in the installer should be the version
configure in the module system. If someone needs `nixUnstable` in their
`nixos-install` they should probably set the module option and not just
add it to the closure.
$EDITOR is allowed to contain flags, so it is important to allow the
shell to split this normally. For example, Sublime Text needs to be
passed --wait, since otherwise it will daemonise.
$NIXOS_CONFIG can be set to a directory, in which case the file used
is $NIXOS_CONFIG/default.nix. This updates 'nixos-rebuild edit' to
handle that case correctly.
This allows to perform `dd if= of=$img` after the image is built
which is handy to add e.g. uBoot SPL to the built image.
Instructions for some ARM boards sometimes contain this step
that needs to be performed manually, with this patch it can be
part of the nix file used to built the image.
The nix store more-or-less requires o+rx on all parent directories.
This is primarily because nix runs builders in a uid/gid mapped
user-namespace, and those builders have to be able to operate on the nix
store.
This check is especially helpful because nix does not produce a helpful
error on its own (rather, creating directories and such works, it's not
until 'mount --bind' that it gets an EACCES).
Helps users who run into this opaque error, such as in #67465.
Possibly fixes that issue if bad permissions were the only cause.
This should have been done initially, as otherwise it gets awfully
awkward to boot into new generations by default.
This system-specific image wasn't expected to be long-lived, thus why it
didn't end up being polished much.
Reality shows us we may be stuck with it for a bit longer, so let's make
it easier to use for new users.
'nix build' is an experimental command so we shouldn't use it
yet. (nixos-rebuild also uses 'nix', but only when using flakes, which
are themselves an experimental feature.)
nix build should store it's temporary files on target filesystem.
This should fix 'No space left on device' on systems
with low amount of RAM when there is a need to build something
like Linux kernel
For imports, it is better to use ‘modulesPath’ than rely on <nixpkgs>
being correctly set. Some users may not have <nixpkgs> set correctly.
In addition, when ‘pure-eval=true’, <nixpkgs> is unset.
When trying to build a VM using `nixos-build-vms` with a configuration
that doesn't evaluate, an error "at `<unknown-file>`" is usually shown.
This happens since the `build-vms.nix` creates a VM-network of
NixOS-configurations that are attr-sets or functions and don't contain
any file information. This patch manually adds the `_file`-attribute to
tell the module-system which file contained broken configuration:
```
$ cat vm.nix
{ vm.invalid-option = 1; }
$ nixos-build-vms vm.nix
error: The option `invalid-option' defined in `/home/ma27/Projects/nixpkgs/vm.nix@node-vm' does not exist.
(use '--show-trace' to show detailed location information)
```
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"
```
Instead of making the configuration less portable by hard coding the number of
jobs equal to the cores we can also let nix set the same number at runtime.
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
Note we're not using wayland default in the graphical media because it
could cause headaches for Nvidia users. But the session is still available
if someone logs out.
In 0945178b3c we decided that Perl-based
VM tests should be deprecated and will be removed between 20.03 and
20.09. So let's switch `nixos-build-vms(8)` to python as well (which is
entirely interactive, so other scripts won't break).
In my experience, the test-driver isn't used most of the time, so this
patch is mainly supposed to get rid of the (probably misleading)
deprecation warning when running `nixos-build-vms`. Apart from that, the
interface for python's test-driver is way nicer.
In some cases, /dev/stderr may not point to a sensible location. For
example, running nixos-enter inside a systemd unit where the unit's
StandardOutput and StandardError are set to be sockets. In these
cases, this line would fail.
Piping to fd2 directly works just as well, even under strange and
twisted executions.
Co-authored-by: Michael Bishop <michael.bishop@iohk.io>
"master" is not a valid SHA-1 commit hash, and it's not even
necessarily the branch used. 'nixos-version --revision' now returns an
error if the commit hash is not known.
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 installing a fresh NixOS system it occasionally happens that you
encounter issues that are rather hard to track down since
`nixos-install(8)` doesn't provide any debugging flags.
This patch adds `-L` to force `nix build` to display the build-log on
stderr and `-v` to increase the log-level of Nix.
1. This makes aggregates of submodules (including the very important
"nixos-option users.users.<username>" case) behave the same way as any
other you-need-to-keep-typing-to-get-to-an-option-leaf (eg:
"nixos-option environment").
Before e0780c5:
$ nixos-option users.users.root
error: At 'root' in path 'users.users.root': Attribute not found
An error occurred while looking for attribute names. Are you sure that 'users.users.root' exists?
After e0780c5 but before this change, this query just printed out a raw
thing, which is behavior that belongs in "nix eval", "nix-instantiate
--eval", or "nix repl <<<":
$ nixos-option users.users.root
{
_module = {
args = { name = "root"; };
check = true;
};
createHome = false;
cryptHomeLuks = null;
description = "System administrator";
...
After this change:
$ nixos-option users.users.root
This attribute set contains:
createHome
cryptHomeLuks
description
extraGroups
group
hashedPassword
...
2. For aggregates of other types (not submodules), print out the option
that contains them rather than printing an error message.
Before:
$ nixos-option environment.shellAliases.l
error: At 'l' in path 'environment.shellAliases.l': Attribute not found
An error occurred while looking for attribute names. Are you sure that 'environment.shellAliases.l' exists?
After:
$ nixos-option environment.shellAliases.l
Note: showing environment.shellAliases instead of environment.shellAliases.l
Value:
{
l = "ls -alh";
ll = "ls -l";
ls = "ls --color=tty";
}
...
When running e.g. `nixos-option users.users.ma27`, the evaluation breaks
since `ma27` is the attribute name in `attrsOf (submodule {})`, but not
a part of the option tree and therefore breaks with the following
errors:
```
error: At 'ma27' in path 'users.users.ma27': Attribute not found
An error occurred while looking for attribute names. Are you sure that 'users.users.ma27' exists?
```
This happens since the option evaluator expects that either the option
exists or the option is a submodule and the "next" token in the
attribute path points to an option (e.g. `users.users.ma27.createHome`).
This patch checks in the `Attribute not found` condition if the attribute-path
actually exists in the config tree. If that's true, a dummy-attrset is created
which contains `{_type = "__nixos-option-submodule-attr";}`, in that case, the
entire entry of the submodule will be displayed.
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
Add --use-remote-sudo option. When set, remote commands will be prefixed
with 'sudo'. This allows using sudo remotely _without_ having to use
sudo locally (when using --build-host/--taget-host).
Automated consumers can use 'sed 1d' or similar to remove this header.
This probably makes this output *easier* to consume correctly. Having
this header show up in consumers' terminal or log output is probably not
useful, but hiding it without hiding all error messages would have been
more troublesome that just stripping it from stdout.
I.e., previously, unsophisticated use would show undesired output:
$ some-other-tool
This attribute set contains:
This attribute set contains:
This attribute set contains:
This attribute set contains:
<Actual some-other-tool output>
The simplest way to hide this undesired output would have been
nixos-option ... 2>/dev/null, which would hide all error messages.
We do not wish to encourage that.
Correct use would have been something like:
nixos-option ... 2> >( grep --line-buffered -v 'This attribute set contains:')
After this change, correct use is simpler:
nixos-option ... | sed 1d
or
nixos-option ... | sed '1/This attribute set contains:/d'
if the caller don't know if this invocation of nixos-option will yield
an attribute listing or an option description.
Switch from convention "appease clang-tidy --checks='*'" to
"References are like non-nullptr pointers". The clang-tidy check
"google-runtime-references" complains about non-const reference
arguments, but this is not a convention used in Nix.
Switch from convention "appease clang-tidy --checks='*'" to
"References are like non-nullptr pointers". The clang-tidy check
"google-runtime-references" complains about non-const reference
arguments, but this is not a convention used in Nix.
Switch from convention "appease clang-tidy --checks='*'" to
"References are like non-nullptr pointers". The clang-tidy check
"google-runtime-references" complains about non-const reference
arguments, but this is not a convention used in Nix.
I don't think this matters. As long as one or the other of these is
a std::string, I get an operator== that looks at content rather than
pointer equality. I picked casting the constant over casting the dynamic
thing in hopes that the compiler would have a better chance at optimizing
away any runtime cost.
Deferring to reviewer.
This is important because this contains some code copied from nix (as an
interim expediency until that functionality can be exported via nix's
API). The license specified here must be compatible with this borrowing.
Select the same license that nix is released under: lgpl2Plus.
Specifically, with
clang-format --style='{ IndentWidth: 4, BreakBeforeBraces: Mozilla, ColumnLimit: 120, PointerAlignment: Middle }'
which was the clang-format invocation that produced the fewest diffs on
the nix source out of ~20 that I tried.
Also add --all, which shows the value of all options. Diffing the --all
output on either side of contemplated changes is a lovely way to better
understand what's going on inside nixos.
This adds support for deploying to remote hosts without being root:
sudo nixos-rebuild --target-host non-root@host
Without this change, only root@host is able to deploy.
The idea is that if the local command is run with sudo, so should the
remote one, thus there is no need for adding any CLI options.
Slim is abandoned and won't work with wayland.
It's in our best interest to use the display-manager
that makes most sense for Plasma5, sddm.
We've already moved on from it being default in #30890
and the graphical.nix profile, which the virtualbox profile uses,
has sddm anyway.
I have `users.defaultUserShell = pkgs.fish;` set on my server and when I ran `nixos-rebuild switch --target-host …`, the command failed with the following error:
fish: Unsupported use of '='. To run 'nix-store' with a modified environment, please use 'env PATH=… nix-store…'
That is because fish requires env to set environment variables for a program. It should also work on other shells.
This sets networking.useDHCP to false and for all interfaces found the
per-interface useDHCP to true. This replicates the current default
behaviour and prepares for the switch to networkd.
There's many reason why it is and is going to
continue to be difficult to do this:
1. All display-managers (excluding slim) default PAM rules
disallow root auto login.
2. We can't use wayland
3. We have to use system-wide pulseaudio
4. It could break applications in the session.
This happened to dolphin in plasma5
in the past.
This is a growing technical debt, let's just use
passwordless sudo.
This will keep configuration configuring the size of the /boot partition
still build, while showing the deprecation warning.
In 99.9% of cases I assume ignoring the configuration is better, as the
sd-image builder already is pretty opinionated in that matter.
The slack, seemingly, accounted for more than the minimum required for
slack plus the two partitions.
This change makes the gap a somewhat abstracted amount, but is not
configurable within the derivation.
The current FAT32 partition is kept as it is required for the Raspberry
Pi family of hardware. It is where the firmware is kept.
The partition is kept bootable, and the boot files kept in there until
the following commits, to keep all commits of this series individually
bootable.
Up until now, the output has been the same for swap devices and swap
files:
{ device = "/var/swapfile"; }
Whereas for swap *files* it's easier to manage them declaratively in
configuration.nix:
{ device = "/var/swapfile"; size = 8192; }
(NixOS will create the swapfile, and later resize it, if the size
attribute is changed.)
With the assumption that swap files are specified in configuration.nix,
it's silly to output them to hardware-configuration.nix.
This will reduce the confusion at boot, where the only thing visible is
the last message from u-boot; where it looks like the board is
hung, while in reality it's likely resizing partitions.
This will reduce the confusion at boot, where the only thing visible is
the last message from u-boot; where it looks like the Raspberry Pi is
hung, while in reality it's likely resizing partitions.
Add "bcache" to boot.initrd.availableKernelModules if a bcache device is
detected.
This fixes a problem I've had one too many times: I install NixOS and
forget to add "bcache", resulting in an unbootable machine (until fixed
with Live CD). Now NixOS will do it for me.
cross-compilation of `btrfs-tools` is broken, and this usually needless dependency of each system closure on `btrfs-tools` prevents cross-compilation of whole system closures
Copy-paste from iso-image.nix
Besides the simplification, it should use `pkgs.buildPackages.squashfsTools` because it is used in `nativeBuildInputs` instead of incorrect `pkgs.squashfsTools` which was forced by `import'
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.
If setting a root password using the `passwd` call in the
`nixos-install` script fails, it should be explained how set it manually
to ensure that nobody gets accidentally locked out of the system.
If our old Nix can’t evaluate the Nixpkgs channel, try the fallback
from the new channel /first/. That way we can upgrade Nix to a newer
version and support breaking changes to Nix (like seen in the upgrade
o Nix 2.0).
This change should be backported to older NixOS versions!
This hasn't been needed for a long time, even when `mutableUsers =
false`. Setting a uid manually is potentially risky since it could
collide with non-declarative user accounts. (We do check for
collisions between declarative accounts.)
Also simplified the argument parsing to write all currently supported
CLI options into a bash array and pass this to `nix-build`.
Also documented `--option` usage in the corresponding manpage.
I've been asked, on numerous occasions, by my students and others, how
to 'sudo' on NixOS.
Of course new users could read up in the manual on how to do that, or we
could make it more accessible for them by simply making it visible in
the default `configuration.nix` file.
Additionally, as raised in [1], replacing `guest` with something more
recognizable could be potentially beneficial to new users. I've
opted for `jane` for now.
[1]: https://github.com/NixOS/nixpkgs/pull/54519#issuecomment-457012223
There are situations where several filesystems reside on a single encrypted LUKS
device (e.g. when using BTRFS subvolumes).
Simply generating a `boot.init.luks.devices.NAME.device` entry for each mounted
filesystem will result in an error later when evaluating the nix expression in
`hardware-configuration.nix`.
Since nix 2.0 the no-build-hook option was replaced by the builders options
that allows to override remote builders ad-hoc.
Since it is useful to disable remote builders updating nixos without network,
this commit reintroduces the option.
cleanSource does not appear to work correctly in this case. The path
does not get coerced to a string, resulting in a dangling symlink
produced in channel.nix. Not sure why, but this
seems to fix it.
Fixes#51025.
/cc @elvishjericco
This adds a NixOS option for setting the CPU max and min frequencies
with `cpufreq`. The two options that have been added are:
- `powerManagement.cpufreq.max`
- `powerManagement.cpufreq.min`
It also adds an alias to the `powerManagement.cpuFreqGovernor` option as
`powerManagement.cpufreq.governor`. This updates the installer to use
the new option name. It also updates the manual with a note about
the new name.
