Raspberry Pi: Tuning the Kernel – 0.3

For the 0.3 for my SBR600 project Tuning the Kernel, I planned to decide on a final kernel to release for the Raspi.

---

After the release of my 0.2 I was unsure of what I was I should change for this 0.3 release.

After conferring with Chris Tyler, I decided on changing the following from the stock kernel:

• SATA/PATA support – OFF
• PCI support – OFF
• USB Support – Modular

I then ensured both IPv6 and SeLinux was supported.

kernel.img (4.7M)

For those interested, here is the make configuration file I used for this kernel   .config

The file size difference of this kernel compared to the original stock kernel is 33KB, while it is a fair amount still leaves the file size as 4.7M

Raspberry Pi: Tuning the Kernel – 0.2

For the 0.2 of my Tuning the Kernel SBR600 project, I had planned to do some trimming of the kernel experimenting with different compilation options for the kernel.

Building a kernel using the make command with no menu options set, will build you a “stock” kernel as I had done in my previous post.

I learned that there are a few methods to go about altering the compilation options for a kernel:

make config

Using the config option, you are presented with a large list of questions that you must go through one by one to change the compilation options.

Support for paging of anonymous memory (swap) (SWAP) [Y/n/?]
System V IPC (SYSVIPC) [Y/n/?] Y
BSD Process Accounting (BSD_PROCESS_ACCT) [Y/n/?] Y
  BSD Process Accounting version 3 file format (BSD_PROCESS_ACCT_V3) [N/y/?] N
Export task/process statistics through netlink (EXPERIMENTAL) (TASKSTATS) [Y/n/?]
  Enable per-task delay accounting (EXPERIMENTAL) (TASK_DELAY_ACCT) [Y/n/?]

make menuconfig

Using the menuconfig option, you’re presented with a graphical ncurses GUI as seen below:

make xconfig

Using the xconfig option brings up an xwindows styled tool for enabling or disabling options.

I believe all methods accomplish the same task in this case, it’s a matter of which you’re more comfortable with (or what’s available to you(xconfig requires gtk+ and menuconfig requires ncurses)).

In my case, I stuck with the xconfig option as I find it easier to navigate with my mouse rather than my keyboard.

The next step is deciding what options to leave on and which can be deemed unnecessary and taken out. (which is the part I’m having most difficulty with).

That being said, I’ve created 2 kernels with some different options turned off on each:

kernel1

• removed Broadcom system support
• removed power management support
• removed misc drivers
• removed SCSI device support
• removed PID support – special HID devices (joysticks)

kernel2

• removed power management support
• removed networking support: (amature radio,CAN bus, IRDA, Bluetooth, Wimax, Plan9)
• removed SCSI device support
• removed PID support – special HID devices (joysticks)

For those interested in the .config files from which I created these two kernels, they can be found here.

Raspberry Pi: Tuning the Kernel – 0.1

My assignment for the class SBR600, is to build and tune the kernel for the Raspberry Pi device (The Raspberry Pi device is a tiny, inexpensive ARM microcomputer designed to use in educational environments), it involves optimizing the kernel to run as efficiently as possible on the Raspberry Pi.

The steps for compiling a custom kernel for the RaspPi looked fairly simply, in that there are surprisingly few! Those steps are as follows:

1. Retrieve kernel (Version 2.6.35.7)
2. Retrieve RaspPi kernel patch (RaspPi Patch)
3. Apply patch to the kernel
4. Add in DWC_otg folder
5. Make the zImage from the patched kernel
6. Run the python imagetool

I ran into problems while attempting to make the zImage of the kernel.

Upon running the command:

make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- zImage

I was greeted with the following error:

/bin/sh: arm-none-linux-gnueabi-gcc: command not found
 make[1]: *** [kernel/bounds.s] Error 127 

After a bit of research I learn I’m missing a toolchain required to utilize the gnueabi-gcc toolset for the make command. So I located and downloaded said toolchain (arm-2011.03-41-arm-none-linux-gnueabi.bin)

Running that toolchain installer I ran into yet another error:

Error: Missing 32-bit libraries on 64-bit Linux host

It seems that I require certain 32bit libraries in order to CROSS_COMPILE the RaspPi kernel.

With the direction of frojoe on the #seneca freenode channel I was directed to this MeeGo wiki page which details the installation of the toolchain:

mkdir -p ${HOME}/tmp
cd ${HOME}/tmp
wget -c https://sourcery.mentor.com/sgpp/lite/arm/portal/package4571/public/arm-none-linux-gnueabi/arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
mkdir -p ${HOME}/opt
tar -C ${HOME}/opt -vjxf arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
export PATH=${HOME}/opt/arm-2009q1/bin:${PATH}

After applying these fixes and re-running the make command I encountered this error:

/bin/sh: /home/nlambert/opt/arm-2009q1/bin/arm-none-linux-gnueabi-gcc: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

Some research lead me to yum install glibc.i686, which corrected this issue. Re-running the make command results in the building of the kernel to the zImage.

I then ran the python imagetool-uncompressed.py script and am greeted with a kernel.img(4.7mb) in the tools directory.

This is my first kernel for the RaspberryPi with stock settings.

Repositories and Distribution

Purpose:

The Purpose of this lab is to sign and create a repository in order to distribute my newly created and tested RPM file.

Signing:

To sign my RPM package first I have to generate a key. This is done using GPG.

gpg –gen-key

This application asks you a few questions including

• Type of key
• Key expiry
• Email address
• Name

After generating my key, I edit my ~/.rpmmacros file and add in the line:

%_gpg_name “nlambert@learn.senecac.on.ca”

Now I can sign my RPM with the newly generated key and then export the public key in to be used later :

rpm –addsign rpmbuild/RPMS/i686/spell-1.1-1.fc15.i686.rpm

gpg –export –armour nlambert@learn.senecac.on.ca > mygpg

Using root privileges I moved my exported key in to the /etc/pki/rpm-gpg directory:

mv /home/nick/mygpg /etc/pki/rpm-gpg/RPM-GPG-KEY-nlambertrepo

I then created a temporary directory to make my repository in and copied my RPM to it. From there I ran the “createrepo” command to generate the repo data folder.

mkdir temp
cp rpmbuild/RPMS/i686/spell-1.1-1.fc15.i686.rpm temp
cd temp/
createrepo .

I then copied the contents of the repodata folder and my source file to a web host (Matrix)

scp -r spell-1.1-1.fc15.i686.rpm repodata nlambert@matrix:~/public_html/myrepo

SSHing into my matrix account I moved the files into their proper places:

mkdir /public_html/www/myrepo/repodata
mv *.gz public_html/myrepo/repodata/
mv *.bz2 public_html/myrepo/repodata/
mv repomd.xml public_html/myrepo/repodata/
mv spell-1.1-1.fc15.i686.rpm public_html/myrepo/

Testing:

In order to test my newly signed and created repository, I copied one of the files in /etc/yum.repos.d in order to create my own.

cp /etc/yum.repos.d/fedora /fedora.repo etc/yum.repos.d/nlambert.repo

The contents of my custom repository file

1. [NLambert]
2. name= NLambert Repo
3. failovermethod=priority
4. baseurl=http://matrix.senecac.on.ca/~nlambert/myrepo
5. enabled=1
6. metadata_expire=7d
7. gpgcheck=1
8. gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-nlambertrepo

Line 1 is the listed name of the custom repository.

Line 4 is the location of my repository where the RPM may be downloaded from.

Line 5 enables the repo file for use when installing files.

Line 6 specifies when the client must update their version of this repo in order to check for new updates.

Line 7 specifies that the RPMs served from this repo are signed with a key.

Line 8 specifies that the public key to be used to verify the signing of the RPMs should be located in /etc/pki/rpm-gpg and named RPM-GPG-KEY-nlambertrepo

Using this file I am now able to install from my very own repository!

A method I used to check my custom repo was “rpm repolist” which displays all repositories which you may install/update from.

From here I’m able to install from my repository with the command “yum install spell”. Because my version of spell has a higher version number it is able to install it from my repository.

Repository Release:

In order to make my repo available to others I can package my repo file and my GPG key into an rpm of its own.

I have yet to do this but will be detailing my attempt at it in my next blog post.

 

My Repository

 

 

 

Mock and Koji

Purpose:

The purpose of this lab is to use and become familiar with the mock and koji tools.

Installation of Mock and Koji:

Mock: Mock is used to test the accuracy of the build dependances for RPMS. Alerting you if your package is missing any.

To get mock, I simply used YUM to grab and install it # yum install mock -y

I then have to add my user account to the mock users group # usermod -G

Koji: Is a build farm system which lets you test your build on different architectures that you might not have an access to.

Koji can be installed with a single step # yum install fedora-packager.

And then run /usr/bin/fedora-packager-setup  which creates the certificates to use Koji.

Using Mock:

In order to use mock, you need to have an SRPM built.

The syntax for using mock is # mock -r <configfile> <SRPMfile>

Here’s an example of one of the mock commands I used:

mock -r fedora-14-i386 rpmbuild/SRPMS/spell-1.1-1.fc15.src.rpm

The results of the mock command are sent to the /var/lib/distribution/result directory.

The distribution is determined by the distribution that was selected when the mock command was entered.

Here is an updated version of my RPM of spell : SPELL

Using Koji:

To build a package using Koji the command syntax is # koji  build dist-f14 –scratch rpmbuild/SRPMS/spell-1.1-1.fc15.src.rpm

The distribution to test the RPM on is F14(Fedora 14(32 and 64bit))

The RPM to be tested is spell-1.1-1.fc15.src.rpm

The –scratch specifies that the build is not committed to the fedora distribution.

Once the distribution has been uploaded to Koji, there will be a link which you can take to view the status of your build on Koji.

Here is one of mine : http://koji.fedoraproject.org/koji/taskinfo?taskID=3407241

The build is listed as closed because it has completed.

There is another method of tracking the status of your Koji build. By simply entering # koji watch-task taskID

Conclusion:

So, my first experience using Mock and Koji were interesting. It was fun to upload and queue my package to the Koji build farm and be able to watch as a host picks up the task and builds it for me.

RPM-Writing

In this lab my goal is to create an RPM package from source. Essentially the opposite of what I did in my previous blog post (Download and install an RPM package).

My first step was to ensure I had the required packages in order to perform the building commands.

[root@localhost tarBalls]# yum groupinstall “Fedora Packager” -y

Installed:
bodhi-client.noarch 0:0.8.0-1.fc15
bzr.i686 0:2.3.4-1.fc15
fedora-easy-karma.noarch 0:0-0.15.20110825git36efb338.fc15
fedora-packager.noarch 0:0.5.9.2-2.fc15
koji.noarch 0:1.6.0-2.fc15
mercurial.i686 0:1.9.1-1.fc15
mock.noarch 0:1.1.12-1.fc15
plague-client.noarch 0:0.4.5.8-2.fc15

Dependency Installed:
GitPython.noarch 0:0.2.0-0.6.beta1.fc15
fedora-cert.noarch 0:0.5.9.2-2.fc15
fedpkg.noarch 0:0.5.9.2-2.fc15
libyubikey.i686 0:1.7-1.fc15
pigz.i686 0:2.1.6-2.fc15
plague-common.noarch 0:0.4.5.8-2.fc15
python-bunch.noarch 0:1.0.0-3.fc15
python-decoratortools.noarch 0:1.8-2.fc15
python-enchant.i686 0:1.3.1-8.fc15
python-fedora.noarch 0:0.3.24-3.fc15
python-krbV.i686 0:1.0.90-4.fc15
python-magic.i686 0:5.07-4.fc15
python-offtrac.noarch 0:0.0.3-3.fc15
python-paramiko.noarch 0:1.7.7.1-1.fc15
rpmlint.noarch 0:1.2-1.fc15
ykpers.i686 0:1.4.1-1.fc15

Complete!,

[root@localhost tarBalls]# yum install rpmlint yum-utils -y
Loaded plugins: langpacks, presto, refresh-packagekit
Setting up Install Process
Package rpmlint-1.2-1.fc15.noarch already installed and latest version
Package yum-utils-1.1.31-2.fc15.noarch already installed and latest version
Nothing to do

After installation of those packages I have to create the build environment with ‘rpmbuild-setuptree’ which creates the ~/rpmbuild and ~/.rpmmacros directories.

Now I’m able to begin the actual package building. I copy the previously downloaded tarballs to the ~/rpmbuild/SOURCES directory.

I move to the ~/rpmbuild/SPECS directory and create a new spec file for my tarball:

[root@localhost SPECS]# rpmdev-newspec spell-1.1

Now I edit the spell.spec file and fill in the meta data

Here’s a snippet of my spell.spec file:

Name:           spell
Version:        1.1
Release:        1%{?dist}
Summary:        Linguistics checking program

License:        GPLv3+
URL:            http://savannah.gnu.org/projects/spell/
Source0:        http://ftp.gnu.org/gnu/spell/spell-1.1.tar.gz

#BuildRequires:
#Requires:
BuildArchitectures: noarch

%description
A spell checking program which prints each misspelled word on a new line.

%prep
%setup -q

%build
%configure
make %{?_smp_mflags}

%install
#rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT

%files
%doc README COPYING INSTALL

%changelog
* Fri Sep 23 2011 Nick Lambert <nlambert@learn.senecac.on.ca> – 1.1-1
– Built source as an RPM.

Some issues I had while altering this spec file were:

• The summary could not contain the name of the program itself, so I opted to call it a “Linguistics checking program”.
• I originally entered GPLv2 as the license which I learned was incorrect. I promptly changed that to GPLv3+.
• My first build attempt failed because of the following error: “find: `/root/rpmbuild/BUILDROOT/spell-1.1-1.fc15.i386′: No such file or directory” To remedy this I simply commented out the “#rm -rf $RPM_BUILD_ROOT” line thus ensuring that directory would exist. I’m not certain if this was the correct way to correct this error, though it did work..

Next I moved to testing with rpmlint:

My first test with rpmlint returned with some errors and warnings

[root@localhost SPECS]# rpmlint ../SRPMS/spell-1.1-1.fc15.src.rpm
spell.src: E: no-changelogname-tag
1 packages and 0 specfiles checked; 1 errors, 0 warnings.

To fix this I added the %changelog section to my spec file and then re-built it.

Running rpmlint on the SRPM file returns no warnings..

Running rpmlint on the RPMS file returned 1 warning:

[root@localhost SPECS]# rpmlint ../RPMS/noarch/spell-1.1-1.fc15.noarch.rpm
spell.noarch: W: no-documentation
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

To remedy this, I added the documation portion to the spec file.

 

To download my SRPMS of spell go here: http://matrix.senecac.on.ca/~nlambert/spell-1.1-1.fc15.noarch.rpm

To download my RPMS of spell go here: http://matrix.senecac.on.ca/~nlambert/spell-1.1-1.fc15.src.rpm

 

Built From Source

The purpose of the Build from Source lab is to become familiar with the building from source process and to create a basis on which the subsequent labs will build upon.

The two pieces of software I have chosen to work with are:

Spell and GNUmp3d

Here’s a snippet of the downloaded tarballs:

[nick@localhost tarBalls]$ ls
gnump3d-3.0.tar.gz  spell-1.1.tar.gz

Here are the unpackaged( using tar -zxf) tarballs:

[nick@localhost tarBalls]$ tar zxf gnump3d-3.0.tar.gz
[nick@localhost tarBalls]$ tar zxf spell-1.1.tar.gz
[nick@localhost tarBalls]$ ls
gnump3d-3.0  gnump3d-3.0.tar.gz  spell-1.1  spell-1.1.tar.gz

After unpacking the tarballs, I then decended into the newly created subdirectories(1 for each application) and installed each program.

GNUmp3d only requires a working Perl installation therefore I didn’t need to run ./configure in order to configure the installation for my system.

Spell on the other hand needed to be configured:

[root@localhost spell-1.1]# ./configure
checking for gcc… gcc
checking whether the C compiler works… yes
checking for C compiler default output file name… a.out
checking for suffix of executables…
checking whether we are cross compiling… no
checking for suffix of object files… o

…

After configuration just a simple ‘make && make install’ to complete the installation of each program.

Here are the two programs run with the help options:

[root@localhost spell-1.1]# spell -h
Usage: spell [OPTION]… [FILE]…
This is GNU Spell, a Unix spell emulator.

-I, –ispell-version        Print Ispell’s version.
-V, –version            Print the version number.
-b, –british            Use the British dictionary.
-d, –dictionary=FILE        Use FILE to look up words.
-h, –help            Print a summary of the options.
-i, –ispell=PROGRAM        Calls PROGRAM as Ispell.
-l, –all-chains        Ignored; for compatibility.
-n, –number            Print line numbers before lines.
-o, –print-file-name        Print file names before lines.
-s, –stop-list=FILE        Ignored; for compatibility.
-v, –verbose            Print words not literally found.
-x, –print-stems        Ignored; for compatibility.

Please use Info to read more (type `info spell’).
Report bugs to: cate@gnu.org
spell home page: <http://www.gnu.org/software/spell/&gt;
General help using GNU software: <http://www.gnu.org/gethelp/&gt;

[root@localhost spell-1.1]# gnump3d -h
GNUMP3d v3.0 (Perl v5.012004) – A portable(ish) MP3/OGG/HTTP streaming server.
– See http://www.gnump3d.org/ for more details.

Usage: gnump3d [options]

–background            Detatch from the console after starting.
–config filename       Read options from the named configuration file.
–debug                 Dump debug output to the console, not the error log.
–dump-plugins          Display all plugins that have been found.
–fast                  Start quickly without indexing the audio files first.
–help                  Display this usage information.
–lang XX               Load the strings from the given language file.
–plugin-dir directory  Load the plugins from the given directory.
–port number           Listen and serve upon the given port number.
–quiet                 Do not display the startup banner.
–root directory        Serve music from the given directory.
–test                  Allow config variables to come from the environment.
–theme-dir directory   Load the theme files from the given directory.
–version               Displays the version of this software.

Report bugs to : Steve Kemp <steve@steve.org.uk>

SBR Introduction!

HELLO WORLD

My name is Nicholas Lambert, I’m in my final semester at Seneca College’s CTY program. One of of my courses this semester is SBR600(Software build and release) where I’m going to learn about the building (compiling, testing, and packaging) of software. I’m looking forward to working directly with the Fedora Project especially getting to tinker with the ARM processors.

This is my very first time writing a blog and I must say that it’s certainly feels weird to put my thoughts and opinions on a page for the whole world to see… I don’t know if I’ll ever feel comfortable doing so.

Here are some links to various profiles of mine on other websites:

CDOT: Nlambert

Fedora Project: Nlambert

And here is a fun desktop background I had not too long ago: BlueOrange