Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

staging: 2024-11-26 #23

Merged
merged 10 commits into from
Nov 26, 2024
Merged

staging: 2024-11-26 #23

merged 10 commits into from
Nov 26, 2024

Conversation

Frontear
Copy link
Owner

@Frontear Frontear commented Nov 26, 2024

Things Done

  1. (165479a) Update our /etc/nix/nix.conf to have a significantly smaller timeout, less download attempts, and disable preallocating contents.
  2. (c04ce7b) Rename our final ISO file to disambiguate it from an official NixOS ISO.
  3. (18bdb0b) Separate hardware and non-hardware related configurations for the laptop.
  4. (1766c0a) Do not cache flake inputs in cachix.
  5. (4eb1fe0) Remove poor chattr recommendations from the laptop.
  6. (bc30f27) Update nixpkgs revision and fix an issue in regards to /etc/machine-id persistence requirements.
  7. (765c6f2) Patch nix-index to strip FHS derivations from the search.
  8. (777b2f3) Enable the pipe operators experimental feature.
  9. (a46dc2e) Add NetworkManager's OpenVPN plugin.
  10. (df7b1eb) Improve GitHub Actions CI speed by parallelizing the builds.

Reduce `connect-timeout`, `download-attempts`, and disable `preallocate-contents`. At first these may all seem like bad choices, but they have their uses. Currently, `connect-timeout` can cause Nix to hang when it fails to connect since it waits for the timeout to be reached. This isn't for just one or two things, this is for _all_ network IO that occurs from Nix, which can block on a lot of unnecessary things, such as trying to update the local narinfo db when it doesn't do anything for our invocation. `download-attempts` follows in tandem to this issue, by causing further blocks on unnecessary tasks, and as a result we want to be slightly less forgiving under low network situations.

Disabling `preallocate-contents` is actually very important because it breaks BTRFS COW functionality and compression. Furthermore, the feature itself isn't actually that important on a modern system, so doing it ahead-of-time isn't bringing any major benefits. The negatives here outweigh the non-existent positives, so it has been removed.
This disambiguates the ISO by changing the actual filename, allowing me to immediately see which one is mine, assuming if I will even carry stock NixOS ISOs anymore...
All of them, or at least the ones I could see have been moved into `hardware/`. With it I've also added some detailed comments and links to the Arch Wiki which explain these choices further.
Since Nix 2.25, flake inputs cannot be substituted. This means that this caching task is defunct and should not be kept. It's not really going to save much space, but its the principal.
Preventing copy-on-write was a very bad idea. Originally my logic was that because I do not strictly care about the store surviving, since I can fully regenerate it through my configuration; it does not matter. Furthermore, COW is useless in the store since files are only ever created or deleted, it actually performs no tangible actions since there is never a "write" that happens on an existing path for a "copy" to occur. Unfortunately, I did not realize that disabling COW also disables compression, that means that my system has absolutely no compression on the store despite using `zstd:15`.. Next time I suppose.

Preventing compression on persist is up for debate though. I've removed it now because I don't have any strong evidence for or against it, especially since I haven't experienced the IO of compression from this installation given my mishap mentioned above. It may be worth doing but it may be too IO intensive, I'd need to perform real-world testing, which I haven't done. As a result, this recommendation may be back but it might not, it depends on what I discover in the future.
…early

In the newest release of systemd (or the _newer_ release compared to the previous nixpkgs revision), a new `systemd-machine-id-commit.service` was introduced to help ensure `/etc/machine-id` was correctly saved from a transient fs like `tmpfs` to a real persistent device. This is for fairly obvious reasons, systemd relies on the machine-id to store logs and other system stateful information, and losing it each time defuncts those data.

Unfortunately, whilst well intentioned this service does nothing for my use-case because we already handle this ourselves (ignoring the `nixos-install` issue which has yet to be fixed). As a result, we can simply disable this service since there is enough assurance it won't be needed. Checking `systemctl --failed` shows no other services failing due to this change, which gives me the confidence in knowing this service is non-essential to anything else, and can be safely disabled.
This is part of a PR over at nix-community/nix-index#243 which makes `--top-level` a default argument. This in turn removes FHS entries by default from being matched when using `nix-locate`. This was always a pain point for me so I am glad someone knew how to fix it. Unfortunately since that PR seems a bit stalled I've in turn needed to patch directly. I've poked upstream to help move that PR along, and once it does merge I'll drop this patch.
`nixd` has support for them and they are honestly really nice to use. `lib.pipe` served us well but having the pipe-operator as is is super nice
@Frontear Frontear force-pushed the staging branch 19 times, most recently from ec3d999 to 15496fb Compare November 26, 2024 21:51
In order to speed up the CI pipeline, we are parallelizing the builds. This does unfortunately re-perform a lot of the tasks, specifically the disk space free, which is arguably the second most lengthy step after the build itself. I cannot find out how to avoid this so at the moment this will be the best change we can do. If there are ways to "snapshot" an action's state and allow parallelization from that snapshot forwards, that could be cool. I know a VM/Container could do this, but I've no idea how to do that using GitHub Actions yaml logic.
@Frontear Frontear merged commit df7b1eb into main Nov 26, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant