reboot takes too long
|Status:||In Progress||Start date:||27 Oct 2019|
|Category:||04 - Root File System|
|Target version:||1.1.0 - Upgrades|
|Severity:||05 - Very Low|
There is no saved data to worry about so a reboot should be nearly instantaneous. But it's not. Find out why and fix it.
#1 Updated by Hammel about 1 month ago
There are a couple of things to deal with here.
Hard reset vs soft reset¶
A hard reset is a power cycle. This requires sync'ing writes to disk and then power cycling the system. The Busybox reboot command already does this. It's not clear why this takes so long, however.
A soft reset is a kexec of the kernel/initramfs pair. System sync'ing must be done first. Unmounting of filesystems (other than the overlay) should also be done. Then the kexec is done. Setup for the kexec can happen before any sync'ing or unmounting is done.Soft resets should use the following sequence:
- Setup kexec
- Enable sysrq actions for sync'ing and read-only remounts using sysrq-trigger
- Send a SIGTERM to all processes, except for init, using sysrq-trigger
Reboot of Dev Platform¶
The dev platform only has the reboot command. There is no graphical reboot because we aren't running an app-based system. One option is to move reboot to reset and implement a kexec-based reboot. So reset becomes the hard reset and reboot becomes the soft reset.
Reboot of Media (or other app-based) platform¶
These can utilize their own wrappers for the hard and soft resets implemented in the dev platform. The default app for the Media system could use the soft reset while the launcher might support a custom key sequence to force a hard reset.
#2 Updated by Hammel about 1 month ago
- Status changed from New to In Progress
- Priority changed from Immediate to Low
- % Done changed from 0 to 20
- Severity changed from 04 - Low to 05 - Very Low
Uh, well, this appears to be something to put on the back burner for now: kexec appears broken. The real reason is that kexec needs one core running to switch kernels. RPis (2B and later) have 4 cores and can't hotplug them, that is, stop cores at will. RPi's can't stop the other cores so kexec won't work (scan down to the kexec section for details).
I wrote a script to do the kexec but ran into trouble trying to run it, apparently because kexec isn't supported by RPIs.
There is no need to continue down this path because this is a hardware limitation that can't be overcome by kexec, at least not currently. So I'm moving this to the very bottom of the stack until, perhaps in the future, there is a workaround.