Hardware requires specific handshaking to get it to initialize, the kernel cannot assume that the hardware that was present last time is available this time, and orchestrating everything is not an easy process.
The holy grail would be a kernel organized and designed to cache everything to disk related to its own configuration, and only re-execute/rerun the hardware reinitialization code.
Admittedly, Windows' current approach to bootup is very close: it closes all applications then pseudo-hibernates the kernel. Bootup simply reads the hibernated kernel state from disk and reloads userspace.
This is of course besides traditional full ACPI hibernation, which is pretty cool but isn't a perfect art. (I'm typing this on a ThinkPad T23, a fairly old (and thus well-tested) hardware configuration; its hibernation/resume is usually rock-solid, but this morning my WLAN decided to get all stupid with dhcpcd, and USB decided that while it could see my external HDD, there wasn't a disk inside it. From-scratch boot is still the only way to get a reasonably predictable system state.)
Why do we need this in a kernel? Why not just serialize the essentials of the apps states and re-load it after reboot/sign-in?
I'd prefer the desktop environment to remember which apps were running including which documents were opened in them and their windows positions and just re-launch everything at start-up. Given how fast does everything cold-boot today thanks to modern SSDs, I wouldn't even use standby/hibernate if this worked this way.
My guess is that there would be a microkernel service that is the core OS, like the BIOS, and it could be instructed to actively wipe the memory and reload the boot files when the machine freezes
I suppose there's a procedure of some kind for rebooting from zero, rather than restoring previous state.
I guess I'd like to be able to specify at startup which processes are to be de-hibernated, which are to be restarted from scratch, and which are to remain dead.
It's possible to do a warm reboot into a new kernel without ever powering down and re-initializing RAM.
Also, it may not even be fully rebooting, but instead doing something like killing all processes except init (launchd) which then starts up the installer. I haven't run it, so I don't know exactly what it's doing, but there are several ways to "reboot" without fully rebooting.
That's kind of the point of Windows' Fast Boot option. The base OS pretty much just hibernates at a normal shutdown. No point in re-initializing and restarting all the base services.
This, or have some kind of suspend mode on steroids where everything is back like you left it when rebooting. Kinda like being able to hibernate windows and Linux when rebooting into the other.
Usually the configuration stays the same, though - why not a way for the user to indicate when it has? Hold down an awkward combination of three far-flung keys while booting, the BIOS wakes up and checks every device plugged into it, otherwise it just pulls it in from a cache.
(And how much does the average computer's config change? How many users never change a single part of the hardware configuration of their computer for its entire lifetime? A hobbyist who built their own might swap out CPU/GPU/drive/ram/etc, but how many people upgrade their laptops in any way?)
Get all that backup stuff spun up. Save the state of the entire computer the same way you're saving a hibernation snapshot. Next boot, just pull that snapshot up. Something makes that snapshot crash? Reset and run the slow boot, either because the system caught this, or because the user held down the "invalidate bootup snapshot" chord.
Although realistically I never reboot my computer any more unless I'm doing an OS upgrade anyway. It's all just "sleep" and "wake up" nowadays for me, so I don't care if bootup adds a minute or two to the end of the half an hour or so my computer spent downloading the update and applying it. Maybe a cold boot just isn't worth optimizing any more.
I like the clean slate we get from boot-from-scratch. Some pieces of hardware have subtle state corruption issues that can accumulate over uptime (kinda like Windows) that get flushed out by a reinitialization.
Instead as much as possible of the boot process should be taken off the critical path and be treated more like hotplug/optional peripherals. Those HDDs? They can spin up while I'm already logged in (assuming they're not the boot drive).
This is the kind of thing that keeps my awake at night.
Does anyone here have some practical tips to turn an embedded Linux machine into an appliance? The kind of system that a botched update cannot brick but only momentarily disable until a non-technical user presses a factory reset button of some sort.
Yep. Keep it all hot. North/southbridge, controllers, everything. Skip POST. If something has changed we can just restart once it's warmed up. Anything that still needs a traditional boot (eg a disk drive) we just be assumed to have not changed until proven otherwise. Fuck the MBR. Fuck ROM and BIOS and CMOS. If you don't need to do it between RAM frames, you don't need to do it until you're told to reboot.
If you've been unpowered all day, or if your hardware has changed, or you're worried about security, then you can choose boot from scratch. The only other reason, IMO, is because the computer has just been put together. If all those parts can restore their previous configuration, all they have to do is signal "yep, I'm still in the same configuration" and we should be able to pick up where we left off (again, except for disk drives/ram/networking etc).
The more extreme form of that is to have the OS run from read-only memory. Some embedded systems work that way. Reset, and you're back to the cold start state.
QNX can be built to run that way, for systems with no disk.
The biggest problem with caching things during the boot process is that turning our devices off and on again will not magically solve our problems any more.
Sounds like an opportunity for a generic UI/management tool. The pre/post boot thing could be mitigated by a rebooting into a special stub that just verifies intent/signatures, applies the settings and reboots back into the OS.
This wouldn't be a silver bullet, many hardware have their own controllers, with their own firmware and their own state that the kernel cannot directly control. And for the same type of hardware some might have a full reset with a power cycle, and other might not.
For some reference you can look at the GPU reset bug for navi 10 and below.
> whether detecting changes and initating a more complete boot or dealing with it in the GUI.
Sure, they can detect hw changes and make full cold boot, therefore losing all RAM data which was saved to the disk at the point of hibernation. (It would be like a quick dirty reset.) Or they can restore that data back to RAM and crash the kernel instantly. In either case, RAM contents are lost.
So each time I turn off the PC, I have to plan ahead, "do I want to use poweroff-type-I or poweroff-type-II option?" If I won't guess right, then I lose my data.
I suspect it's less about having CPU as afterthought, than about how and who is to take CPU out of "awaiting to be booted" state. Ancient CPU simply had a BIOS mask ROM hardwired to reset vector and immediately load from it upon release of reset line, nowadays and on more complex systems, I believe that's what Intel Management Engine/Apple Secure Enclave/VideoCore GPU/etc. will do, not the main CPU itself.
As someone who worked on boot up sequence in Windows, that won’t work. You could kill components in the system if someone forgets to press the right keys on bootup. The snapshot method you mention is essentially how it already works
The holy grail would be a kernel organized and designed to cache everything to disk related to its own configuration, and only re-execute/rerun the hardware reinitialization code.
Admittedly, Windows' current approach to bootup is very close: it closes all applications then pseudo-hibernates the kernel. Bootup simply reads the hibernated kernel state from disk and reloads userspace.
This is of course besides traditional full ACPI hibernation, which is pretty cool but isn't a perfect art. (I'm typing this on a ThinkPad T23, a fairly old (and thus well-tested) hardware configuration; its hibernation/resume is usually rock-solid, but this morning my WLAN decided to get all stupid with dhcpcd, and USB decided that while it could see my external HDD, there wasn't a disk inside it. From-scratch boot is still the only way to get a reasonably predictable system state.)
reply