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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2006761:
> systemd-resolved always (reverse)-resolves the host's IP addresses and FQDN.
> This can be harmful when an application (for instance, a DNS zone manager) is
> installed on the same server instance. That application would expect
> NXDOMAIN to be returned if the current server's IP does not belong in an
> already managed reverse zone.
This allows clients of nss-resolve to use the same config options that are
available through the dbus api and as command-line options to resolvectl.
The man page text is is mostly copied directly from
c6f20515ab.
Migrate logind to use the new macros to declare a D-Bus method or signal.
Replaced SD_BUS_METHOD_WITH_NAMES with SD_BUS_METHOD_WITH_ARGS.
Replaced SD_BUS_SIGNAL_WITH_NAMES with SD_BUS_SIGNAL_WITH_ARGS.
When conditions fail on a service unit, a path unit can cause
PID 1 to busy loop as it keeps trying to activate the service unit.
To avoid this from happening, add a trigger limit to the path unit,
identical to the trigger limit we have for socket units.
Initially, let's start with a high limit and not make it configurable.
If needed, we can add properties to configure the rate limit similar
to the ones we have for socket units.
Spotted whilst debugging:
```
[763/2094] Generating man/machine-info.html with a custom command
Element cite in namespace '' encountered in para, but no template matches.
[765/2094] Generating man/machine-info.5 with a custom command
Element cite in namespace '' encountered in para, but no template matches.
```
Follow-up to 357376d0bb.
I think this makes it much easier to figure out what information sources
were used to generate the names, and why certain names were not generated.
On my laptop:
Using default interface naming scheme 'v250'.
ID_NET_NAMING_SCHEME=v250
wwp0s20f0u2i12: addr_assign_type=3, MAC address is not permanent.
wwp0s20f0u2i12: Parsing slot information from sysname "0000:00:14.0": success
wwp0s20f0u2i12: dev_port=0
wwp0s20f0u2i12: PCI path identifier: domain=0 bus=0 slot=20 func=0 phys_port= dev_port=0 → p0s20f0
wwp0s20f0u2i12: USB name identifier: ports=2 config=1 interface=12 → u2i12
ID_NET_NAME_PATH=wwp0s20f0u2i12
Using default interface naming scheme 'v250'.
ID_NET_NAMING_SCHEME=v250
ID_NET_NAME_MAC=en54ee75cb1dc0
enp0s31f6: MAC address identifier: hw_addr=54:ee:75:cb:1d:c0 → 54ee75cb1dc0
ID_OUI_FROM_DATABASE=Wistron InfoComm(Kunshan)Co.,Ltd.
enp0s31f6: Parsing slot information from sysname "0000:00:1f.6": success
enp0s31f6: dev_port=0
enp0s31f6: PCI path identifier: domain=0 bus=0 slot=31 func=6 phys_port= dev_port=0 → p0s31f6
ID_NET_NAME_PATH=enp0s31f6
Using default interface naming scheme 'v250'.
ID_NET_NAMING_SCHEME=v250
ID_NET_NAME_MAC=en0050b6856d36
hub0: MAC address identifier: hw_addr=00:50:b6:85:6d:36 → 0050b6856d36
ID_OUI_FROM_DATABASE=GOOD WAY IND. CO., LTD.
hub0: Parsing slot information from sysname "0000:00:14.0": success
hub0: dev_port=0
hub0: PCI path identifier: domain=0 bus=0 slot=20 func=0 phys_port= dev_port=0 → p0s20f0
hub0: USB name identifier: ports=4.1.3 config=2 interface=0 → u4u1u3c2
ID_NET_NAME_PATH=enp0s20f0u4u1u3c2
Using default interface naming scheme 'v250'.
ID_NET_NAMING_SCHEME=v250
wlp4s0: addr_assign_type=3, MAC address is not permanent.
wlp4s0: Parsing slot information from sysname "0000:04:00.0": success
wlp4s0: dev_port=0
wlp4s0: PCI path identifier: domain=0 bus=4 slot=0 func=0 phys_port= dev_port=0 → p4s0
ID_NET_NAME_PATH=wlp4s0
Now that kernel-install creates the machine-id directory, we don't need to do
this is 'bootctl install', and in fact it's better not to do this since it
might never be necessary. So let's change the default behaviour to 'no'.
I kept support for 'auto' to maintain backwards compatibility, even though the
default was changed. Previous behaviour can be requested by specifying
--make-machine-id-directory=auto.
This is a natural extension of d6bce6e224: if we are installing sd-boot, we
want to use the sd-boot layout, so let's write the appropriate
KERNEL_INSTALL_LAYOUT setting. Effectively, if we do 'booctl install',
kernel-install will not autodetect the layout anymore.
And 357376d0bb added support for KERNEL_INSTALL_MACHINE_ID. We need to support
it here too. We both read it, so that we create the right directories, and also
write it if it wasn't written yet and we created some directories using it, so
that kernel-install that is executed later knows the machine-id that matches
the directories we crated.
The code is changed in some places to fail if we can't figure out the current
status. When installing the boot loader it's probably better not to guess.
On some runs `sleep infinity` run by the user manager uses over 3M of
memory, which is higher than the MemoryHigh= set on testbloat and
testmunch. If no pgscan is generated, then systemd-oomd sorts by memory
usage which leads to a situation where testchill (using 3M) could be
targeted over testbloat (1M-2M).
Fix this by setting reasonable MemoryHigh= values for all of these test
units. Even if somehow testchill throttles a bit at 3M, testbloat and
testmunch should still be trying to use over 100M at memory and will
throttle down to 5M and 6M with the new values. This should reflect
the desired state in pgscan and memory usage during the test run.
Fixes#21684
341890de86 made "bootctl install" create
ESP\MID, in preparation of cf73f65089 that
followed it and created 00-entry-directory.install to make ESP\MID\KVER
if ESP\MID existed ‒ this meant that "bootctl install" followed by
"kernel-install $(uname -r) /boot/vml*$(uname -r) /boot/ini*$(uname -r)"
actually installed the kernel correctly.
Later, 31e57550b5 reverted the first
commit, meaning, that now running those two commands first installs
sd-boot, but then does nothing. Everything appears to work right,
nothing errors out, but no changes are actually done. To the untrained
eye (all of them), even running with -v appears to work:
all the hooks are run, as is depmod, but, again, nothing happens.
This is horrible. Nothing in either manpage suggests what to do
(nor should it, really), but the user is left with a bootloader that
appears fully funxional, since nothing suggests a failure in the output,
but with an unbootable machine, /no way to boot it/, even if they drop
to an EFI shell, since the boot bundle isn't present on the ESP,
and no real recourse even if they boot into a recovery system,
apart from installing like GRUB or whatever.
00- is purely instrumentation for 90-,
and separating one from the other has led to downstream dissatisfaxion
(indeed, the last mentioned commit cited cited exactly that as the
reversion reason), while creating $ENTRY_DIR_ABS is only required
for bootloaders using the BLS, and shouldn't itself toggle anything.
To that end, introduce an /{e,l}/k/install.conf file that allows
overriding the detected layout, and detect it as "bls" if
$BOOT_ROOT/$MACHINE_ID ($ENTRY_DIR_ABS/..) exists, otherwise "other" ‒
if a user wishes to select a different bootloader,
like GRUB, they (or, indeed, the postinst script) can specify
layout=grub. This disables 90- and $ENTRY_DIR_ABS manipulation.
