0.3 Raspberry Pi Startup

Okay, first of I am going to mention that this is my 4th attempt posting this entry! WordPress, for some unknown reason , continues to erase my posts…so please bare with me as this post doesn’t appear as nice as I would like it to.  Anyways…for my 0.3 I had planned on testing all of the tools and utilities that I was experimenting with in my 0.2 release except this time I wanted to test them on the actual Raspberry PI device itself.

First, I should mention, that before it came to testing, I wanted to create my own partition on the Raspberry Pi, that way if I messed something up it would just be my partition that crashes and the whole system.  It’s fairly simple to create a partition so I looked at Chris’s instructions here which guide you on how to create a partition for the Raspberry Pi.  Unfortunately, I was unsuccessful in doing this.  For some reason whenever I would try to reboot the device with cmdline.txt pointing to my partition (dev/sda6) the device wouldn’t boot.  The SD card wouldn’t get initialized. I tried to do this 4-5 times and was unsuccessful every time. After speaking with Chris, he suggested that I use the default partition on the device and hopefully I wouldn’t do anything drastic to hurt it, which I didn’t.

The first utility I wanted to try on the Raspberry Pi was the hdparm command. The Raspberry Pi located at Seneca CDOT has a USB external hard drive connected to it, this is where most of the information s stored allowing for the SD card to have less information on it.  I wanted to see if I could speed up the hard drive speed with hdparm. Below are the sets of commands that I used.

Get drive information: hdparm /dev/sda
Gather more information: hdparm –I /dev/sda
Test the Speed: hdparm –d1 –c3 –u1 /dev/sda

NOTE: The below command did not complete successfully.
Increase the Speed: hdparm –d1 –c3 –u1 /dev/sda

After trying the above commands I realized that this drive is fairly new and it’s already at the fastest speed at which it can operate.

After realizing that the hard drive could not be optimized I decided that I should enable the readahead service to see if it makes a difference.  On most Fedora machines readahead is installed by default.  However since the Raspberry Pi has a custom kernel I had to install it manually using YUM.  After installing there isn’t much initial configuration. The configuration file is located in /etc/readahead/readahead.conf. After inspecting the configuration file, add the following line to /boot/cmdline.txt or grub.conf:

init=/sbin/readahead-collector

The above command will enable the readaheadservice to start at boot.

 After entering the command I rebooted the machine and this is what I got:

The picture is a bit blurry so I’ll explain what it says below:

****** Readahead Collector Started ******
Readahead-collector: cannot insert audit rules
init: readahead-collector main process (536) terminated with status 1

Essentially what’s its saying is that it cannot find the audit daemon.  The reason why is because audit wasn’t built into the kernel resulting in readahead not being able to start or work at all.  After doing some troubleshooting with Chris he helped me determine that a new kernel needs to be built that supports audit that way readahead can start.  Unfortunately there wasn’t enough time left in the semester for me to try a different kernel that supports readahead.

With time running out and my 0.3 deadline fast approaching, I figured that there has to be something I can do on this device to make it boot a little bit quicker.  So I took another look at the current services running and determined that a few more services could be turned off.  Those services were: gpm, pcscd, avahi-daemon and udev-post.  I disabled these services for run level 3 and it is booted normally without any errors.  Below is a list of the services that are currently enabled on the Raspberry PI located at Seneca CDOT.

avahi-daemon        3:off
cups                3:off
gpm                 3:off
haldaemon           3:on
httpd               3:off
iptables            3:on
lvm2-monitor        3:off
mdmonitor           3:off
messagebus          3:on 
netconsole          3:off
netfs               3:off 
network             3:on
ntpd                3:on 
ntpdate             3:off
pcscd               3:off
portreserve         3:off
rdisc               3:off
rsyslog             3:off
saslauthd           3:off
sshd                3:on
svnserve            3:off
udev-post           3:off

As you can see there are only six enabled services on this device. It takes approximately 22.6 seconds for these services to boot; however this doesn’t include the initial boot that initialize the SD card and loads the modules.  For the SD card to initialize and load the modules it takes about 18.3 seconds.  Ive also seen it take as long as 25 seconds. The reason being that the Raspberry PI has a couple of modules that fail on the startup, during the boot it tries to load the modules which takes a lot of time this is why the device doesn’t boot that fast.

In order for the Raspberry PI to have a quick startup then it needs to be able to successfully load every module. This is what’s taking the longest to load, after the failed modules it takes 22.6 seconds to load the services.  Technically, if everything is loading properly it should take the device approximately 25-30 seconds to boot instead of the 36-40 seconds that it takes now. Keep in mind this isn’t incorporating readahead or any other utilities.  If the device had readahead enabled I would say that the device would boot in at least 25 seconds.  Below is a list of some of the deficiencies I’ve noticed when using the device. Some can be fixed while others will have to remain the same.

Deficiencies

As mentioned previously when device is first powered on it takes 18.3 seconds to initialize the SD card, load the modules and display errors.  However this time varies. I have seen it take 25 seconds to initialize the SD card. This should not take this long; no modules should be failing.

Services Deficiencies:

– To mount the USB external hard drive takes at least 5 seconds
– Takes 5 seconds to mount /swap files
– Takes 4 seconds for the haldaemon to start
To sum it all up I would say that with the current kernel that is configured on the Raspberry PI that this is the fastest speed it can get.  However if the errors are fixed at the beginning of the boot i.e. (failed modules etc…) I would definitely say that the boot could go from 36 seconds to at least 25 seconds.

With a new kernel that supports auditd & readahead, I would definitely think that the device should easily be able to boot in about 20 – 22 seconds.

You may ask where I am getting all of these boot estimations from. In my 0.1 post I mentioned that I wanted my goal to be getting the device to boot in 15 seconds.  While I couldn’t meet that goal for reasons beyond my control (failed modules, kernel issues) I figured that I should make a virtual machine with the same specs and the PI. I did this in my 0.2 I was able to make a virtual machine that just had the same services running as the PI in 11.6 seconds; you can watch that video here.

I have done more work to that virtual machine. I disabled more services that I mentioned earlier in my post; enabled readahead speed up the disk with hdparm mounted some file systems temporarily and before you knew it I had my virtual machine booting in 6.9 seconds! I definitely didn’t expect it to boot that quick.  Below is a video of the boot:

6.9 Second Boot video

These are the services running on the virtual machine, the exact same as the Raspberry PI located at Seneca CDOT.

These are the file systems I mounted as tmpfs.

I’m currently working on a bash script that will turn off all unneeded services and enable readahead.The reason why I haven’t uploaded it yet is because I know that everyone’s system is setup differently and I didn’t want to create something that’s going to harm or potentially crash your system. I want the script to be as efficient as possible without harming your system.  The script will be uploaded sometime next week.

Overall I actually loved experimenting and doing the work for Software Build and release.  This project was very interesting to me and lead me to learn a lot of new techniques and concepts. I definitely didn’t expect to find myself creating a virtual machined boot in 6.9 seconds, that’s for sure.  It also felt good actually working on a device that hasn’t even been fully released yet.  Now I can say that I know all about the Raspberry PI Foundation  and that I helped make it boot more efficiently and faster.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s