Bug #724
closed
reboot takes too long
100%
Description
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.
Updated by Hammel almost 5 years 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
- kexec
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.
Updated by Hammel almost 5 years 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.
Updated by Hammel over 4 years ago
- Status changed from In Progress to Closed
- % Done changed from 20 to 100
This was addressed by RM #746 - by adding -f to the reboot command. This is kinda hacky but it's a quick hardware reset and we don't worry too much about sync'ing or flushing with current PiBox use cases. If we did, we could wrap this in a small script that did that for us.
Closing issue.