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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We expose various other forms of UUID helpers already, i.e.
SD_ID128_UUID_FORMAT_STR and SD_ID128_MAKE_UUID_STR(), and we parse
UUIDs, hence add a high-level helper for formatting UUIDs too.
This doesn't add any new code, it just moves some helpers
id128-util.[ch] → sd-id128.[ch], to make them public.
Add the "Isolated" parameter in the *.network file, e.g.,
[Bridge]
Isolated=true|false
When the Isolated parameter is true, traffic coming out of this port
will only be forward to other ports whose Isolated parameter is false.
When Isolated is not specified, the port uses the kernel default
setting (false).
The "Isolated" parameter was introduced in Linux 4.19.
See man bridge(8) for more details.
But even though the kernel and bridge/iproute2 recognize the "Isolated"
parameter, systemd-networkd did not have a way to set it.
In D-Bus, clients connect to a bus (the usual case), or use direct
questions to each other (the unusual case). A bus is a program one can
connect to and implemented by dbus-daemon or dbus-broker. HOwever,
busses never connect between each other, that doesn't exist. Hence don't
claim so.
This is probably confusion about the fact that sd-bus calls D-Bus
connection objects just "sd_bus" for simplicity, given they are used in
99% of the cases to connect to a bus — only in exceptional cases they
are used for direct connections between peers without involving a bus.
Follow-up for b7bb58ef70
Since a long time the D-Bus spec knows a special bit in its message
header for indicating that "interactive" authentication is OK. The
original hostnamed API is before that was added hence most functions
expose that boolean as explicit argument.
For new added functions let's get rid of it, the message flag is good
enough and replaces it with complete functionality.
No new APIs should carry the "interactive" boolean flag explicitly as
argument anymore.
Follow-up for: 9697662915
The general approach of kernel-install was that each plugin would drop in some
files into the entry directory. But this doesn't scale well, because if we have
multiple initrd generators, or multiple initrds, each generator would need to
recreate the logic to put the generated files in the right place.
Also, effective cleanup is impossible if anything goes wrong on the way, so we
could end up with unused files in $BOOT.
So let's invert the process: plugins drop files into $KERNEL_INSTALL_STAGING_AREA,
and at the end 90-loaderentry.install DTRT with those files.
This allow new plugins like 50-mkosi-initrd.install to be significantly simpler.
Remove incorrect claim that C escapes (such as \t and \n) are recognized and that control characters are disallowed. Specify the allowed characters and escapes with single quotes, with double quotes, and without quotes.
Sometimes hardware vendor does not set DMI info correctly.
Already there is a way that the dbus properties can be overriden by
using hwdb. But that is not user friendly.
This adds two new fields in /etc/machine-info.
Closes#22207.
Currently, running "meson build" followed by "meson test -C build"
will result in many failed tests due to missing dependencies. This
commit adds the missing dependencies to make sure no tests fail.
Add a new setting that follows the same principle and implementation
as ExtensionImages, but using directories as sources.
It will be used to implement support for extending portable images
with directories, since portable services can already use a directory
as root.
Fixes#6308: people want to be able to link a unit file via 'systemctl enable'
from a git checkout or such and refer to other files in the same repo.
The new specifiers make that easy.
%y/%Y is used because other more obvious choices like %d/%D or %p/%P are
not available because at least on of the two letters is already used.
The new specifiers are only available in units. Technically it would be
trivial to add then in [Install] too, but I don't see how they could be
useful, so I didn't do that.
I added both %y and %Y because both were requested in the issue, and because I
think both could be useful, depending on the case. %Y to refer to other files
in the same repo, and %y in the case where a single repo has multiple unit files,
and e.g. each unit has some corresponding asset named after the unit file.
The idea is that when not set, we do whatever we did in the past. But
with a new setting of initrd_generator=mkosi-initrd, mkosi-initrd will
generate an initrd.
In particular, mention the contract the generator has with external
ExecCondition= binaries that may be provided by desktop environments.
But, also mention all the other relevant keys. In particular
X-systemd-skip= is important to be documented.
Strictly speaking, this breaks the backward compatibility, but I guess
in most cases people already sets Scope=link for such routes.
This behavior matches with how 'ip route' command adds such route by
default.
Prompted by https://twitter.com/jplitza/status/1480500562391179270.
* sd-bus/man: document EBUSY error in bus_message_read
The EBUSY error can be returned from sd_bus_exit_container(), and, if
that happens, it will be propogated upwards towards bus_message_read. In
terms of documentation, this means that bus_message_read's man page
can't just include the error text for sd_bus_message_read_basic, as
reading basic types exclusively doesn't have the potential for this
error.
sd_bus_message_read_basic's error documentation isn't incorrect when
applied to sd_bus_message_read, it's just incomplete. While EBUSY is
documented in sd_bus_message_open_container.xml,
it's explanation is unique to the sd_bus_message_exit_container function
and makes for poor documentation of the general read API.
There are a few undesirable properties to how boot entries are
currently sorted.
First, it sorts by entry file name only, which may not correspond
to the title that is shown (for exmaple because it is prefixed by
machine-id). The file ending will also create unexpected ordering
("arch-lts.conf" would come before "arch.conf").
While the list is sorted alphabetically ascending, it is also
lower version/priority first, which is unintuitive. In particular,
a boot-counted entry that is bad (0 tries left) will be at the very
top.
Additionally, the Windows and Mac loaders should be sorted with
the rest of the loaders.
This patch changes busctl capture to generate pcapng format
instead of the legacy pcap format files. It includes basic
meta-data in the file and still uses microsecond time
resolution. In future, more things can be added such as
high resolution timestams, statistics, etc.
PCAP Next Generation capture file format is what tshark uses
and is in process of being standardized in IETF. It is also
readable with libpcap.
$ capinfos /tmp/new.pcapng
File name: /tmp/new.pcapng
File type: Wireshark/... - pcapng
File encapsulation: D-Bus
File timestamp precision: microseconds (6)
Packet size limit: file hdr: (not set)
Packet size limit: inferred: 4096 bytes
Number of packets: 22
File size: 21kB
Data size: 20kB
Capture duration: 0.005694 seconds
First packet time: 2021-12-11 11:57:42.788374
Last packet time: 2021-12-11 11:57:42.794068
Data byte rate: 3,671kBps
Data bit rate: 29Mbps
Average packet size: 950.27 bytes
Average packet rate: 3,863 packets/s
SHA256: b85ed8b094af60c64aa6d9db4a91404e841736d36b9e662d707db9e4096148f1
RIPEMD160: 81f9bac7ec0ec5cd1d55ede136a5c90413894e3a
SHA1: 8400822ef724b934d6000f5b7604b9e6e91be011
Strict time order: True
Capture oper-sys: Linux 5.14.0-0.bpo.2-amd64
Capture application: systemd 250 (250-rc2-33-gdc79ae2+)
Number of interfaces in file: 1
Interface #0 info:
Encapsulation = D-Bus (146 - dbus)
Capture length = 4096
Time precision = microseconds (6)
Time ticks per second = 1000000
Number of stat entries = 0
Number of packets = 22
This explicitly mentions that comments and empty lines are supported
(and ignored) in /etc/locale.conf. It then adds ownership reference
to the factory default.
This adds /etc/locale.conf to the set of configuration files
populated by tmpfiles.d factory /etc handling.
In particular, the build-time locale configuration in systemd is
now wired to a /usr factory file, and installed to the system.
On boot, if other locale customization tools did not write
/etc/locale.conf on the system, the factory default file gets
copied to /etc by systemd-tmpfiles.
This is done in order to avoid skews between different system
components when no locale settings are configured. At that point,
systemd can safely act as the fallback owner of /etc/locale.conf.
Also fixes the following:
- IPServiceType= is moved to [DHCPv4] section,
- drop an incorrect sentence in RouteMTUBytes= in [DHCPv4] section.
- drop unnecessary word 'unsigned'.
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.
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.
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.
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.
If KERNEL_INSTALL_MACHINE_ID is defined in /etc/machine-info, prefer it
over the machine ID from /etc/machine-id. If a machine ID is defined in
neither /etc/machine-info nor in /etc/machine-id, generate a new UUID
and try to write it to /etc/machine-info as KERNEL_INSTALL_MACHINE_ID
and use it as the machine ID if writing it to /etc/machine-info succeeds.
In practice, this means we have a more robust fallback if there's no
machine ID in /etc/machine-id than just using "Default" and allows
image builders to force kernel-install to use KERNEL_INSTALL_MACHINE_ID
by simply writing it to /etc/machine-info themselves.
The ordering of the service wrt. to udevd is enforced by unit configuration,
so no need to tell the user about this. From users' POV, the only thing that
counts is that the unit is enabled and then the right thing happens.
This description will help users who are trying to reset the already configured
CPUQuota= by trying incorrect ways such as CPUQuota=0 or CPUQUota=infinity.
Some types of credentials that a user would want to pass
into the initrd do not depend on the specific kernel/initrd
version. For instance, this can include SSH keys, rootfs
encryption keys, dm-integrity keys, and so on. This
introduces a directory where such credentials can be placed
so that any kernel image will load them
if /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed exists
install that instead of /usr/lib/systemd/boot/efi/systemd-bootx64.efi
the idea is that SecureBoot tooling can create the efi.signed file
whenever /usr/lib/systemd/boot/efi/systemd-bootx64.efi from the package
is updated.
Confer https://github.com/systemd/systemd/pull/19006#issuecomment-800234022:
On some systems it's the admin's explicit choice not to to have the
machine ID leak into the ESP
On some systems the machine ID is transient, generated at every boot,
and hence should not be written to the ESP
When an activation job is skipped because of a Condition*= setting failing,
currently the JobRemoved signal lists 'done' as the result, just as with
a successful job.
This is a problem when doing dbus activation: dbus-broker will receive a
signal that says the job was successful, so then it moves into a state where
it waits for the requested name to appear on the bus, but that never happens
because the job was actually skipped.
Add a new StartUnitWithFlags that changes the behaviour of the JobRemoved
signal to list 'done' or 'skipped'.
Fixes#21520
The documentation of sd_bus_get_timeout wrongfully states that the returned time-value is relative. In fact, it is an absolute value which is based of CLOCK_MONOTONIC. This change corrects that documentation.
