| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
Instead of exposing just the partition type UUID, let's expose the
GptPartitionType struct, which has a lot more information available
in a much more accessible way.
Also, let's get rid of SECONDARY/OTHER in PartitionDesignator. These
were only there to support preferred architectures in dissect-image.c,
but we can easily handle that by comparing architectures when we decide
whether to override a partition. This is done in a new function
compare_arch().
|
| | |
|
| |
|
|
| |
This also avoids multiple evaluations in STRV_FOREACH_BACKWARDS()
|
| |
|
|
|
| |
At least for now they are all GPT partition types, and we should mention
that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.
We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.
Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
|
| |
|
|
| |
It may be useful when debugging daemons.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I think this formatting was originally used because it simplified
adding new options to the help messages. However, these days, most
tools their help message end with "\nSee the %s for details.\n" so
the final line almost never has to be edited which eliminates the
benefit of the custom formatting used for printf() help messages.
Let's make things more consistent and use the same formatting for
printf() help messages that we use everywhere else.
Prompted by https://github.com/systemd/systemd/pull/18355#discussion_r567241580
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Presently, CLI utilities such as systemctl will check whether they have a tty
attached or not to decide whether to parse /proc/cmdline or EFI variable
SystemdOptions looking for systemd.log_* entries.
But this check will be misleading if these tools are being launched by a
daemon, such as a monitoring daemon or automation service that runs in
background.
Make log handling of CLI tools uniform by never checking /proc/cmdline or EFI
variables to determine the logging level.
Furthermore, introduce a new log_setup_cli() shortcut to set up common options
used by most command-line utilities.
|
| |
|
|
|
|
| |
The tool deals with any kind of 128bit id, not just uuid, and by default
we display just a series of hex chars, hence let's not claim everything
was a "uuid", but just generically say "id"
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Was getting:
../src/id128/id128.c:15:1: error: initializer element is not constant
static sd_id128_t arg_app = SD_ID128_NULL;
^
when building on CentOS 7.
Other parts of the code initialize `static sd_id128_t` to {} and this
was the original setting before a19fdd66c22 anyways.
|
| |
|
|
|
|
|
|
| |
For some unrelated stuff I wanted the machine ID in UUID format, and it
was annoying doing that manually. So let's add a switch for this, so
that this works:
systemd-id128 machine-id -u
|
| |
|
|
| |
We must be all lazy, at least I know I always used -p ;).
|
| |
|
|
|
|
|
|
|
|
| |
When emitting the calendarspec warning we want to see some color.
Follow-up for 04220fda5c.
Exceptions:
- systemctl, because it has a lot hand-crafted coloring
- tmpfiles, sysusers, stdio-bridge, etc, because they are also used in
services and I'm not sure if this wouldn't mess up something.
|
| | |
|
| | |
|
| |
|
|
|
| |
This is high-level functionality, and fits better in shared/ (which is for
our executables), than in basic/ (which is also for libraries).
|
| |
|
|
|
|
|
|
|
| |
This way, we can extend the macro a bit with stuff pulled in from other
headers without this affecting everything which pulls in macro.h, which
is one of our most basic headers.
This is just refactoring, no change in behaviour, in prepartion for
later changes.
|
| | |
|
| | |
|
|
|
The raison d'etre for this program is printing machine-app-specific IDs. We
provide a library function for that, but not a convenient API. We can hardly
ask people to quickly hack their own C programs or call libsystemd through CFFI
in python or another scripting language if they just want to print an ID.
Verb 'new' was already available as 'journalctl --new-id128', but this makes
it more discoverable.
v2:
- rename binary to systemd-id128
- make --app-specific= into a switch that applies to boot-id and machine-id
|
