Take the 2-minute tour ×
Raspberry Pi Stack Exchange is a question and answer site for users and developers of hardware and software for Raspberry Pi. It's 100% free, no registration required.

I'm creating an embeddable remote application that won't be permanently switched on. I've been playing around with different OS distributions and can reduce the time to boot substantially by using better SD cards with faster read speeds. I'm not fixed to any particular distribution, so I can strip down as much as neccessary to use a minimal Linux distribution.

(I've attempted to look for benchmarks that people have ran to improve boot time, but I haven't found anything with hard figures.)

I could also use build root (see also YouTube video Raspberry Pi - Super Fast Boot Time - Marshmallow Entertainment System)...

share|improve this question
You should vote to close this question. Then users will be redirected to the original question and add more answers. SInce that one hasn't been marked as answered yet. –  ppumkin Mar 26 '14 at 16:05
I'm just thinking that this one has plenty of activity (views are obviously not as high, simply because this one is less than a day old), more votes, & more answers, so I thought it might be better to leave this one up, and then possibly move your answer over here. It's really a matter of convenience I think. 1 user moving his answer over as opposed to 3 moving their's and thus loosing all votes, conversation and the like. Is there any reason why we should go one way or the other? I don't mind, I'm just thinking that the other people who answered may not want to move, and thus we lose content –  RPi Awesomeness Mar 26 '14 at 21:11
@ppumkin Check out this Meta.SE post regarding the closure of dupes: Do Not delete good duplicates and this SE blog post. I think they agrees with my previous point. Unless the duplicate is a copy-paste of the other one, or terrible quality, and because this one has plenty of answers/activity, we should just leave them both open. –  RPi Awesomeness Mar 26 '14 at 21:13
@ppumkin Good points, so long as this one isn't deleted. I originally reviewed Leave Open, but I guess marking this as a duplicate of that is the right way to go. Only thing I can think of is that I at least want to have an higher-quality Q/A on the marked original, than on the duplicate. That is definitely not the case here. –  RPi Awesomeness Mar 27 '14 at 20:08
Yea, you are right. There are more answers here. Seems to have got more attention. I suppose we need to leave it to the moderators to decide as they will know better what to do here. Anyway. Well done with getting allot of votes on your answer :) I am sure the OP appreciates your contribution. +1 –  ppumkin Mar 27 '14 at 20:15

8 Answers 8

up vote 9 down vote accepted

If you combine Arch Linux with the features that Fred suggested, you should get a generally fast booting OS.

What slows down OS' boot-times is

  1. Slow read/write (I/O) speeds.

    So you using a faster SD card will help, a Class 10 card will be substantially faster than a Class 4 card. I misunderstood how SD card classes worked, and that has been pointed out quite clearly in the comments, my bad. Actually, a Class 10 card will be faster than a Class 4 card for large file transfers such as HD video and whatnot. Apparently Class 4 performs just as well with smaller files. Again, my bad, but hey, we all learn now and again.

  2. A bogged-down init sequence.

    If you have lots of software that fires up during the boot phase, the boot-time is going to be slower. More software starting == Longer boot time.

    Thus, if you need a fast boot, cut as much software from the init sequence as possible. You can create a simple script (or I'm sure there is one out there) that will launch software after the main boot sequence completes, spreading the load out a bit more.

That's basically it. Arch Linux is probably the way to go, combined with the features Fred mentioned, as I said before. Arch is a very minimal OS and may not be the best thing for a beginner to use, but if you have experience in Linux, then go for it. It just takes a bit of setting up, as it comes with the bare minimum to install and that's it.

Hope your project goes well!

share|improve this answer
SD card "class" is a very poor indicator of performance in an embedded system. The "class" ratings are for large sequential file transfers (like you have with a multi-megapixel digital camera), not for small files such as startup scripts. Class 4 cards regularly outperform most Class 10 cards on 4k read and write operations by a factor of 100 or more. There are Class 10 cards with good IOPS, but those models are few and far between. –  Ben Voigt Mar 26 '14 at 15:24
Yea I agree with @BenVoigt - when i Used class 4 it seemed like small writes and updates were fast but yea large transfers on class 10 are much better. I wish I could use a RAM card powered by battery for instant performance. –  ppumkin Mar 26 '14 at 16:07
I'm sorry, I didn't know that. I shall fix that immediately. I had understood that the higher the class the higher the speed. Thanks for pointing that out, I just learned something :D Thanks for the upvotes too :) –  RPi Awesomeness Mar 26 '14 at 18:12
I'm wondering why my answer got downvoted. I don't entirely mind the loss of rep, I just want to know what merited the downvote, so I can improve my answer. –  RPi Awesomeness Mar 29 '14 at 18:59

I suggest using Arch Linux.

I get normal booting time of 5s (kernel) + 5s (to userspace) and it doesn't require much effort, because it is using systemd for init.

share|improve this answer
@goldilocks, you can use systemd on raspbian too. It halved the boot time for me. –  John La Rooy Apr 2 '14 at 13:43
@JohnLaRooy Good to know. I was assuming the performance difference vs. traditional init would mostly be because systemd can parallelize, but it probably also saves time by not having to fork and interpret shell scripts for everything. –  goldilocks Apr 2 '14 at 14:55
@goldilocks I don't agree, I tried, and systemd makes much difference, compared to sysvinit. See my answer. –  Basj May 30 at 12:53
@Basj Even better to know. I've deleted my comment about it probably not making "much difference in terms of boot times since it is [on] a single core". I do mostly use systemd -- but TBH I do not pay much attention to boot times. –  goldilocks May 30 at 13:08

The optimal solution is probably to build a distribution that does only exactly what you want it to on boot, this way you're guaranteed minimal times (using a minimalist init system like sinit). Alternatively, you might consider using the suspend to disk (hibernation) feature of the Linux kernel. Once booted, the suspend and resume operations later on are pretty quick, and the system is entirely off in the meantime.

share|improve this answer

Use TinyCoreLinux. It's made for fast loading and to survive power failures.

share|improve this answer

I wrote an article here about it.

In short: use systemd.

You can easily get your RaspberryPi app running less than 8 seconds after you plugged the power cord, or less than 3 seconds after the Linux boot has started.

An example here, my service is called samplerbox.service:

enter image description here

Note: I haven't tried to optimize userspace time because I don't need it: my app starts early anyway, so I don't mind if the networking DHCP / IP attribution takes 8 seconds after my app has been launched.

share|improve this answer

Using a statically linked kernel instead of modprobing drivers can also dramatically increase performance. There are other optimizations to be made by carefully configuring and recompiling a kernel.

share|improve this answer

You could try to use eINIT to speed up the boot process: : http://sourceforge.net/projects/einit/

share|improve this answer
Welcome to Raspberry Pi! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. If you could include the important info from the link it would make your answer more useful and help keep this site/Q:A more useful in the future, as including this info protects against link rot. –  RPi Awesomeness Mar 29 '14 at 19:02

Remove any kernel modules that you won't use.

share|improve this answer
Answers on this site should include the steps needed to perform the suggested actions (how to determine what modules are loaded, which are needed and how to remove them), and references and links to further information. –  Steve Robillard Apr 2 '14 at 23:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.