Add a new command `mxgrub --reboot` which reboots to the selected kernel
via kexec.
Notes:
* Do a sync before triggering the reboot, so that services are still
available while the bulk of dirty pages is written, which can take
a relevant time on big machines.
* kexec (without -l, -p, -e, or -f) loads the kernel and than calls
shutdown, which is handled by systemd. So this is a full shutdown ;
systemd will stop services, unmount filesystems and sync all disks
(again). It just recognizes the loaded kernel and calls the
equivalent of (`kexec -e` instead of `reboot -f`) in the very last
step. We just avoid the EFI/BIOS initialization and grub and kernel
loading.
* When an nfs server restarts, clients currently get 90 seconds to
renew their leases. Some nfs file operations from the clients are
blocked during this time, so this adds to the time, a workstation
appears to be frozen to the user. We can consider to reduce this
lease_time of our servers to a lower value. The disadvantage is,
that the clients need to send more RENEW request (2/3 of the lease
time, so every minute currently) and might lose lock state if the
network is interrupted for a longer time.
* Strictly speaking, kexec() has not much to do with grub. However,
in our implementation of the grub based boot it is related because
the record of which kernel to boot next (the selected kernel)
is kept in the grub environment file. So if we want the kexec based
reboot to start the same kernel as a reboot sequence over grub
would do, we need to read the grub environment file. This should be
enough excude to implement the command in mxgrub.
* Loading of the new kernel might fail on machines where not enough
continuous physical memory is availble because of fragmentation.
Timings:
* reboot theinernet (to lightdm login prompt) : 47 -> 22 seconds
* reboot claptrap (to console login prompt) : 160 -> 59 seconds
* reboot claptrap (to NFS server available) : 165 -> 43 seconds
* reboot claptrap (to locks available) : 262 -> 141 seconds