It is very simple - and applies for all operating systems - the bigger the size of data which has to be read at boot time is, the longer the boot time.
Of course it is not without importance at which speed the data is read (difference of boot media).
I think that with recent hardware it accounts for a very little extent respect to uncompressing data in RAM, creating filesystem, creating dev directory, module loading and timeouts.
loading extensions "onboot" could make up for the vast part of differences of boot times.
indeed fast boot would encompass remastering; at least "tclocal" trick should be used (I fear both do not work for every combination of extensions).
I could not see how housekeeping of the backup which is in the direct personal responsibility of the user would be related to init scripts.
I think, as well as the member I answered, that we can say tinycore handles backup/restore in a fashion similar to a boot/init script. The meaning was that.
When it resets, the PC is set to some fixed starting address.
000 Registers may or may not be cleared at this point, so the first thing that should happen is that all registers should be cleared.
001 The bare minimum needed to interface to some storage device and the full range of RAM needs to be initiated.
010 Data is copied (at max speed possible) from hd0 to RAM. The smaller this file, the faster it'll boot.
500 Registers are set to what is indicated by file from disk.
510 PC set to origin of in RAM.
511
this was addressed by Hiroki Kaminaga (I know just his work, I don't know others) in "Improving Linux Start Time Using Software Rescue". It gains just 50% time.
This might be a vast simplication of the process, but the point is that what is typically done by the BIOS, needs to be done by the bootloader. The more the bios can get out of the way the better. Or rather, ideally the bootloader would be in the BIOS, and not in the MBR (why do we need that thing again? It seems unnecessary.)
You are talking about "coreboot" project. But I do not think it is a useful way: kernel patching is the most easy and effective way to gain boot speed, then also init scripts have to be customized.
Grub is typically used, but which bootloader is the FASTEST?
It seems that some time can be gained also patching the boot loader. It has to be investigated.
With suspend to RAM there would be a certain threshold of time at which either shutdown would use more or less energy in comparison. My estimated guess would be that 2 boots a day may use more energy than suspending to RAM.
the king of all tricks would be storing a RAM image of a booted system and loading it at boot then jump to a suitable kernel routine. But it is not clear if devices would be initialited. This could be solved with a quick "wake-up" routine.
In fact the entire boot process could be re-thought but it would remain a linux system I think.
Welcome
FAQ
Downloads
Wiki
