There are two ways to speed up system boot:

  1. Remove cruft from the boot sequence (parallelizing init scripts, readahead, removing modules, etc.)
  2. Bypass the boot sequence completely to boot into a pre-saved image

This spec talks about the second technique. The first one is already being addressed in other teams/sessions.

Release Note

The x86 boot sequence is quite fragile with the multitude of (buggy) BIOSes that need to be supported. Hence the grub fast boot changes should not be the default option, but rather enabled explicitly by the user.


Netbook users and OEMs are asking for faster boot times so that the (mobile) devices are quickly usable. The idea is that these devices should have the response times of a traditional mobile device such as a mobile phone and the functionality of a laptop.

Use Cases

  1. Alice is attending a conference. Typical of conferences, there are very few power sockets. While listening to the sessions, Alice would like to take notes, check email and then close the lid and go back to listening. She repeats this many times during the day. In order to save battery, the machine should suspend/hibernate when the lid is closed and resume quickly when it is opened. The battery should last the whole day on a single charge.

  2. Bob manages a server farm that guarantees 99.99% uptime. That means 52 minutes of downtime allowed per year. Considering some of these machines take 10+ minutes to boot, every second saved counts.
  3. Charlie manages a 1000-seat Linux desktop installation. A majority of his users do not power-off their computer at night because they want an instant-on experience in the morning. Some of the more conscientious users suspend the machine, but it still draws some power.

Alice needs her laptop to save power and become usable quickly. Suspend/Resume (STR) ought to give her that. If STR doesn't give a full days battery life, fast boot might become more attractive.

Bob could definitely use fast boot, but only if it supported his enterprise hardware configurations - so LVM and RAID support need to be thought about.

With Fast Boot, Charlie could mandate compulsory shutdowns since users would be more amenable to sub-30s boots.


Need to verify numbers from Intrepid

Here are typical boot/suspend/hibernate/resume numbers from a laptop:

Shutdown numbers

  • Shutdown system: ~15s (why?!)
    • What happened to flush buffers to disk and kill power?
  • Hibernate: 20-50s
    • Freeing up memory and then saving the application state to disk takes time
  • Suspend: ~5s
    • Put memory in self-refresh and cut power to processor and board

Startup numbers

  • Fresh Boot: 60+ seconds
  • Resume from hibernate: ~40s (application state restored)
  • Fast boot: ~25s (from grub fast boot tests)
  • Resume from suspend: ~5s



Grub Fast Resume

  • patches from
    • git://
  • working swsusp


  • Grub patches against 0.9.7 which is a dead-end for upstream. So patches will never go upstream
    • Work reportedly ongoing to support Grub2


  • Resumes from disk a lot faster due to LZF compression
  • Nigel maintains a TuxOnIce kernel for all Ubuntu flavours (550Kb patch)

    • Git tree on
  • Offer a .deb package to users?


  • Work is not going upstream. EVER.
    • Upstream working at a kexec-based solution as successor to in-kernel suspend

Snapshot boot for ARM

  • Proof-of-concept done on OSK5192 boards
  • Bootloader (u-boot) taught about swsusp image format
    • swsusp had to be ported to ARM first

Test/Demo Plan

Unresolved issues

BoF agenda and discussion

  • How to enable grub fast boot optionally for users?
  • Can compression part of TuxOnIce be used with swsusp?


  • The Launchpad page talks about TuxOnIce support. Is thissomething being seriously considered? I would loveto finally have it available. --MattPrice

    • The whole framework is quite big (500K patch). It would be nice if we could get some features of TuxOnIce ported to swsusp e.g. the LZF compression --AmitKucheria


KernelTeam/Specs/FasterBootFromImage (last edited 2008-12-06 18:15:34 by 216)