IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Also fix indentation.
(cherry picked from commit 2fa6574e835566c2aa5cbf4167ecee316f71bf98)
(cherry picked from commit dbed9051f701bfb1f0df1e19f01538348280d498)
Instead of succeeding when either the firmware reports a TPM device
or we find a TPM device, let's check that the firmware reports a TPM
device and the TPM subsystem is enabled in the kernel.
To check whether the subsystem enabled, we check if the relevant
subdirectory in /sys exists at all.
(cherry picked from commit 300bba79c22e4be1effe2faad0e59ac725d396a1)
(cherry picked from commit 1757446e8bc4dc076badd5c1ad53a0021c42638c)
When reboot is invoked, the -p/--poweroff option is intentionally
ignored. Update the man page to reflect this exception.
(cherry picked from commit 6dfaeac3704c68a1e297cef0c08e5b6ee1dbf3b7)
Let's document that "." is a bad choice of character when naming
interfaces. Let's also document the hard restrictions we make when
naming interfaces.
Result of the mess that is #25052.
(cherry picked from commit 8f598a463571608cbeb1b562afcadf2db335a530)
Before Debian switched to systemd, `shutdown now` would reset the system into
single user mode, doing roughly the equivalent of `telinit 1`.
Now, systemd's `shutdown` command does not behave that way; it defaults to
`poweroff` which might be confusing for users (like me) used to the previous
method.
Because I don't use the command often, I keep being stumped by this behavior,
and every time I look at the `shutdown(1)` manpage, I don't understand why I
can't find what I am looking for. This patch should make sure that people like
me find their way back to some sort of reason.
Maybe the *proper* way to fix this would be to restore the more classic
behavior, but I'm definitely not going to climb that hill. Besides, I clearly
remember the time I found out about the `shutdown` command and was *really*
confused when it brought me back to a command-line prompt. That was really
counter-intuitive and I find that change to actually be a good thing. So I'm
not proposing to change this behavior, merely document it better.
I originally added this to the `-P` option but it was suggested adding a new
`COMPATIBILITY` section instead, where other such issues could be added.
The `COMPATIBILITY` section is not actually officially documented. `man(1)`
talks about a `CONFORMING TO` section, but `shutdown(1)` is not
POSIX (`shutdown(2)` is, of course), so there's no actual standard on how this
should work.
The other option I considered was to add a `BUGS` section, but that seemed to
inflammatory, and definitely counter-productive.
(cherry picked from commit 9aafd310cc42716a923e0d40e56db7952e16a9a3)
A NetDev is needed to create the bridge in order to match the example's description "This creates a bridge..."
(cherry picked from commit bc33789a06e5a727fa4662b0dfcbe02ef7e46687)
The ":=" operator was only added in Python 3.8 so splitting the line with it into two makes check-os-release.py actually fulfill its claim of working with any python version.
(cherry picked from commit ce0a056abc41168e1b45537505ca9f65bf6f5c30)
And point people to "journalctl --unit=" for information of prior runs.
Inspired by: #24159
(cherry picked from commit 157cb4337b83359267050bff43c1ad39b0303f10)
While Type=file works because it seems to be the default, the line gets
ignored as printed on the stderr output.
Use the correct value "regular-file" for the target type.
(cherry picked from commit 0ad7b7b8092e85f85be155dc3264b9f7607e9d24)
It is not clear what "unprivileged user namespaces are available" means.
It could mean either that they are only usable, that is, enabled in the kernel,
or they have been enabled for the specific service. Referring to the
`PrivateUsers=` options makes it clear that the latter is meant.
(cherry picked from commit 34aee208b5d745fd6c90c09e3e6e91f2c2949514)
Whitespace inside of the <varname> field was propagated to the displayed form,
causing strange indentation.
(cherry picked from commit 9cfc294fe0e2637d96f8e5c29143c10e2173daa3)
Also change the title to describe the module more comprehensively.
Follow-up for 90bc309aa2c1430941f4c50f73e681ab3e488bd3. Suggested
in https://bugzilla.redhat.com/show_bug.cgi?id=2085485#c5.
(cherry picked from commit 9e6df034128936895df2d6348eefce61317ebcc2)
We have vendor presets, and local admin presets, and runtime presets
(under /usr/lib, /usr/local/lib and /etc, /run, respectively). When we
display preset state, it can be configured in any of those places, so
we shouldn't say anything about the origin.
(Another nice advantage is that it improves alignment:
[root@f36 ~]# systemctl list-unit-files multipathd.service
UNIT FILE STATE VENDOR PRESET
multipathd.service enabled enabled
^ this looks we have a "PRESET" column that is empty.)
(cherry picked from commit c1e0dc9c882dfae7ba4bf49c50fd253ea199e7d9)
it's enabled units, and they might be started by various forms of
activation, not just "at boot".
Fix that.
(cherry picked from commit 0c772b1cc1f08bee260addbecb8adc6cdf4ddeef)
Fixes#22966. Since there are competing conventions, let's not
change our code, but make the docs match what is implemented.
(cherry picked from commit b72308d34440530df3bb8b6b3d272dfc303d1d37)
The methods published by the example have a reply in the signature, but
the code was not sending any, so the client gets stuck waiting for a
response that doesn't arrive. Echo back the input string.
Update the object path to follow what would be the canonical format.
Request a service name on the bus, so that the code can be dropped in a
service and it can be dbus-activatable. It also makes it easier to see
on busctl list.
In the documentation, using the term "managed" for both the RA flag and
the DHCPv6 mode is confusing because the mode is referred to as
"solicit" both in the official DHCPv6 documentation (see RFC 8415) and
in the WithoutRA option.
Furthermore, calling the other RA flag "other information" or "other
address configuration" is confusing because its official name is simply
"other configuration" (see RFC 4861 and RFC 5175) and it isn't used to
assign IP addresses.
Rewrite the documentation for DHCPv6Client and WithoutRA to make it
clear that getting the "managed" RA flag triggers the same kind of DHCP
request as WithoutRA=solicit, whereas getting the "other configuration"
RA flag triggers the same kind of DHCP request as
WithoutRA=information-request.
