A couple notes:
---------------
Adding invalid `console=` parameters is not an issue. Any invalid
console is unused. The kernel will use the "rightmost" (last) valid
`console=` parameter as the default output. Thus the SBBR-mandated AMA0
on A1, and ttyS0 on x86_64 as documented by Oracle.
`nvme_core.shutdown_timeout=10` was added as it was written this way in
the A1 images. Unclear whether `nvme.shutdown_timeout=10` is wrong. At
worst this is a no-op.
While working on #192270, I noticed that only some wait_for_* helper
functions make the timeout configurable. I think we should be able to
customize it in all cases
While reviewing other changes related to synapse I rediscovered the
`lib.findFirst (...) (lib.last resources)` hack to find a listener
supporting the `client` resource. We decided to keep it that way for now
a while ago to avoid scope-creep on the RFC42 refactoring[1]. I wanted
to take care of that and forgot about it.
Anyways, I'm pretty sure that this is bogus: to register a user, you
need the `client` API and not a random listener which happens to be the
last one in the list. Also, you need something which serves the `client`
API to have the entire synapse<->messenger interaction working (whereas
`federation` is for synapse<->synapse).
So I decided to error out if no `client` listener is found. A listener
serving `client` can be defined in either the main synapse process or
one of its workers via `services.matrix-synapse.workers`[2].
However it's generally nicer to use assertions for that because then
it's possible to display multiple configuration errors at once and one
doesn't have to chase one `throw` after another. I decided to also error
out when using the result from `findFirst` though because module
assertions aren't thrown necessarily when you evaluate a single config
attribute, e.g. `config.environment.systemPackages` which depends on an
existing client listener because of `registerNewMatrixUser`[3].
While at it I realized that if `settings.instance_map` is wrongly
configured, e.g. by
settings.instance_map = mkForce {
/* no `main` in here */
}
an `attribute ... missing` error will be thrown while evaluating the
worker assertion.
[1] https://github.com/NixOS/nixpkgs/pull/158605#discussion_r815500487
[2] This also means that `registerNewMatrixUser` will still work if you
offload the entire `client` traffic to a worker.
[3] And getting a useful error message is way better for debugging in such a
case than `value is null while a set was expected`.
follow-up on 28b3156bc6 which broke
when tokenFile was left empty.
Making both options nullable also allows us to provide a more meaningful
error message when neither authentication method is configured.
Fixes#228141, which describes an issue where detaching Yubikey during the boot process
causes cryptsetup to write empty passphrase instead of the challenge-response salt stored
on the boot drive.
Duplicated sudo's testsuite for now, as its maintainer does not with
to collaborate on testing effors; see #253876.
Environment-related tests were removed, as sudo-rs does not support
`(NO)SETENV` yet; see memorysafety/sudo-rs#760
This is preferable even for regular `sudo`, but will ensure the check is useful
when using `sudo-rs` in the future.
Also, dropped antediluvian comment about the syntax check being disabled,
when it was clearly not commented out:
- introduced in 2007, commit 6d65f0ae03ae14f3e978d89959253d9a8f5e0ec1;
- reverted in 2014, commit e68a5b265a,
but without ammending the comments.