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.
If the test logs contain lines like:
```
...systemd-resolved[735885]: profiling:/systemd-meson-build/src/shared/libsystemd-shared-250.a.p/base-filesystem.c.gcda:Cannot open
```
it means we're possibly missing some coverage since gcov can't write the stats,
usually due to the sandbox being too restrictive (e.g. ProtectSystem=yes,
ProtectHome=yes) or the $BUILD_DIR being inaccessible to non-root users.
to, hopefully, get rid of the following error:
```
2022-02-13 13:32:12 [ERROR] Failed to get [GITHUB_TOKEN]!
2022-02-13 13:32:12 [ERROR] []
2022-02-13 13:32:12 [ERROR] Please set a [GITHUB_TOKEN] from the main workflow environment to take advantage of multiple status reports!
```
The 'slim' version drops certain storage-heavy linters[0] which we don't
use anyway, so let's make the job a bit faster by downloading and using
a smaller image.
[0] https://github.com/github/super-linter#slim-image
Otherwise, the managed configs, that is addresses, routes and so on
configured by the previously assigned .network file will not be dropped
on reconfiguring the interface.
CIFuzz has been kind of broken for a couple months because
coverage reports downloaded from OSS-Fuzz contain absolute
paths while paths to files changed in PRs are relative and they
don't match. It makes it kind of hard for CIFuzz to figure out
what it should run so it runs either all fuzz targets or just new
fuzz targets. Until that issue is fixed let's just always predictably run
all fuzz targets.