|
Bugzilla – Full Text Bug Listing |
| Summary: | systemctl kexec fails with error | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Smith <jsmithfpv> |
| Component: | Other | Assignee: | systemd maintainers <systemd-maintainers> |
| Status: | RESOLVED UPSTREAM | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | fbui |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE Tumbleweed | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Smith
2024-03-10 20:01:12 UTC
I believe this may be a systemd bug. https://github.com/systemd/systemd/issues/24588 `systemctl start kexec.target` seems to do the correct thing. It requires user auth, which is annoying, but that's at least my temporary fix. (In reply to Smith from comment #0) > Running systemctl kexec results in the following error. > "Failed to open file system "/dev/nvme0n1p1": Permission denied". Yes, I think `systemctl kexec` has always required root privileges. > Running with sudo instead results in "No boot loader entry suitable as > default, refusing to guess." According to systemctl man page, `systemctl kexec` is searching for a kexec kernel to load if none has been loaded before. This automatic search only works if the bootloader running on your system follows the bootloader specification, which is not the case with grub2 (at least by default). Hence, as you noticed, you'll have to load the kexec kernel manually in order to skip the automatic search and make `systemctl kexec` works on TW with grub2 as there's currently no option for disabling the automatic search with `systemctl kexec`. So this seems to work as designed. It's not ideal but systemd upstream seems to voluntary make things more complicated than they should be for distros that haven't embraced the bootloader specification yet (that's at least what https://github.com/systemd/systemd/issues/15029 suggests). > Yes, I think `systemctl kexec` has always required root privileges.
I don't believe it did around a year ago, even current Leap documentation seems to suggest that you can just run `systemctl kexec` to trigger the service. This behavior seems new and unexpected.
Previously, my system's reboot menu was using `systemctl kexec`. Since then, I've had to switch it to `systemctl start kexec.target`, which asks for PAM instead. That doesn't really bother me much, but it is different.
It is a shame to hear that it is an upstream issue. Thanks so much!
(In reply to Smith from comment #3) > > Yes, I think `systemctl kexec` has always required root privileges. > > I don't believe it did around a year ago, even current Leap documentation > seems to suggest that you can just run `systemctl kexec` to trigger the > service. This behavior seems new and unexpected. At least it was the case with leap 15.4: $ systemctl kexec ==== AUTHENTICATING FOR org.freedesktop.login1.set-wall-message ==== Authentication is required to set a wall message Authenticating as: root Password: ==== AUTHENTICATION COMPLETE ==== ==== AUTHENTICATING FOR org.freedesktop.login1.reboot ==== Authentication is required to reboot the system. Authenticating as: root Password: The search auto logic dates from 4bb2e9d466a (v236) and since this commit the `systemctl kexec` requires that either the kexec kernel is already loaded or sd-boot is the used bootloader. Since this commit is pretty old I doubt that upstream will accept to restore the old code but feel free to ask ;) Closing this bug as this works as designed (by upstream). Hope that makes sense. |