This will greatly reduce the number of cases where the global unicast
scope overlaps with link scopes configured as default-route, making it
feasible to use the global DNS setting in conjunction with per-link dns
servers configured by the network.
This change is preferred over demoting links to default-route=no where
the user prefers to use the network provided DNS servers, and I expect
it is non-disruptive in that it should not degrade the efficacy of any
existing configuration.
Note, `systemd-analyze foo@.service --instance=hoge` is equivalent to
`systemd-analyze foo@hoge.service`. But, the option may be useful when
e.g. passing multiple template units that have restriction on their
instance name:
```
$ ls
template_aaa@.service template_bbb@.service template_ccc@.service
$ systemd-analyze ./template_* --instance=hoge
```
Without the option, we need to embed an instance name into each unit
name, so cannot use globs.
Prompted by #33681.
After 3976c43092 (#31423), IPMasquerade=
implies only per-interface IP forwarding. That means, nspawn users need
to manually enable IPv4/IPv6Forwarding= in networkd.conf when
--network-veth or friend is used. Even the change was announced in NEWS,
the change itself breaks backward compatibility and extremely reduces
usability.
Let's make the setting imply the global setting again.
Fixes#34010.
The net_id builtin only checked the of_node of a netdev's parent device,
not that of the netdev itself. While it is common that netdevs don't have
an OF node assigned themselves, as they are derived from some parent
device, this is not always the case. In particular when a single
controller provides multiple ports that can be referenced indiviually in
the Device Tree (both for aliases/MAC address assignment and phandle
references), the correct of_node will be that of the netdev itself, not
that of the parent, so it needs to be checked, too.
A new naming scheme flag NAMING_DEVICETREE_PORT_ALIASES is added to
allow selecting the new behavior.
This allows for example forcing to use /sbin/init instead of always
using /usr/lib/systemd/systemd if it exists. Or it allows using a
different path altogether.
The PrepareForShutdownWithMetadata signal was added via
e4aab5cf1a but a corresponding property
was not. A property has to be a single type, so the bool needs to be
one of the key/value pairs as 'ba{sv}' is not a valid property.
+ Scale the x-axis of the resulting plot by a factor (default 1.0)
+ Add activation timestamps to each bar
Signed-off-by: rajmohan r <rajmohan.r@kpit.com>
This fixes
commit 9b0688f491
Author: Yu Watanabe <watanabe.yu+github@gmail.com>
Date: Tue Jan 9 10:52:49 2024 +0900
virt: add Google Compute Engine support
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Arch and Tumbleweed do not do EOLs but are still stable, so clarify the paragraph.
Also break the entry in paragraphs, to make it more readable when rendered.
The point was made on https://lists.debian.org/debian-ctte/2024/08/msg00005.html
that 'pre-release sounds' like an RC candidate, ie, something that will change
very slightly in the released version. But this is not necessarily the case
for example at the beginnig of a Fedora Rawhide or Debian Testing release cycle,
so change it to a more generic 'development'
Follow-up for 7102dc52e6
This is for experimental builds of the OS made to test some specific WIP
feature.
For example, let's say the distro in question is Asahi Linux and Apple
just released the M3 SoC. The Asahi developers will start porting to the
M3, and will quickly generate builds of Asahi Linux that can technically
boot but aren't ready for any kind of daily use. These images are marked
as experimental, and can be shared among the developers. If a user
somehow stumbles upon one of these images and tries to install it,
they'll be warned that they're about to install an experimental Apple M3
port of Asahi Linux. Eventually, once the Asahi developers think that
their M3 port is ready for a wider audience, they can merge it into the
mainline Asahi repos, where it will be distributed through the usual
nightly CI builds (where RELEASE_TYPE=pre-release; M3 support is no
longer experimental).
This will allow GUIs to customize their behavior a little based on the
type of release.
For example, an OS installer may display a warning/disclaimer if
RELEASE_TYPE=prerelease. The software updates app might be a bit more
insistent about upgrading to the next major release if
RELEASE_TYPE=stable than if RELEASE_TYPE=lts
The --list-invocations command is similar to --list-boots, but shows
invocation IDs of specified unit. This should be useful when showing
a specific invocation of a unit.
The --invocation option is similar to --boot, but takes a invocation ID
or an offset. The -I option is equivalent to --invocation=0.
This allows for "per-instance" credentials for units. The use case
is best explained with an example. Currently all our getty units
have the following stanzas in their unit file:
"""
ImportCredential=agetty.*
ImportCredential=login.*
"""
This means that setting agetty.autologin=root as a system credential
will make every instance of our all our getty units autologin as the
root user. This prevents us from doing autologin on /dev/hvc0 while
still requiring manual login on all other ttys.
To solve the issue, we introduce support for renaming credentials with
ImportCredential=. This will allow us to add the following to e.g.
serial-getty@.service:
"""
ImportCredential=tty.serial.%I.agetty.*:agetty.
ImportCredential=tty.serial.%I.login.*:login.
"""
which for serial-getty@hvc0.service will make the service manager read
all credentials of the form "tty.serial.hvc0.agetty.xxx" and pass them
to the service in the form "agetty.xxx" (same goes for login). We can
apply the same to each of the getty units to allow setting agetty and
login credentials for individual ttys instead of globally.
- Improve wording for explanation when these variables are inherited
- Clarify that these variables are not placed in the process environment block,
so /proc/PID/environ cannot be used as a debugging tool
Currently inhibitors are bypassed unless an explicit request is made to
check for them, or even in that case when the requestor is root or the
same uid as the holder of the lock.
But in many cases this makes it impractical to rely on inhibitor locks.
For example, in Debian there are several convoluted and archaic
workarounds that divert systemctl/reboot to some hacky custom scripts
to try and enforce blocking accidental reboots, when it's not expected
that the requestor will remember to specify the command line option
to enable checking for active inhibitor locks.
Also in many cases one wants to ensure that locks taken by a user are
respected by actions initiated by that same user.
Change logind so that inhibitors checks are not skipped in these
cases, and systemctl so that locks are checked in order to show a
friendly error message rather than "permission denied".
Add new block-weak and delay-weak modes that keep the previous
behaviour unchanged.
