Store the definition files in the initrd instead of reading them from
the Nix store in /sysroot.
This way, the initrd has to be re-generated every time the definition
files change. When the path to the defintion files instead of the
definition files themselves are embedded in the initrd, however, the
initrd also has to be re-generated every time. In this regard, this
change does not improve the status quo.
However, now systemd-repart also works reliable when the Nix store is
mounted separately from the root partition.
This change also enables new use-cases like creating partitions
necessary to boot the system. However, by default, the root partition
cannot be created on first boot because the systemd-repart service
requires a /sysroot to be mounted. Otherwise, systemd-repart cannot
determine the device to operate on.
Since v253, systemd-repart tries to create temporary directories in
/var/tmp. However, this directory doesn't exist in the initrd. This
commit adds an enviroment variable to re-use the existing /tmp directory
instead of /var/tmp.
Previously, we hardcoded a 60 second timer to stop netdata if we didn't have any answer back.
This is wrong and can cause data loss because the SIGTERM sent by systemd can sometimes be not honored.
Which in turn becomes a SIGKILL, causing potential data loss / corruption.
Offer a flag to users and bump the deadline to 2 minutes.
Because llvmPackages_latest is used in Nixpkgs, by quite a few
packages, it's difficult to keep it up to date, because updating it
requires some level of confidence that every package that uses it is
going to keep working after the update. The result of this is that
llvmPackages_latest is not updated, and so we end up in the situation
that "latest" is two versions older than the latest version we
actually provide. This is confusing and unexpected.
"But won't this end up fragmenting our LLVM versions, if every package
previously using _latest is separately pinned to LLVM 14?", I hear you
ask. No. That fragmentation is already happening, even with an
llvmPackages_latest, because packages that actually require the
_latest_ version of LLVM (15/16), have already been decoupled from
llvmPackages_latest since it hasn't been upgraded. So like it or not,
we can't escape packages depending on specific recent LLVMs. The only
real fix is to get better at keeping the default LLVM up to
date (which I'm reasonably confident we're getting into a better
position to be feasibly better able to do).
So, unless we want to double down on providing a confusingly named
"llvmPackages_latest" attribute that refers to some arbitrary LLVM
version that's probably not the latest one (or even the latest one
available in Nixpkgs), we only have two options here: either we don't
provide such an attribute at all, or we don't use it in Nixpkgs so we
don't become scared to bump it as soon as we have a new LLVM available.
Context summary:
'vma create' can't otherwise write to tmpfs such as /dev/shm.
This is important when used from non-nixos machines which may
have /build as tmpfs.
VMA is Proxmox's virtual machine image format that wraps QEMU images,
augmenting these with proxmox-specific configuration file.
proxmox-image.nix uses the VMA tool to create vma image files.
The VMA tool exists as a patchset ontop of QEMU.
VMA writes its output with open() and O_DIRECT flag.
O_DIRECT does not work on Linux tmpfs [1]. Thus:
$ vma create ~/output.vma ... # works, assuming home isn't tmpfs.
$ vma create /dev/shm/output.vma ... # fails since /dev/shm is tmpfs
Failure results in assert(*errp == NULL).
O_DIRECT is a cache performance hint.
But it currently blocks our usage of nixos-generate -f proxmox from
Non-NixOS hosts and Docker.
The patch here simply removes O_DIRECT:
vma-writer.c later performs memalign due to O_DIRECT, but this is
safe to do with or without O_DIRECT.
Ideally, this should be fixed in upstream Proxmox: Perhaps by falling
back to open without O_DIRECT.
Another attempt to fix this SIGABRT is [2], which writes the vma file
directory to $out/ folder -- however that may still be tmpfs mounted
which it is in our case.
[1] https://lore.kernel.org/lkml/45A29EC2.8020502@tmr.com/t/
[2] https://github.com/NixOS/nixpkgs/pull/224282
This allows modules that declare their class to be checked.
While that's not most user modules, frameworks can take advantage
of this by setting declaring the module class for their users.
That way, the mistake of importing a module into the wrong hierarchy
can be reported more clearly in some cases.
