Lennart Poettering
5caa3167ff
This renames find_esp() to find_esp_and_warn() and tries to normalize its behaviour: 1. Change the error that is returned when we can't find the ESP to ENOKEY (from ENOENT). This way the error code can only mean one thing: that our search loop didn't find a good candidate. 2. Really log about all errors, except for ENOKEY and EACCES, and document the letter cases. 3. Normalize parameters to the call: separate out the path parameter in two: an input path and an output path. That way the memory management is clear: we will access the input parameter only for reading, and only write out the output parameter, using malloc() memory. Before the calling convention were quire surprising for internal API code, as the path parameter had to be malloc() memory and might and might not have changed. 4. Rename bootctl's find_esp_warn() to acquire_esp(), and make it a simple wrapper around find_esp_warn(), that basically just adds the friendly logging for the ENOKEY case. This rework removes double logging in a number of error cases, as we no longer log here in anything but ENOKEY, and leave that entirely to find_esp_warn(). 5. find_esp_and_warn() now takes a bool flag parameter "unprivileged_mode", which disables logging in the EACCES case, and skips privileged validation of the path. This makes the function less magic, and doesn't hide this internal silencing automatism from the caller anymore. With all that in place "bootctl list" and "bootctl status" work properly (or as good as they can) when I invoke the tools whithout privileges on my system where /boot is not world-readable
systemd - System and Service Manager
Details
General information about systemd can be found in the systemd Wiki.
Information about build requirements are provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the HACKING file for information how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.