99e015e2 missed to update the example
below - DHCPv6.AssignAcquiredDelegatedPrefixAddress was moved to
DHCPv6PrefixDelegation.Assign.

As it already defaulted to true since it's introduction in
9efa8a3c, there's no need to explicitly
list it at all.

Apparently, if IO is still in flight at the moment we invoke LOOP_CLR_FD
it is likely simply dropped (probably because yanking physical storage,
such as a USB stick would drop it too). Let's protect ourselves against
that and always sync explicitly before we invoke it.

Make timesyncd retry interval grow more slowly

Fixed below systemd codesonar warning.
isprint() is invoked here with an argument of signed
type char, but only has defined behavior for int arguments that are
either representable as unsigned char or equal to the value
of macro EOF(-1).

As per codesonar report, in a number of libc implementations, isprint()
function implemented using lookup tables (arrays): passing in a
negative value can result in a read underrun.

The explicit limit is dropped, which means that we return to the kernel default
of 50% of RAM. See 362a55fc for a discussion why that is not as much as it
seems. It turns out various applications need more space in /dev/shm and we
would break them by imposing a low limit.

While at it, rename the define and use a single macro for various tmpfs mounts.
We don't really care what the purpose of the given tmpfs is, so it seems
reasonable to use a single macro.

This effectively reverts part of 7d85383e. Fixes #16617.

Like HP ZBooks, all EliteBooks use the same micmute scancode.

The new retry intervals are [15, 20, 26, 34, 45, 60, 80, 106, 141, 188, 250,
333, 360, ...]. This should allow graceful response if a transient network
failure is encountered. Growth is exponential, but with a small power and
capped to a non-too-large value so that we resynchronize within a few minutes
after network is restored. I made the minimum 15 s to make sure that we never
send packets more often than that.

Fixes #16492.

Follow-up for 6e537f62.

Follow-up for https://github.com/systemd/systemd/commit/99e015e28c8322bf714f45cd1defcf20ac2103c5

Follow-up for 99e015e2.

network: fix several DHCP6 PD issues, and cleanup DHCP4 and NDISC

Small adjustements to let various tests pass in overloaded Fedora infra and related changes

Increase /tmp size to 50% of RAM

Signed-off-by: Gaurav Singh <gaurav1086@gmail.com>

In https://bugzilla.redhat.com/show_bug.cgi?id=1858219 a user
reported that hibernation is not supported. This is probably caused
by secure boot, but our current logging does not make this
obvious.

This should be enough to fix https://bugzilla.redhat.com/show_bug.cgi?id=1856514.
But the limit should be significantly higher than 10% anyway. By setting a
limit on /tmp at 10% we'll break many reasonable use cases, even though the
machine would deal fine with a much larger fraction devoted to /tmp.
(In the first version of this patch I made it 25% with the comment that
"Even 25% might be too low.". The kernel default is 50%, and we have been using
that seemingly without trouble since https://fedoraproject.org/wiki/Features/tmp-on-tmpfs.
So let's just make it 50% again.)

See 7d85383e.

(Another consideration is that we learned from from the whole initiative with
zram in Fedora that a reasonable size for zram is 0.5-1.5 of RAM, and that pretty
much all systems benefit from having zram or zswap enabled. Thus it is reasonable
to assume that it'll become widely used. Taking the usual compression effectiveness
of 0.2 into account, machines have effective memory available of between
1.0 - 0.2*0.5 + 0.5 = 1.4 (for zram sized to 0.5 of RAM) and
1.0 - 0.2*1.5 + 1.5 = 2.2 (for zram 1.5 sized to 1.5 of RAM) times RAM size.
This means that the 10% was really like 7-4% of effective memory.)

A comment is added to mount-util.h to clarify that tmp.mount is separate.

Closes #16602.

This should not change any behavior.

As the link may be reconfigured later. If we do not update the address
information, then its setup state or operstate may not be updated
correctly.

link_request_set_routes() is also called when a dynamic address is
configured. At that time, static addresses may not be configured yet.

Fixes #16546.

Previously, we did not drop addresses and delegated prefixes when
DHCP6 client is stopped.

Fixes #15455.
Fixes #13564.

Otherwise, the old addresses will exist in deperecated state.

Previously, on DHCPv4 address renewal, the old address may be removed
while the new address is not ready yet.

This also simplifies the logic of removing address and routes.

Just for safety.