The example pertinent to `fccUnlockScripts` contains wrong (maybe old) key names possibly leading to trial/error while configuring the option. This issue can be avoided updating the example.
Reimplement the `ModulePath` generation logic by only adding the
`/lib/xorg/modules` subpath for each module, in the specified order.
In particular, hardware-specific drivers are listed *before*
`xorgserver`, which fixes https://github.com/NixOS/nixpkgs/issues/299684.
This also keeps the list reproducible, as wanted by https://github.com/NixOS/nixpkgs/pull/230186.
I have confirmed that X is able to find `.so` files recursively within
the `ModulePath`, so that there is no need to include subdirectories of
`/lib/xorg/modules`. Furthermore, I don't expect there to be a need to
include directories *outside* of `/lib/xorg/modules`, as the default
`ModulePath` on standard distributions is `/usr/lib/xorg/modules`.
(see https://www.x.org/releases/current/doc/man/man5/xorg.conf.5.xhtml#heading4)
Upstream updates roon-server frequently, and client apps (iOS, Android,
etc) will stop working with older versions of the roon-server.
We can't always keep the roon-server up to date as fast as upstream
releases, so it is often necessary for users to use an overlay or
provide their own version.
In particular the use case of running NixOS stable channel, but wanting
to use the `pkgs.roon-server` from unstable is one that I want to
support with this simple change.
PR #256638 inadvertently introduced a bug in `nixos-generate-config` whereby it
would never put `bcache` into the `availableKernelModules` for the initrd.
This is because the `qr` operator in Perl returns a regex object, rather than
matching it; the regex object evaluates to true, making the filter expression
effectively `grep(!true, @bcacheDevices)`, which will always return an empty
list.
- Build virtualbox guest additions from source and fix paths
- Install VBoxDRMClient to support resizing
- Support resizing on wayland and x11
- Adding multiple new options
- clipboard
- seamless
- Removing x11 option
- Support linux 6.8
services.nfs.settings is added for options that go into /etc/nfs.conf.
There are services.nfs.server.extraNfsdConfig and
services.nfs.extraConfig, but they have drawbacks. They overlap in
scope (nfs.extraConfig can also add nfsd options). They require that one
writes INI syntax. They often produce nfs.conf files with duplicate
section names, which is confusing.
This deprecates services.nfs.server.extraNfsdConfig and
services.nfs.extraConfig.
services.nfs.settings cannot be used together with
services.nfs.server.extraNfsdConfig or services.nfs.extraConfig.
- Slight rewordings and typo fixes.
- Use documentation prefixes for addresses, rather than 1.2.3.4, and
add IPv6 examples.
- Fix description for `keyFile` (`/var/lib/mycelium/key{,.bin}`).
- Some formatting by my editor
This is shamelessly stolen from Photoprism's module, and should allow
executing the manage script without resorting to various tricks due to
relying on transient users.
The postgresql runs on a different node than my mastodon itself. Sometimes when
rebooting the entire host it can happen that mastodon gets started
before the DB[1] is up. In that case `mastodon-init-db.service` ran
through with the following log output:
2024-03-07 15:30:56.856
Migrating database (this might be a noop)
2024-03-07 15:30:56.856
/nix/store/xzm7www0qb7jg5zrgg7knynckx5yhki9-unit-script-mastodon-init-db-start/bin/mastodon-init-db-start: line 9: [: -eq: unary operator expected
It seems wrong to me to have this unit pass if the DB isn't even up,
especially with such an error.
This patch now checks if the exit code of the psql check was non-zero
and fails the entire unit. A retry can be implemented e.g. with
Restart/RestartSec then (which is more elegant than adding a while/sleep
loop anyways) like this:
systemd.services.mastodon-init-db = {
serviceConfig = {
Restart = "on-failure";
RestartSec = "5s";
RestartMode = "direct";
RemainAfterExit = true;
};
unitConfig = {
StartLimitBurst = 5;
StartLimitIntervalSec = "60";
};
};
Also using `-t --csv` now to not render the column name and to not
render a table so we don't need to rely on the format of psql (and parse
it with `sed(1)`).
[1] I added a script that blocks until postgres is there in the meantime
though.
Previously, pdftk (part of the ticket, badge, ... generation pipeline)
would fail with:
```
Error occurred during initialization of VM
Failed to mark memory page as executable - check if grsecurity/PaX is enabled
```
Thise caused pdf generation to fail.
Since pdftk is a java application and, according to systemd.exec(5),
> Note that [MemoryDenyWriteExecute=] is incompatible with programs and
> libraries that generate program code dynamically at runtime, including
> JIT execution engines, executable stacks, and code "trampoline" featu
> re of various C compilers.
Disabling `MemoryDenyWriteExecute=` fixes it.
As a follow-up to https://github.com/NixOS/nixpkgs/pull/294096 this
should further improve the flexibility around building OS images with
systemd-repart:
* Previously the attribute set `compression` needed to be fully
populated, including `algorithm` and `level` because
`compression.enable` was evaluated by bash, after being interpolated
as strings into the `buildCommand`. Now it's sufficient to pass
`compression.enable = false` to the builder, e.g. in `overrideAttrs`,
to disable the compression.
* Using mkDerivation allows for much more customization than the
previously used `runCommand`, making use of phases and pre/post hooks.
This is especially helpful for building multiple images from the same
system configuration, e.g. to build an image `Y` based on a partially
built raw image `X`, by injecting a UKI that depends on `X` into a
defered ESP.
* Before this change it was non-trivial to conduct further manipulations
on the amended repart definitions. Now, the definitions that
systemd-repart uses to build the image can be easily manipulated in
`postPatch` or `preBuild`.
Aside from this, the build is now executed in the build directory, rather
than `$out`. This allows references to relative paths in the build
environment to be used, especially for `--definitions`, which previously
required an absolute path.
The available policies for `InsertedDevicePolicy` and
`ImplicitPolicyTarget` differ from the defined policy enum. This change
is to prevent users from configuring incorrect policies for `usbguard`
Related `usbguard` documentation
https://usbguard.github.io/documentation/configuration.html
Signed-off-by: Ameya Shenoy <shenoy.ameya@gmail.com>
The NVIDIA X driver uses a UNIX domain socket to pass information to
other driver components. If unable to connect to this socket, some
driver features, such as G-Sync, may not work correctly. The socket will
be bound to a file with a name unique to the X server instance created
in the directory specified by this option. Note that on Linux, an
additional abstract socket (not associated with a file) will also be
created, with this pathname socket serving as a fallback if connecting
to the abstract socket fails.
The default, which was in effect prior to this change, was `/var/run`.
The effect of not setting this option was that GDM X sessions
(and other non-root sessions) would see this warning in the log files:
```
(WW) NVIDIA: Failed to bind sideband socket to
(WW) NVIDIA: '/var/run/nvidia-xdriver-b4f69129' Permission denied
```
I don't see any security implications of turning this on universally,
since there already was an abstract socket created according to the
docs.
Documentation:
1. [NVIDIA X Config Options](https://download.nvidia.com/XFree86/Linux-x86_64/440.82/README/xconfigoptions.html#SidebandSocketPath)
Diagnosis:
1. [Arch Linux BBS post](https://bbs.archlinux.org/viewtopic.php?pid=1909115#p1909115)
This option makes it easier to reuse a system's ukify.conf without the
need for manually calling the generator on `settings` again to receive a
rendered configuration file.
Theoretically, a complete configuration file could now be provided by
users.
