| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the options in nix.conf are now exposed as a submodule with a
freeform type and since that change[1] got introduced, we get a bunch of
warnings during machine evaluation:
trace: warning: The option `nix.useSandbox' defined in `...' has been renamed to `nix.settings.sandbox'.
trace: warning: The option `nix.maxJobs' defined in `...' has been renamed to `nix.settings.max-jobs'.
trace: warning: The option `nix.buildCores' defined in `...' has been renamed to `nix.settings.cores'.
To shut them up, I went through all machines and modules and renamed the
remaining options that were not renamed back then when @devhell did some
renames in a0297bf921399c3243dcca99626d8697f0735abe.
This was done by looking through the output of:
$ git grep -A 10 '\<nix\(\.\| *=\)' machines modules
After that I tested the contents of the nix.conf of all the machines
against the changes this commit introduced via the following command:
$ nix-build --no-out-link -E '
with import <nixpkgs/lib>;
map (m: m.eval.config.environment.etc."nix/nix.conf".source)
(collect (m: m ? eval) (import ./machines))
'
I've sorted the resulting nix.conf files and diffed on that result and
the only difference that showed up was the following:
allowed-users = *
-auto-optimise-store = false
auto-optimise-store = true
builders-use-substitutes = true
cores = 0
This is because the previous way to generate the config was by
concatenating strings whereas the new way works on an attribute set, so
we get deduplication by design.
[1]: https://github.com/NixOS/nixpkgs/pull/139075
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @devhell
Cc: @Profpatsch
Cc: @sternenseemann
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Another thing that was lurking around in configuration.nix, so it has
been battle-tested for weeks. Given that all the layers from the
hardware up to the LUKS container with the filesystem support discard,
it does make sense to enable it.
The disadvantage of using discard with LUKS is that attackers can now
gain information about the file system in use. However, this is already
public knowledge so given that discard increases performance, I decided
to enable it despite some warnings[1] out there.
[1]: https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
| |
Another thing that was hanging around in configuration.nix and with my
new hardware it actually became useful since it does have capsule
updates.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is one of the few things that I originally added manually, simply
because usually printing is not something I do regurarily.
Since I had to re-do the CUPS config a few weeks ago, I decided to
instead switch to ensurePrinters, simply because it makes it easier to
just remove all the CUPS state and get to a known working configuration
in the event that something breaks.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
| |
The user shouldn't have direct access to the /dev/snd/* but go through
things such as pulseaudio or pipewire. I added the user to that group
back then as a workaround to quickly get something[TM] working, but
nowadays it's not needed anymore.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
| |
I no longer have a scanner that requires to have hplip and/or any of the
proprietary parts of it, so let's keep it out of the machine
configuration.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
| |
Workspace one is usually my "communications workspace" and since I've
been using Psi as my go-to XMPP client, it's a good idea to add it to
that workspace, even though I usually start it on that workspace anyway.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I already had this in my configuration.nix for quite some time and it's
part of my overly complicated[TM] audio setup where I combine multiple
speaker systems into one using two sound cards.
Since the mapping depends on the individual channels, it's very much
important to address the right sound card. So while I'm re-doing my
whole audio setup, I decided to get at least the udev part out of my
very messy configuration as a first start.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first (small) part of this already started in commit
dc2ef245d76f900f174e87961a3d17e6aecbd6e2, where I switched from Intel
CPU microcode to AMD.
However, at that time the hardware was still on its way, so the actual
move didn't happen yet.
On June 4th 2021 at 17:22:41 CEST, I started to migrate to the new
machine by using my old spinning rust configuration and btrfs balanced
to NVMe-only.
This means that we now no longer need to use bcache, which was a 512 GB
SATA SSD, nor do we use a RAID10 configuration in btrfs. Instead, I've
switched to NVMe with RAID1 exclusively, so this removes BFQ, power
management workarounds and two devices.
Since my old graphics card didn't work with UEFI GOP, I also had to
switch to a newer one (which I wanted to avoid, but whatever...), so
instead of DVI and HDMI we're now exclusively on DisplayPort.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
| |
After all the goal was to move all hardware specific stuff to the actual
machine definition, which includes the boot loader.
Since GRUB is enabled by default but with a higher priority value, we
now no longer need to mkForce-disable the option for machines using
systemd-boot.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
| |
The new hardware for dnyarri no longer contains an Intel CPU, so apart
from switching the microcode updates to AMD I also removed the setting
from the base profile because it clearly doesn't belong there.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Injecting pre/post start scripts into services called
"btrfs-scrub-.service.service" isn't going to do a whole lot if the
actual service name is called "btrfs-scrub-.service".
During the last scrub I was wondering why caching got slow afterwards
and found out that the caching devices were filled with lots of
irrelevant data from the scrub. This led me to inspect what went wrong
and when checking the properties of the scrub service unit, I found out
that it never worked in the first place for the reason meantioned in the
first paragraph.
Actually using the right unit name helps a lot here, so onwards to the
next scrub in February :-)
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I already have this running in writethrough for long enough so that I'm
pretty confident that a disaster like last time[1] should not happen
anytime soon so that hereby I'm making this permanent in the machine
configuration.
The reason why I set this to writearound initially instead of
writethrough, was that I just wanted to go with the most conservative
option first.
Of course, during scrub, we still disable all caching, so we should not
generate too much wear on the SSD.
[1]: 15008e69542774c441e388ad4c2e28a2d27f9ba0
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
| |
I've had this laying around in my configuration.nix since quite a while,
but today is one of those days where I can't stand all the cruft piling
up there anymore and decided to add it here.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm using gPodder to follow a bunch of YouTube channels and the internal
extractor/downloader tends to be pretty unreliable.
On the other hand, youtube-dl is regularily updated and supports a ton
of different formats.
To make sure we can actually use the extension, gPodder needs to have
access to the youtube_dl Python module, so we need to add it to the
propagatedBuildInputs.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The use of types.loaOf has been deprecated since quite a while and
lately[1] there is also an appropriate warning in place if an option
definition relies on types.loaOf to coerce the list to an attrset.
In vuizvui we didn't rely on types.loaOf, but it turned out that dnyarri
still relied on it in boot.initrd.luks.devices.
Since we already use attrsets for defining the LUKS devices, it's rather
easy to fix and we just need to return a nameValuePair in mkDevice.
[1]: https://github.com/NixOS/nixpkgs/commit/03309899eb41e50ef65001f63d6a4f078e3d4556
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The usage of DHCP is no longer global since a while[1] and we now have
to explicitly enable it for the interfaces in question.
This actually is a good thing and makes it far less problematic if we
use tunnel interfaces and other more complicated networking
configuration.
I added the definitions for all machines where I actually know which
interfaces are in use and disabled useNetworkd for shakti, because I
don't know the interface names for that machine and the machine
currently isn't in use anyway, so we can add it later if needed.
[1]: https://github.com/NixOS/nixpkgs/pull/69302
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since NixOS/nixpkgs@c814d72b517bb201c8bbbfc64e386c7023352886, a lot of
packages now no longer have a name attribute but instead use pname, so
when checking the package name within allowUnfreePredicate we need to
make sure that we fall back to a default if the name attribute is not
present.
This fixes evaluation of the machine, however I didn't check if it
actually builds.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I did have a major outage this week, because I was using bcache with
writeback mode on a RAID10 backing storage. Fortunately, I was able to
recover 99.9% of the data (only the most recent stuff wasn't
recoverable), but I certainly don't want this to happen again in the
future.
While I did use bcache with hibernate and writeback, the interesting
part is that the caching device went bonkers after a "normal" shutdown
rather than a suspend/hibernate, with "normal" being "with a bunch of
kernel warnings about zswap". Also, this happened around a btrfs scrub,
so the inconsistency was all over the place.
So first of all, I'm now going with writaround mode rather than
writeback mode for the time being. Although it's slower than writeback,
the chances that I need to do such a recovery again is close to 0% with
writethrough and writearound because all writes are synchronous.
Second, this very change makes sure that whenever the machine goes to
sleep or a scrub is started, the caching is disabled and afterwards it's
re-enabled. That way we shouldn't have lots of trash on the caching
device.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
| |
I had this in my local configuration.nix since a while and while it
might be annoying when this runs every month, I think it's better to do
it regularily rather than having a dying disk go unnoticed.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
| |
Since quite a while, NixOS re-uses the passphrases from earlier devices,
so there is no need anymore for such a device in order to unlock
multiple containers with the same passphrase.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
| |
The "luksClose" subcommand for cryptsetup has been deprecated for a
while, so let's move over to "close".
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since I got a new SSD for the machine (thanks @cvdnext), I also had the
opportunity to re-create my LUKS containers to LUKS2 with Argon2 key
derivation alongside creating bcache backing devices.
The change in order to support bcache is just a matter of adding
"bcache" to availableKernelModules and we're done.
However, as the storage configuration is not a very common one, I
decided to add a test specific to that to make sure future NixOS updates
won't prevent the machine from booting.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
| |
The upstream version 0.6.4 was released 2 months ago and it recently hit
nixpkgs[1], so we can finally drop the override as the new version now
contains the fix[2] for the problem that affected me.
[1]: https://github.com/NixOS/nixpkgs/commit/5e2590ba6fd352bc65b4cd7fd82
[2]: https://github.com/gpodder/podcastparser/pull/17
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
| |
Similar to 8562389f5e13e42329fc26ca53e9cf54ac0e541e but now for dnyarri.
I grew a bit tired recently to fix up kernels, so let's actually run the
latest release version instead.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
| |
These were needed a few months ago but they're now automatically added
if boot.initrd.luks.devices is non-empty.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
| |
I've put in an assertion back then to make sure that once gpodder 3.10.1
is released, we get a failure so we don't stay behind forever.
With NixOS/nixpkgs@4d1e72cfbb8de0d8adf2c047aad14f29eb4f77bf, not only
the version is bumped but also the icon theme is added back, so we can
drop the whole override of the attributes.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is needed in order to correctly display icons if someone doesn't
use a full desktop environment.
I'm not sure why NixOS/nixpkgs@bff6d624e05c53777a9d2fd85872884983f74313
removed this (in particular gnome3.defaultIconTheme, but
hicolor_icon_theme should be enough anyway), but let's re-add it for our
configuration until this is sorted out.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Seems that 543ca6580d6f52d58caf975c0ed583956aa08b39 was not enough to
fix the actual issue, because the real issue was in podcastparser.
The upstream issue is gpodder/gpodder#394 and the pull request fixing
this is gpodder/podcastparser#17.
Instead of just updating podcastparser, I also updated gpodder to latest
master, because it contains a few more fixes.
I've tested whether this fixes my issue and it did (feed items now have
the correct date).
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
| |
I've been using this for a while and got better results than zlib and
lzo, so let's actually use this for all my machines.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
| |
This is mainly to get gpodder/gpodder@c937184987431427dfcf8ac9bc098ce0ac
but there are other fixes in the current master version, so instead of
just patching the single fix, I'm heading for master directly instead.
I've also added an assertion on the version attribute so that whenever
there is a new upstream version, we can revert this.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
| |
I'm using Firefox now and also having a label which only says "Browser"
is a bit more browser-agnostic.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
| |
Actually this is the only one workstation where I use gpodder, so let's
move it there and also don't make it a lazy package.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This dissolves the user.aszlig.system.kernel module, which was not only
to stay on the latest bleeding edge kernel but also to enable BFQ. The
latter has been factored out already a while ago already.
Originally, I had a fully custom kernel config for mmrnmhrm and dnyarri,
but it's no longer the case and thus the user.aszlig.system.kernel
module is now no longer needed.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two other occasions where packageOverrides are still in use,
one of them is @sternenseemann's fliewatuet machine and another one is
@devhell's package profile.
I've replaced every other occurence of packageOverrides and replaced it
with overlays and checked the store path hash after evaluation.
The reason why I left @sternenseemann's fliewatuet alone was that for
I wasn't quite sure whether "bluez = pkgs.bluez5" is still needed or
intentional to pin it to version 5. Because if it's not the case the
packageOverrides can just be dropped because bluez is already bluez5 in
upstream <nixpkgs>.
For @devhell's package profile, I did the conversion, but the store path
turned out to be a different one than what it was prior to the change.
I did take a quick look at the requisites of the drv and found that sox
was one of the different paths that led to the change in the final store
path.
This obviously needs to be tested and/or investigated first.
Other than that, the main reason why I'm moving everything to overlays
is that it's the replacement for packageOverrides and also has a better
way to pass through chains of overrides than packageOverrides had.
My guess is that after NixOS 17.09, the old packageOverrides function
will be removed, so let's make sure we're ready for that.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @devhell, @sternenseemann
|
|
|
|
|
|
|
|
| |
We only use the firmware blobs for the CPU microcode and the GPU, both
of them are redistributable so there is no need to enable those that
have even more licensing restrictions.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
| |
The derivation name now is just "hplip-VERSION" (eg. "hplip-3.16.11")
instead of "pythonX.Y-hplip-VERSION".
The upstream commit changing this was:
NixOS/nixpkgs@3760c8c7fde6e8b15d19b063579d05018fc2d8b3
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts the following commits:
* f34f60216a94f41e684b2b2a29be9ca5f8f72940
* fb6cd06936a469fad708e1095b5ee25ad1298375
Using permittedInsecurePackages on all my machines isn't something I
want to pursue, because this really affects *one* single package and I
really don't want to whitelist webkitgtk-2.4.11 across all of my
machines.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately, mmrnmhrm has died because of three blown up capacitors
which resulted in hard shut downs due to CPU0 temperature values that
were out of range.
At first I assumed a real temperature problem and thus vacuumed the fan
and everything else, applied new thermal paste and it still failed after
a few minutes. What I found a bit odd was the fact that the machine
powered off even though the last reading of the CPU temperature was 40
degrees Celsius, so that definitly wasn't the problem.
So I went on to look for any blown capacitors on the main board, because
that's probably one of the most frequent cause of hardware failure... at
least for mainboards and monitors. One of the three capacitors I found
to be leaking seems to be leading to the CPU temperature sensor as far
as I can tell (I didn't test with a multimeter though, because I have
lent it out to someone else).
While it shouldn't be hard to fix the blown capacitors (apart from the
fact that we had national holiday during the Easter week), my long-term
goal was to make mmrnmhrm obsolete anyway, so it was a good opportunity
to do exactly that.
The reason why I wanted to get rid of mmrnmhrm was that it has been a
very slow machine since commit 2df7ee103a01da34c9c82235bc286dde35e0f1ba,
which was essentially a hardware downgrade back then.
Dnyarri always has been the better machine hardware-wise but I couldn't
use it to its full potential because it had a cooling issue. The latter
has been resolved a few weeks ago, where I replaced the CPU fan and it's
now not only less noisy but stays at below 50 degrees Celsius even on
high load.
Merging mmrnmhrm into dnyarri also means, that we now have a new disk
layout:
+---------------+--------------+--------------+--------------+
| Disk 1 | Disk 2 | Whole disk 3 | Whole disk 4 |
+---------------+--------------+--------------+--------------+
| EFI partition | crypt-vault | crypt-root-3 | crypt-root-4 |
| crypt-swap-1 | crypt-swap-2 +-----------------------------+
| crypt-root-1 | crypt-root-2 |
+---------------+--------------+
Disk 1 and 2 use GUID partitions while disk 3 and 4 don't have a
partition table but use btrfs across the whole device. The crypt-vault
partition is solely for unlocking other crypto volumes so that a single
passphrase unlocks all of the LUKS containers rather than needing to
provide 6 passphrases.
Also, I've migrated to using UEFI for booting, which is why there now is
an EFI partition as well. Having no redundancy on the EFI and the
crypt-vault partitions doesn't hurt so much because in the event of
drive failure all of the containers can still be unlocked via a
passphrase instead of the vault key.
Disk 3 and 4 are the disks that were formerly installed into mmrnmhrm
and now comprise one big btrfs volume together with the two disks (1 and
2) already present inside dnyarri.
Instead of RAID1 on data and metadata, the btrfs file system layout now
is RAID10 for data and metadata.
This merge also removes synergy for obvious reasons (no other machine
anymore) and disables kmscon because it was just a test in the first
place and I found it a bit annoying to work with.
Summary: Mmrnmhrm is (are?) dead, long live dnyarri!
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
| |
webkitgtk-2.4.11 is insecure, I am whitelisting it for now to fix the
evaluation errors on the hydra.
Consider, what you want to do on the issue long term, or just revert
this commit as soon as the CVEs are fixed upstream, @aszlig!
|
|
|
|
|
|
|
|
|
|
|
| |
This machine is used for collecting all that useless paperwork gathered
since a few years, so I need scanner support.
Unfortunately the scanner (it's part of a HP Officejet all-in-one
thingy) needs to have a proprietary plugin for hplip in order to work,
which is not nice and I'm not very proud about needing to do this.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
| |
I now prefer to explicitly state the function along with the "lib."
namespace instead of making it available over the whole scope of the
module.
One of the main reasons for this is that you can do early error checking
with nix-instantiate --parse.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
I use this machine to archive all the crap that's piling up over the
years and paperwork is quite useful in this regard :-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
| |
This is needed mostly for the GPUs and for KMS to hopefully work.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've been patching these machines up since ages and I'm tired now to do
both kernel configs *again* for the recent kernel versions.
Of course, in the long run I still want them to have their customized
kernel, but right now it's better to have a recent generic kernel rather
than have a fucked up custom kernel.
Also, this removes all that cruft for the Intel HDA pinning on dnyarri,
because the machine now has two X-Fi sound cards.
Both machines probably won't boot now, so we'll have to adjust a few
things very soon.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
I no longer use VirtualBox on any of my machines anymore, so let's
remove it for good :-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
Actually this is the *only* machine where I actually use VirtualBox, on
every other machine I'm fine with qemu/KVM.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
It has been renamed since months (NixOS/nixpkgs@14321ae) and
users.extra* are now just aliases to users.users and users.groups.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
I'm going to remove legacy fbdev support from the kernel configurations,
so in order to still have terminals besides the X server we need to
enable this (also, kmscon allows more eyecandy if we want that).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|