Re: The best way to execute kexec via dbus

[Andrei Borzenkov <arvidjaar@xxxxxxxxx>]

Please answer to the list, not me personally. You do it second time.

On 26.08.2022 17:12, Tomáš Hnyk wrote:
> On Friday 26. August 2022, 15:02:54 (+02:00), Andrei Borzenkov wrote:
> 
>> On 26.08.2022 13:54, Tomáš Hnyk wrote:
>>>
>>>>>>
>>>>> Indeed, it must have been the late night, they are the same. However,
>>> the following are not the same even the man page says they are:
>>>>>
>>>>> sudo systemctl kexec # results in kexec
>>>>>
>>>>> full log here: https://hastebin.com/gubivumaha.apache
>>>>>
>>>>> srp 26 10:38:08 GreenOne systemd[1]: Reached target System Shutdown.
>>>>> srp 26 10:38:08 GreenOne systemd[1]: Reached target Late Shutdown
>>> Services.
>>>>> srp 26 10:38:08 GreenOne systemd[1]: Starting Reboot via kexec...
>>>>> srp 26 10:38:08 GreenOne systemd[1]: Shutting down.
>>>>> srp 26 10:38:08 GreenOne systemd-shutdown[1]: Syncing filesystems and
>>> block devices.
>>>>> srp 26 10:38:08 GreenOne systemd-shutdown[1]: Sending SIGTERM to
>>> remaining processes...
>>>>> srp 26 10:38:08 GreenOne systemd-journald[416]: Journal stopped
>>>>>
>>>>>
>>>>> sudo systemctl start kexec.target --job-mode=replace-irreversibly
>>> --no-block # failed attempted kexec
>>>>>
>>>>
>>>> You are right. systemctl does more (and differently) in case of
>>>> "systemctl kexec". Not sure whether it needs explicit documentation
>>>> though, as expectations are that it /should/ have the same effect.
>>>>
>>> Well, I guess then the man page could say something like (caps are what
>>> would change) - I did assume one was just shorthand for the other:
>>>
>>> Shut down and reboot the system via kexec. This is MORE OR
>>> LESS/TYPICALLY/SHOULD BE(+delete "is") equivalent to systemctl start
>>> kexec.target --job-mode=replace-irreversibly --no-block.
>>>
>>>>> srp 26 10:39:04 GreenOne systemctl[2041]: Cannot automatically load
>>> kernel: ESP mount point not found.
>>>>
>>>> That could be the actual reason. systemctl attempts to autodetect kernel
>>>> for kexec and it needs ESP; final call to "systemctl --force kexec"
>>>> happens late, when ESP (/boot/efi in your case) is already unmounted.
>>>>
>>>> For testing you could set DefaultDependencies=false for /boot/efi to
>>>> avoid it being unmounted on shutdown.
>>>>
>>> Where can I set it? kexec.target already has "DefaultDependencies=no" in
>>> [Unit]?
>>>
>>
>> It is not about kexec.target.
>>
>> You can add it in drop-in, like
>>
>> bor@localhost:~> cat /etc/systemd/system/boot-efi.mount.d/nodef.conf
>> [Unit]
>> DefaultDependencies=false
>> bor@localhost:~>
>>
>> By default fsck service has RemainAfterExit=yes and mount units require
>> fsck services so they are stopped anyway, I had to add override
>>
>> bor@localhost:~> cat
>> /etc/systemd/system/systemd-fsck@dev-disk-by\\x2duuid-893B\\x2d91D8.service.d/exit.conf
>>
>> [Service]
>> RemainAfterExit=false
>> bor@localhost:~>
>>
> 
> Indeed, the above makes these two work (included when launched from the GUI), thanks!: 
> sudo systemctl start kexec.target --job-mode=replace-irreversibly --no-block
> qdbus --system org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.StartUnit kexec.target replace-irreversibly
> 
> Is this a misconfiguration on my part or is that something that should be filled as a bug?

This should be filed as a bug. It is expected to work (IMHO).

> I would have expected this to just work right away. Is it safe if I leave my configuration system with the overrides you suggested?
> 

Well, I do not trust systemd to not attempt fsck on mounted filesystem
in response to some event, so I guess better is to remove
Conflicts=shutdown.target.

> 
>>
>> But notice also that systemd only supports automatic detection when
>> using systemd-boot. E.g. here openSUSE provides customer service that
>> detects default grub2 boot entry and performs "kexec --load".
>>
> 
> But I am using systemd-boot!

Do not forget to mention in in your bug report.

> systemd-analyze gives "Startup finished in 8.467s (firmware) + 402ms (loader) + 3.001s (kernel) + 2.885s (userspace) = 14.756s" 
> Those eight seconds in firmware are why I am after kexec. Grub gives 4 seconds in loader, only systemd is this fast. I am not sure how to check if I booted useing systemd-boot otherwise.

It does not really matter for this specific problem. What matters is
that your have systemd-boot configuration where systemctl can find
suitable boot entry. Of course, it you do not actually use systemd-boot
this can be considered a bug as well, but do not mix two independent issues.

> efibootmgr gives:
> 
> 
> BootOrder: 0000,0001,0019,001A,001D,001E,0010,0011,0012,0013,0014,0015,0020,0022,0023,0024,001B,001C,001F,0003
> Boot0000* Linux Boot Manager
> Boot0001* ubuntu
> Boot0003* Linux-Firmware-Updater
> 
> So I do not understand why the kexec kernel is not loaded, should I remove grub completely?
> 

I do not understand this last sentence.