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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
It should make it easier to figure out what exactly services do there.
For example, with SYSTEMD_LOG_LEVEL=debug userdbd (v249) prints
```
varlink-5: New incoming message: {"method":"io.systemd.UserDatabase.GetUserRecord","parameters":{}}
```
before it crashes and systemd-resolved prints
```
varlink-21: New incoming message: {"method":"io.systemd.Resolve.ResolveAddress","parameters":{"address":[127,0,0,1],"flags":0,"ifindex":1000000,"family":0}}
```
and those messages are helpful (especially when scripts causing them
aren't clever enough to keep track of random stuff they send to systemd
:-))
If we assign our own test runner, passing arguments stops working
as unittest won't instantiate its own test runner after it parses
the arguments from sys.argv.
Consequence is that the tests will write to stderr now instead of
stdout since it doesn't seem possible to configure the stream that
unittest.main() will instantiate its test runner with so it'll
default to sys.stderr.
otherwise units using `DynamicUser=yes` won't be able to write the
coverage stats (currently affecting TEST-20-MAINPIDGAMES).
`DynamicUser=yes` implies `ProtectSystem=strict` and
`ProtectHome=read-only` and can't be overridden hence we need to
utilize `ReadWritePaths=` to work around that.
When checking if we look at the root directory we actually need to
compare both st_dev *and* st_ino. The existing check only checked the
latter. Fix that.
On my local system I linked up the ESP and XBOOTLDR partitions, and
ended up with duplicate entries being listed. Try hard to detect that
and only enumerate entries in the ESP if it turns out that both dirs
have the same dev_t.
This should detect both bind mounted and symlinked cases and should make
our list output less confusing.
THis makes sure that find_esp_and_warn() + find_xbootldr_and_warn()
follow our usual coding style that on success all return values are
initialized. We got that right in most successful codepaths out of these
functions, but missed the one where the paths are manually overwritten
via env vars.
Let's improve display of boot entries and show what type they have (i.e.
boot loader spec type 1, or type 2, or auto-discovered or reported by
boot loader), and in particular mark entries the boot loader discovered
but we can't find (i.e. that likely vanished, or possibly couldn't be
found due to a misconfiguration) and that the boot loader didn't find
but we see (which are new, or possibly also the result of
misconfiguraiton).
This is supposed to be a replacement for #22161, but instead of hiding
vanished entries, highlights them, which I think is more appropriate for
a low-level tool such bootctl.
Replaces: #22161#22398
Quite often we compare uuids/id128 formatted as strings with specific
values. So far we usually used streq() for that. let's add a new
explicit helper for this in id128_equal_string() that compares a string
with an sd_id128_t and is more robust than a simple string comparison.
Moreover, we can mroe easily reuse the various defines we have for
specific UUIDs, for example those from gpt.h.
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.
get_block_device_harder() returns == 0 if the fs is valid, but it is not
backed by a single devno. (As opposed to returning > 0 if the devno is
valid). Let's catch this case and log a clear message, and don't bother
open the device in that case.
This is mostly cosmetical, as either way, systemd-gpt-auto-generator
doesn't work in scenarios like that.
Prompted-by: #22504
device nodes with 0 dev_t are not real (and for that reason such inodes
are used as whiteouts in overlayfs, for example), hence refuse them
early. It seems wrong going to sysfs for something we know can't exist
anyway.
