Home_greyopenFATE - openSUSE feature tracking > #305326
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

5 Second Boot

Feature state

openSUSE Distribution
Rejected Information
Rejected Information


The amount of time required to boot up needs to be reduced drastically. I suggest we consider the work being done in this article:


as our baseline and strive to make similar adjustments.

User benefit:

As we continue to get more involved in the Thin Client and UMPC markets, boot time becomes increasingly important. Intel's Moblin project is touting boot time as one of the significant features/advantages of their Moblin project. There are signs that other distros are following suit. We have at least one Thin Client partner that is requesting significant improvements in boot time in order to remain competitive. In fact, SLETC would have been included on more thin client hardware shipments to-date had we a faster boot time.


icons/user_comment.png J. A. wrote: (10 years ago)

I spoken with both AJ and Michael Meeks regarding this requirement. AJ suggested that include Coolo in the discussion since it will most definitely affect the distribution as a whole.

icons/user_comment.png S. K. wrote: (9 years ago)

similiar adjustments? Do you mean the "We had to do a lot of damage to X," part or the "use xfce" part?

There is a limit on what you can do in a generic system and many of the low hanging fruits is already done. If you talk about getting a thin client to boot fast, then making transparent use of suspend & resume is the way to go IMO. Booting off cold hardware is problematic if you want more than xfce. There are about 100MB data to read for a pretty standard KDE session (and I assume GNOME is similiar) - on a pretty fragmented file system you get ~8MB/s netto - so just reading your files takes already 12s.

Making preload dynamic on the blocks actually used is something that was discussed long, long ago, but the kernel still doesn't provide the infrastructure - so this is one of the TODOs, but possibly Intel got that ball rolling.

Kernel drivers being quicker with probing would be another TODO, also listed in the article.

Another urgent TODO is defragmentation because readahead helps only a little if the next update will scatter the files around your 1TB hard drive.

icons/user_comment.png J. D. wrote: (9 years ago)

may be this is plain stupid, forgive me if it is.
The install time was dramatically reduced by the use of "images" of installs. Could it not be possible to build "images" of the installed system - that is to have all the necessary files on boot able to read at once.
It's not exactly the same as suspend to disk, of like a suspend to disk with only the system.

Most computers never change hardware and a new grub entry could be added: boot with new hardware

icons/user_comment.png R. U. wrote: (9 years ago)

Squashfs could be utilized for that. It would be superior to preload as it also could do the initrd thing. But every time a /bin/lib is updated the whole squash-start-image needs to be updated also. Andthere it is to make sure such an image is not fragmented on disk.

icons/user_comment.png S. L. wrote: (8 years ago)

Already we need to update dependencies of running scripts after adding a new script. We can create tarbar on this command. Init system may only checks last modify date for each file in tarbar and compare it with file outside tarbar.

Last change: 3 years ago
Loading tags...
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint