30

I love my Pi, but it takes a considerable time to boot. If I want to use it as a Media Centre, it's quite important that it powers up quickly.

Are there any steps I can take to improve boot performance?

11
  • 9
    Leave it on? :P Commented Jun 15, 2012 at 7:45
  • That was my initial response, but other questions have made me think twice about doing this. Commented Jun 15, 2012 at 7:46
  • SD cards life is largely dependant on writes. Are they affected by leaving them on? Commented Jun 15, 2012 at 7:48
  • I have no idea how many disk writes an install performs while idle... Commented Jun 15, 2012 at 8:47
  • 1
    My Class 10 SD card has ~7MB/s while my external HDD has ~30MB/s Commented Jul 22, 2012 at 20:50

4 Answers 4

12

Certain things can be disabled that improve boot up speed - swap for instance (my Pi takes ages to activate it.)

However, SD card reads are comparatively slow, and the device itself isn't all that fast - I don't think there's a magic bullet to make it boot up that much faster than by default.

I know it's something you've considered already, but personally I would just leave it on. The two main reasons for not doing so appear to be stability (which could be solved by a cron job reboot every so often if it proves to be an issue at all) and SD card wear. While I don't have any figures on how quickly the latter will take place, there's things you can do to mitigate it (disabling swap) and for the price of SD cards, I'd be tempted to just see what happens. If it dies relatively quickly, you can revisit it and you've not thrown away that much. If it lasts for a couple of years or more (which I highly suspect may well be the case, though I have no benchmarks for that) I think £10 every few years is a rather low maintenance cost in the grand scheme of things.

As mentioned already the main thing that kills SD cards is lots of writes, and I can't think of anything that would really be doing that (or should be doing that) when the Pi is sitting idle.

2
  • 1
    I don't think stability is a problem - Linux machines are known to run for many months, often years, without rebooting. As for writes, there are a lot of log files in /var/log that will be regularly updated. The solution would be to disable logging, or mount /var/log as tmpfs (which uses system memory as temporary storage.) Commented Jul 14, 2012 at 6:51
  • What about battery powered applications, where leaving it on is a waste of resources? Commented Jun 25, 2017 at 2:35
4

If you are willing to switch to a whole new init system, I've found that using systemd allows the system to boot up considerably quicker, although I haven't done any benchmarks to give any real numbers.

3
  • Arch already uses systemd I believe. Commented Jul 14, 2012 at 20:14
  • I had to manually install it and switch to it explicitly. Commented Jul 15, 2012 at 1:00
  • For what it's worth, I just installed the proposed Arch version, it has systemd enabled by default. (For future reference, today's January 14th 2013). Commented Jan 14, 2013 at 23:28
0
  1. Leave it on (as berry120 said:)
  2. Make a bootchart to see what takes time, then eliminate where possible
  3. replace slow software with smaller/faster options
  4. maybe try readahead (or try disabling readahead if it was already on and doing harm)
0

A few suggestions: Strip SystemV at /etc/rc.sysinit

  • Remove RAID
  • Remove LVM(depends)
  • Remove BTRFS detection

or Use systemd

Parallel load the programs

Compile the kernel with hardfloat

If parts of your root partition are static use Squashfs noted in the wiki

E.g /usr /bin /sbin .. etc..

/etc/fstab

noatime,nodiratime,errors=remount-ro,data=writeback 

External SSD and HDD for the root partition

1
  • 1
    Could you perhaps explain how to make sections of the filesystem squashfs? That would make this answer much more useful, and is also the only thing I'm not already doing. Commented Jul 22, 2012 at 20:57

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.