@ofborg test boot

Are you able to come up with a test configuration that fails currently? I've tried enable boot.tmpOnTmpfs = true; but that still succeeds without this change. This bug should not occure again and thus we should have a test for this very commonly used option.

@andir FWIW without this change, a system rebuild succeeds because the tmpfs mount doesn't get cleaned up, but a reboot would fail. NixOS Tests can't really be used to test this afaict because they have their own implementation of tmpOnTmpfs inside nixos/modules/qemu-vm.

Another option would be re-adding systemd.additionalUpstreamSystemUnits = optional config.boot.tmpOnTmpfs "tmp.mount";

With that, you get something like

# /nix/store/q6ylicsava582g55mdx0788yg2fib7js-systemd-246.6/example/systemd/system/tmp.mount
#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Temporary Directory (/tmp)
Documentation=https://systemd.io/TEMPORARY_DIRECTORIES
Documentation=man:file-hierarchy(7)
Documentation=https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
ConditionPathIsSymbolicLink=!/tmp
DefaultDependencies=no
Conflicts=umount.target
Before=local-fs.target umount.target
After=swap.target

[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=mode=1777,strictatime,nosuid,nodev,size=50%,nr_inodes=400k

# /nix/store/xgxf0nqiimbzmvzrqz77xrdbijdkkiy0-system-units/tmp.mount.d/overrides.conf
[Unit]

[Mount]
Options=mode=1777,strictatime,rw,nosuid,nodev,size=50%,huge=within_size
What=tmpfs
Where=/tmp

@ajs124 thats my preference too, but I wanted to avoid starting a revert/re request cycle if I could help it, while in the mean time systems are unbootable

EDIT: https://logs.nix.samueldr.com/nixos/2021-01-10#1610240617-1610240313

(In summary: I don't have a preference for which PR is merged.)

systemd doesn't merge these options, but overwrites. So even with #108881, you'd have no inode limit.

@ajs124 , @endocrimes I'm a bit lost on if this or #108881 is the right way forward, which work, and which one is cleaner. Can you sort that out, so we can merge one fix or the other?

@Floki sure - @ajs124 if your override gets reduced to just the mount options and you add a comment explaining the override behavior then I'd go for that over this PR.

Tracking systemd defaults automatically is the better behavior IMO.

FYI: where is necessary because it's what the unit's name is derived from (#108881 (comment)).

I think we should stick with this PR. It is precise in what it does and we can update it when needed. Upstream systemd shouldn't be the authorative source for how things are done but rather a source for inspiration and guidance.

Also using upstream units is what got us into this situation in the first place. We have the ability to merge options properly without weird empty line hacks etc..

Works on my machine.