A while ago I registered with flattr. I found the idea of encouraging people to give kudos to people who do something on the web easily and meaningfully, by attaching a little bit of money to it. I had planned to use my flattr account only as a kudos-forwarder: All funds that I get by being flattred would be spend on flattering things that I like. At that time, flattr did not allow me registering my things without first uploading money, so I did not use my account. But recently, they changed this policy, so I added a few of my projects to the list of things people can now flattr:

• This blog (flattr it)
• My LaTeX wiki engine latexki (flattr it)
• The German lecture script wiki Mitschriebwiki that it runs (flattr it)
• The web-version of screen-message (flattr it)
• The pornyness calculator (flattr it)

I almost always use the less intrusive text links. I fear that this means that people have to do an extra click before the have flattred the thing, but I still prefer it this way. Also, I do not use the automatic addition of things for each blog post, on the one hand because that does not seem to work with text links, and on the other hand because I don t think that each post is worth to be flattred. Generally, I avoid such closed-source walled-garden online services. I guess I make an exception this time because it is not a service that I run the risk of becoming dependent on. Flattr makes money per things flattered. It would be nicer if they only charged when people actually withdraw cash from their account, this way, many more people could do forward-only flattering for free, making many other people happy and appreciated, while still eventually making money.

Flattr this post

So as Alpha 2 approaches, I find myself working towards porting the alternate installer/d-i to the pandaboard to support the netboot installer. There's not a lot of documentation that describes the internals of d-i, nor what bits are platform specific.

This is especially true when working towards creating a new subarchitecture since lots of little places have to be touched, kernels usually have to be tweaked, and all other sorts of odds and ins. This post isn't a comprehensive guide to what's necessary, but just little tidbits of what I did, just some random odds and ends.

The first step of any enablement is to have something you can run and boot. The netboot images, as well as the alternate kernel and ramdisk are built out of the debian-installer package. In the debian-installer package, several config files for driving the process are located in build/config/$arch/$subarch. For omap4, we have the following files:

boot/arm/generate-partitioned-filesystem
build/config/armel.cfg
build/config/armel/omap4.cfg
build/config/armel/omap4/cdrom.cfg
build/config/armel/omap4/netboot.cfg

boot/arm/generate-partitioned-filesystem is a shell script that takes a VFAT blob, and spits out a proper MBR and partition table.

build/config/armel.cfg simply is a list subarchitectures to build, and some sane-ish kernel defaults for armel.

build/config/armel/omap4.cfg is also a simple config file which specifies the type of images we're building, and the kernel to use in d-i. This file looks like this:

MEDIUM_SUPPORTED = netboot cdrom

# The version of the kernel to use.
KERNELVERSION := 2.6.38-1309-omap4
# we use non-versioned filenames in the omap kernel udeb
KERNELNAME = vmlinuz
VERSIONED_SYSTEM_MAP =

As a point of clarification, 'cdrom' is a bit of a misdemeanor; it refers to the alternate installer kernel and ramdisk used by alternate images, and not the type of media. Other types of images exist such as 'floppy' and 'hd-install', but these are specialized images, and out of scope for this blog post.

Each file in build/config/armel/omap4/* is a makefile thats called in turn for each image that created. The most interesting of this is the netboot.cfg

MEDIA_TYPE = netboot image
SUBARCH = omap4
TARGET = $(TEMP_INITRD) $(TEMP_KERNEL) omap4
EXTRANAME = $(MEDIUM)
INITRD_FS = initramfs

MANIFEST-INITRD = "netboot initrd"
MANIFEST-KERNEL = "kernel image to netboot"
INSTALL_PATH = $(SOME_DEST)/$(EXTRANAME)

omap4:
 # Make sure our build envrionment is clean
 rm -rf $(INSTALL_PATH)
 mkdir -p $(INSTALL_PATH)

 # Generate uImage/uInitrd
 mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Ubuntu kernel" -d $(TEMP_KERNEL) $(INSTALL_PATH)/uImage
 mkimage -A arm -O linux -T ramdisk -C none -a 0x0 -e 0x0 -n "debian-installer ramdisk" -d $(TEMP_INITRD) $(INSTALL_PATH)/uInitrd

 # Generate boot.scrs
 mkimage -A arm -T script -C none -n "Ubuntu boot script (serial)" -d boot/arm/boot.script-omap4-serial $(INSTALL_PATH)/boot.scr-serial
 mkimage -A arm -T script -C none -n "Ubuntu boot script (framebuffer)" -d boot/arm/boot.script-omap4-fb $(INSTALL_PATH)/boot.scr-fb

 # Create DD'able filesystems
 mkdosfs -C $(INSTALL_PATH)/boot.img-fat-serial 10240
 mcopy -i $(INSTALL_PATH)/boot.img-fat-serial $(INSTALL_PATH)/uImage ::uImage
 mcopy -i $(INSTALL_PATH)/boot.img-fat-serial $(INSTALL_PATH)/uInitrd ::uInitrd
 mcopy -i $(INSTALL_PATH)/boot.img-fat-serial /usr/lib/x-loader/omap4430panda/MLO ::MLO
 mcopy -i $(INSTALL_PATH)/boot.img-fat-serial /usr/lib/u-boot/omap4_panda/u-boot.bin ::u-boot.bin
 cp $(INSTALL_PATH)/boot.img-fat-serial $(INSTALL_PATH)/boot.img-fat-fb
 mcopy -i $(INSTALL_PATH)/boot.img-fat-serial $(INSTALL_PATH)/boot.scr-serial ::boot.scr
 mcopy -i $(INSTALL_PATH)/boot.img-fat-fb $(INSTALL_PATH)/boot.scr-fb ::boot.scr
 boot/arm/generate-partitioned-filesystem $(INSTALL_PATH)/boot.img-fat-fb $(INSTALL_PATH)/boot.img-fb
 boot/arm/generate-partitioned-filesystem $(INSTALL_PATH)/boot.img-fat-serial $(INSTALL_PATH)/boot.img-serial

 # Generate manifests
 update-manifest $(INSTALL_PATH)/uImage "Linux kernel for OMAP Boards"
 update-manifest $(INSTALL_PATH)/uInitrd "initrd for OMAP Boards"
 update-manifest $(INSTALL_PATH)/boot.scr-fb "Boot script for booting OMAP netinstall initrd and kernel from SD card. Uses framebuffer display"
 update-manifest $(INSTALL_PATH)/boot.scr-serial "Boot script for booting OMAP netinstall initrd and kernel from SD card. Uses serial output"
 update-manifest $(INSTALL_PATH)/boot.img-serial "Boot image for booting OMAP netinstall. Uses serial output"
 update-manifest $(INSTALL_PATH)/boot.img-fb "Boot image for booting OMAP netinstall. Uses framebuffer output"

The vast majority of this is fairly straightforward. TARGET represents the targets called by make. There are tasks for creating a vmlinuz and initrd that must be included. The omap4 target then handles specialized handling for the omap4/netboot image.

omap4 requires a VFAT boot partition on the SD card with a proper filesystem and MBR. The contents of the filesystem are straightforward:

MLO - also known as x-loader, a first stage bootloader
u-boot.bin - u-boot binary, second stage bootloader, used to book the kernel
uImage - linux kernel with special uboot header (created with mkimage)
uInitrd - d-i ramdisk with special uboot header
boot.scr - special boot script for u-boot for commands to execute at startup.

MLO and u-boot.bin are copied in from x-loader-omap4-panda and u-boot-linaro-omap4-panda which are listed as build-deps in the control file for d-i. boot.scr is generated from a plain-text file:

fatload mmc 0:1 0x80000000 uImage
fatload mmc 0:1 0x81600000 uInitrd
setenv bootargs vram=32M mem=456M@0x80000000 mem=512M@0xA0000000 fixrtc quiet debian-installer/framebuffer=false console=ttyO2,115200n8
bootm 0x80000000 0x81600000

These are u-boot commands that simply load the uImage/uInitrd into RAM, set the command line, and then boot into it.

When porting the installer, it is mostly a task of putting your subarchitecture name in the right places, then adding the necessary logic in places to spit out an image that boots. This provides a sane base to start working on porting other bits of the installer. When d-i is uploaded to Launchpad, these files end up in http://ports.ubuntu.com/ubuntu-ports/dists/oneiric/main/installer-armel/current/images/

My next blog post will go a bit into udebs, and understanding how d-i does architecture detection, and introducing flash-kernel.

TED has published a list of resources for suicide prevention and to help survivors and their families [1]. Psychology Today has an interesting article by Paula J. Caplan, Ph.D about the recent US Supreme Court decision denying female employees of Walmart the ability to file a class action lawsuit about their poor pay and working conditions [2]. She describes the problem as a focus on rights of the ruling class vs fairness to the workers, it could also be described as prioritising perceived rights of the rich over the rights of workers to fair treatment. It seems to me that her article has relevance to some of the discussions related to the treatment of women in the Free Software community. New Scientist has an interesting article by Ferris Jabr about the use of MRI to discover brain-wave patterns correlated with Autism in sleeping toddlers [3]. This doesn t seem likely to be useful for scanning the entire population as it currently has a false-positive rate of 7/43 (which would make false-positives outnumber true-positives by about 15:1). But it does seem likely to do some good in identifying young children who might be on the Autism Spectrum. Shea Hembry gave an amusing TED talk about how he created art works for 100 fictional artists for his own exhibition [4]. He created a biography for each artist and every one had a unique style of art. Steve Keil gave a passionate TED talk about the benefits of play for children and for adults [5]. He focussed on the benefits for Bulgaria (where his talk was given) but it all applies to all humans. Frederic Bastiat s 1850 essays on economics are interesting, informatice, and well written [6]. Some of the themes such as the supposed economic benefits of maintaining a large army are the subject of political debate today. Paula J. Caplan, Ph.D wrote an insightful article for Psychology Today about the recent US supreme court decision in regard to the Wal-mart case [7]. Her article seems to have some obvious parallels to the situation in the FOSS community. The idea of rights vs fairness, beliefs that are unconscious or unexamined, and the comparison of attitudes towards racial vs sexual discrimination (in terms of not treating sexual discrimination and harassment seriously) seem to all apply clearly. Al Jazeera reports that the Fukushima disaster is worse than is reported in the mainstream western press [8]. Generally I wouldn t be inclined to trust al Jazeera if other news sources were reliable. But unfortunately reliable news related to contentious issues such as nuclear power is quite rare. It will probably be quite a long time before we can be confident that we know much about Fukushima, everyone who knows seems to be lying.

• [1] http://blog.ted.com/2011/06/11/resources-for-suicide-prevention-post-attempt-survivors-and-their-families/
• [2] http://www.psychologytoday.com/blog/science-isnt-golden/201106/americans-fail-take-sexism-seriously-the-supreme-courts-wal-mart-rul
• [3] http://www.newscientist.com/blogs/shortsharpscience/2011/06/brain-out-of-sync-in-toddlers.html
• [4] http://www.ted.com/talks/shea_hembrey_how_i_became_100_artists.html
• [5] http://www.ted.com/talks/steve_keil_a_manifesto_for_play_for_bulgaria_and_beyond.html
• [6] http://bastiat.org/en/twisatwins.html
• [7] http://www.psychologytoday.com/blog/science-isnt-golden/201106/americans-fail-take-sexism-seriously-the-supreme-courts-wal-mart-rul
• [8] http://english.aljazeera.net/indepth/features/2011/06/201161664828302638.html

I often get requests of persons who would like to contribute to Debian but who don t know where to start. Let s try to answer this question properly so that I can give out this URL the next time that I am asked. The Debian website has a page explaining how to help Debian. While it provides no less than 10 suggestions in a daunting text-only list, it s difficult to know what to do next once you picked up something that you could do. I will try to fix this by providing concrete information for each cases in upcoming articles but in the mean time I propose you another approach to start with. Before answering your question ( what can I do for Debian ), we need to know some information about you. What motivates you? You re a volunteer, you re not doing stuff for Debian because someone told you so. You must have some intrinsic motivation and the ultimate motivation is usually that you re enjoying what you re doing. So what are you enjoying and/or what are your motivations ?

• Is there something that you would like to learn? A new programming language? Packaging? Coding? System administration? A specific software?
• Do you want to interact with smart people?
• Do you like to help users?
• Do you like to fix software just so that it works for you?
• Do you like to build something remarkable and useful for millions of people?

On the opposite, make sure to know what you hate and what you want to stay far away from. Maybe you dislike a programming language so much that you don t want to be involved in a project where you would have to use it, etc. Write down the answers to the questions, you might need them later when you ll ask other Debian contributors how you can help. What are your skills? If you re not interested in learning new skills, then you must obviously select a task where your current skills are sufficient. Again make a list of your skills and in particular of skills that you d like to practice! Here s a non-exhaustive list of skills to consider:

• What languages are you fluent with? Are you confident to write documentation or translate documentation in those languages?
• Are you a programmer? If yes, which languages do you know?
• Can you diagnose problems? Can you debug problems with strace and/or gdb?
• Can you triage bugs?
• Do you know some Debian packaging?
• Are you an artist and/or a web designer?
• Do you know how to work with VCS (subversion, git, bzr, )?

How much time can you spend on Debian? This is the last important information that you need to communicate whenever you re asking someone else what you could do for Debian. There s no point giving you a big task if you can only spend 30 minutes every week. On the opposite if you can work on Debian full time during a week (because you re between 2 contracts or because you re in vacation), it s equally important to know. In general contributing to Debian requires time, you should be ready to spend at least several hours per week and possibly more at the start while you re learning everything. Find something to do At this point you have a generic idea of what you d like to do but you re still missing a concrete objective. Let s try to find one, we ll explore several ways to do this. Scratch your itch The best objectives are those that satisfy your own needs. Here are some examples:

• Did you notice a missing feature? Try to implement it.
• Have you been annoyed by a bug? Try to fix it.
• Did you lose too much time on something because there was no documentation? Write the missing documentation and submit it where appropriate.
• File bug reports for the things that you can t fix yourself. Even wishlist bug reports for new features.
• Do you use software that are not packaged for Debian? Create the package(s) and maintain it/them.
• Do you need a newer version of a package compared to what s in Debian unstable? Contact the maintainer and propose your help to update the package.
• Do you need a newer version of a package compared to what s in Debian stable? Contact the maintainer and propose your help to create a backport.

If you re a good Debian citizen, you have already filed bugs for issues that bugged you. Then you can browse http://bugs.debian.org/from:hertzog@debian.org to find out some ideas of stuff to do (obviously replace hertzog@debian.org by your own email address). Join a team If you don t have a specific itch to scratch, you might want to focus your work on a specific team. Head over to wiki.debian.org/Teams and browse the list of teams. You ll surely find one that works in an area that you like. If you select a packaging team, pick one that works on packages that you re actually using. Some of the teams have instructions for newcomers, follow them when that is the case. Otherwise join the mailing list and the IRC channel, and get a feel of how the team works. See if it suits you, you can follow several teams at the same time and pick the one that you prefer after a few days/weeks. Once you have lurked a bit, if you still don t know how you could help, then just ask on the mailing list. Include all the answers you have collected to the 3 questions on your motivations, your skills and your time available. Focus on a specific package You can concentrate your work on a specific package even if you re in a team, it s often a good idea. But I list it separately because not all packages are team maintained and you might want to help maintain a package where there s a single maintainer currently. I leave it up to you to find a way to select a package that interests you Then head over to the package tracking system: http://packages.qa.debian.org/dpkg (replace dpkg by the name of the package that interests you) Fill in the form in the bottom-left corner with your email and select opts in the drop-down list, then click go . You get a new form where you can select the information that you ll receive, I recommend you to keep everything except upload-binary and to validate the form. From now on, you get the same mails than the maintainer (and a bit more actually), and it s a good idea to inform the maintainer that you subscribed and that you re going to help a bit. Maybe he s willing to grant you commit rights immediately, maybe he will ask you to send patches for a start. The important thing is to create a good relationship. In any case (even if you did not get any answer from the maintainer), you should be free to help triage existing bugs and to help deal with the flow of incoming bugs (including forwarding bugs when appropriate). Help a Debian developer Paul Tagliamonte once blogged Hey, DDs, need help?. He offered his help to overworked Debian developers . His post was missing all the information required (cf motivations/skills/time) but the approach is a good one. The best way to start contributing is to work with existing Debian developers. Even if you just want to be sponsored for your own pet package, you should consider that mentoring is a burden for many Debian developers and that you re more likely to get a sponsor if you have an existing relationship with a Debian developer that you helped. Pick a developer that works in an area that is of interest, and offer him your help. To simplify things even further, I have created a wiki page where you can find out how you can help me and thus build a relationship with me. That s it for now, I hope this article will help you to start contributing. Don t forget to subscribe to my newsletter to not miss future articles for new contributors. Note that you can refer to this article with the following URL: http://raphaelhertzog.com/go/contributing/ (easier to type and remember).

13 comments Liked this article? Click here. My blog is Flattr-enabled.

Today I was made aware of bug #607839, and it makes me sad. I think its a great example about how trademarks and free software do not coexist well together. This bug started out as a question of the copyright license of a file, but quickly turned into a discussion about the GNOME [0] trademark, and the GNOME Foundation Trademark Usage Guidelines for Third Parties I believe that the GNOME project would be standing on solid legal ground if they wanted to actually try to aggressively protect their trademark. It is easy for me to find hundreds of places we use their mark in ways that are expressly forbidden by their trademark license. Here are some examples:

grep -i "gnome's" /var/lib/dpkg/available  # many package descriptions invalidly using a possessive
grep -i "gnome[^ ]" /var/lib/dpkg/availabe # returns nothing, trademark symbol is required

Probably to be in strict compliance, we would need to allow uppercase letters in package names. (I doubt this would happen, especially not for a reason like this). I am sure that a lawyer would tell us that the safest legal place for Debian would be to abandon all use of their marks. This would unfortunately be a herculean effort on Debian's part; we'd have to rename tons of packages, create and maintain tons of patches, create new logos, etc. And, I believe it would have the unfortunate side-effect of having a negative impact on both projects from a publicity standpoint. As with the firefox/iceweasel situation, the company trying to protect its trademark looks like a bully, and Debian looks like out-of-touch zealots. From the tone of the conversation in the bug report, I do not believe that this is something that the GNOME Foundation would force on us, and I certainly don't believe it would be an outcome they would hope for. They could give us written permission to use their marks in the ways we are already using them, however, lots of people would point at DFSG#8, and this would fail the 'tentacles of evil' test. (We are, of course, already under the grasp of these tentacles, as their current trademark license is subject to change) Better for us would be if they modified their trademark license agreement in order to allow our current usages of their mark. I feel that this quite unlikely to happen. It would certainly weaken their hold on the mark. Trying to apply the DFSG in these situations also doesn't work as well as it should. The DFSG is written with copyrights in mind and not patents and trademarks. This feels to me similar to situations we have with patent encumbered software which is under a perfectly free license. We can distribute the software without fear of a claim that we are violating copyrights, but the software is still not perfectly free since as I user, my rights to use and distribute the software might be severely limited from a legal standpoint. Also by Debian choosing to distribute software which has these kinds of potential problems, we might be putting a legal liability on members of the project and people that run mirrors for us. Of course, to add to the conflict I feel, Debian has its own trademarks, which it is poor at enforcing. On one hand, its bad for all the reasons that this situation is bad. On the other hand I sometimes wish that Debian did a better job of protecting its own trademark. It's clear from how many people show up in #debian expecting support for linuxmint or aptosid claiming "linux mint debian edition IS Debian, it says so on linuxmint.org" that we have allowed our mark to be diluted. NOTE: I became aware of this bug because of Zack CCing the FTP team. I serve on this team as an assistant, however, My comments here come from me personally without any discussion with other members of FTP team and should not be taken as any kind of offical word from the FTP team. [0] I suddently feel compelled to mention that The GNOME name is a registered trademark of GNOME Foundation in the United States or other countries.

While some folk look down on fakeraid (that is BIOS based RAID-until-OS-takes-over) solutions, I think they are pretty neat: they let a user get many of the benefits of dedicated controller cards at a fraction of the cost. The benefits include the usual ones for RAID more spindles to handle IO, tolerance of disk failures. And unlike pure LVM solutions, you can boot from a degraded RAID 1 / 5 / 10 set because the BIOS knows how. In some ways this is better than dedicated cards, because we have the software take over, so we can change the algorithms for IO dispatch all the way down to the individual devices However, these RAID volumes are in a pretty awkward spot for installers and bootloaders: inside a running Linux environment they look like software RAID which cannot be depended on for booting, but at boot time they look like hard disks which cannot be looked under the hood. I recently got a new desktop machine which has one of these motherboards, and fortuitously my old desktop I was replacing had the same size disks so I had 4 disks and the option of using a RAID setup. Apparently I m a sucker for punishment because I went for a RAID 10 (that is two RAID volumes made up of two-disk mirrors (the RAID 1 component), and then those two volumes are combined via striping (the RAID 0 component). This has the potential for pretty nice performance: in principle any read can come from one of 2 disks, and every 64KB (the stripe size) of linear data will switch to the other mirror set, giving a nice boost. Writes need to write to 2 disks always, but every 64KB worth of data will alternate mirror sets, also giving a boost. Sadly we (Ubuntu) aren t ready for this yet: there are two key bugs that make this layout almost impossible to install into. This blog post is for my exo-memory, I want to be able to figure out what I did next time around . Firstly parted_devices, a helper used by Ubiquity and debian-installer to determine which block devices are actually disk drives that one can partition and install onto, has a confused heuristic when dealing with dmraid it looks for devices which are not layered on other dmraid devices. This handily excludes partitions, but has the undesirable effect of excluding that striped device because it is layered on the two mirrored devices. Bug 560748 was filed about that, and I ve added a workaround to it basically disabling the filtering, so its not suitable as a long term fix, but it will let one select the RAID volume correctly. Secondly, grub2, which needs to figure out what the name at boot time of the RAID volume will be currently gets confused. I don t know enough to really explain and be correct in my explanation but I do have a fugly patch which worked for me. Bug 803658 tracks this defect. The basic approach I took was to say that dmraid devices should be an abstraction layer we don t peek under: if it claims to be a disk, well then its a disk. As grub does actually work that way - it talks to INT 13h the BIOS support for booting off of the RAID volume is entirely sufficient. Sadly neither bug is at the point where the patches can be rolled into Ubuntu itself, but the workaround should let folk get up and running. In both cases, build the package locally in the installer, install it, then after than run ubiquity and things should install. After the install, you will need to reapply the patch in the resulting installed environment, or things like update-grub will die on you! (huge thanks to cjwatson and ev for giving me some tips while I investigated this)

I have bought a Samsung Galaxy S Android phone some time ago. One of the first thing that you try to do with such a phone is to switch to some alternate firmware (the coined term is ROM ), like CyanogenMod. Flashing a firmware is a whole new universe. You are told about a lot of proprietary tools, you need to download a lot of things from MegaUpload and friends and nobody really explains what s going on under the hood. I was a bit lost at first. I will not provide a step-by-step guide since I cannot afford to stay up-to-date. Such a guide is usually posted on some forum. It assumes you are running Windows and provides appropriate download links. You must follow it (and check that it is recent enough). I will just provide you some background to understand those guides.

Android firmwares There are several Android firmwares. Most of them are specific to a given phone (or its close variations). They can be sorted in three categories:

1. Official firmwares from the phone manufacturer include a kernel with appropriate drivers and, usually, a customized interface (HTC Sense for HTC, TouchWiz for Samsung). Some manufacturers will lag a lot behind Android schedule and you may not get all the new shiny features.
2. Modified firmwares are built from the official firmwares. They usually add a lot of hacks on top of the original firmware, remove some cruft but are still closely related to the official firmware.
3. Firmwares built from Android Open Source Project (the open source version of Android) do not share nothing with the official firmware except some bits related to the kernel (drivers, hacks).

Darky ROM Darky ROM is a modified firmware. It takes the original firmware from Samsung, adds a custom kernel (based on the source of the official kernel), adds a lot of hacks, some additional applications and removes some unwanted cruft. This is a very nice firmware which is quite snappy. This is a drop-in replacement for the default firmware: you will only get improvements. The latest version is 10.1 and there is a neat guide on how to install it.

CyanogenMod CyanogenMod is a firmware built from AOSP. It supports several devices and provide an unified firmware on all of them. Support for the Samsung Galaxy S is recent and is not present in the stable build. However, some RC build is now available. Be sure to read the FAQ (most notably the part saying that you need to install from Froyo 2.2 because the bootloader provided by Samsung with Gingerbread 2.3 is not compatible). You can also grab some information from the wiki. The major drawback of using this firmware instead of going for a modified firmware like Darky ROM is that the battery life may suck. I now need to charge my phone every day instead of once every two days. On the plus side, you get a very clean firmware with a lot of features and almost no cruft. For example, the notification bar can be customized and OpenVPN is available out of the box. Moreover, almost everything is open source (if you don t install Google apps). You can see this firmware as an open source distribution for your phone. There is no need to download random files linked from a random forum to make it work. There is no package manager, though. Despite the bad battery life, I prefer this firmware.

Prerequisites Before trying to flash a new firmware, there are some tools that you need to have. Note that you don t need root access to flash a new firmware.

Download & recovery mode Before trying to install any firmware, you must check that your phone can access download and recovery modes. The download mode allows to flash any new firmware, even if the current firmware does not boot at all. As long as this mode is available, there is very little chance that you brick your phone. To access those modes, you need to use the three-button combo . Here are the steps (your phone should not be plugged):

1. Power off the phone (wait for the phone to vibrate).
2. Hold the Volume down button for download mode. Hold the Volume up button for recovery mode.
3. Hold the Home button.
4. Hold the Power button. The phone will start.
5. Once you have the Samsung logo displayed on the screen, release the Power button.
6. Only release the two other buttons when you enter the recovery mode or download mode. The recovery mode displays a menu. The download mode displays a big yellow Android logo.

If after ten tries, you are unable to access those modes, maybe they have been disabled. Keep reading, there is a solution.

Heimdall Heimdall is a tool to flash a new firmware to your phone. This is not a mandatory tool but you will have to use it if something goes wrong. Most guides will tell you to use Odin. It is a leaked Samsung tool running on Windows only. You can use Heimdall instead.

$ git clone https://github.com/Benjamin-Dobell/Heimdall.git
Cloning into Heimdall...
remote: Counting objects: 423, done.
remote: Compressing objects: 100% (271/271), done.
remote: Total 423 (delta 220), reused 332 (delta 138)
Receiving objects: 100% (423/423), 5.91 MiB   962 KiB/s, done.
Resolving deltas: 100% (220/220), done.
$ cd Heimdall/heimdall
$ sudo apt-get install libusb-1.0-0-dev
$ ./configure && make
[...]
$ sudo cp 60-heimdall-galaxy-s.rules /etc/udev/rules.d
$ sudo /etc/init.d/udev reload

You need to use this tool while in download mode. You can test it, while in download mode, with:

$ ./heimdall print-pit

This will display the partition table of your phone. This is enlightening to know what it contains:

• IBL+PBL is the boot loader, be extra careful with it;
• PIT is the partition table;
• EFS contains some important data like IEMEI, be extra careful with it;
• SBL is the second boot loader;
• SBL2 is the backup of the second boot loader;
• PARAM contains some images used as various stage of the boot process;
• KERNEL is the kernel;
• RECOVERY is the backup of the kernel;
• FACTORYFS contains /system file system which is some kind of root file system;
• DBDATA contains /data file system which is the database to store application parameters;
• CACHE contains /cache file system which contains the Dalvik cache;
• MODEM contains the firmware for the modem.

As we will see, Heimdall is able to flash any of those partitions with flash subcommand.

adb adb stands for Android Debug Bridge. Among other things, this tool allow you to drive your phone through the USB connection. You can get a shell, reboot into download or recovery mode, push files to your Android device, etc. To get this tool, you need to download the full Android SDK.

$ tar zxvf ~/download/android-sdk_r11-linux_x86.tgz
$ cd android-sdk-linux_x86
$ tools/android update sdk
[select Android SDK Platform-tools]
$ platform-tools/adb shell
# uname -a
Linux localhost 2.6.35.7-I9000XWJVH-CL184813 #Dark_Core_2.4 PREEMPT Mon May 16 15:02:38 EEST 2011 armv7l GNU/Linux

The important commands are:

• shell to get a shell on the device;
• reboot recovery to reboot in recovery mode;
• reboot download to reboot in download mode;
• push to put a file on the phone;
• pull to retrieve a file;
• install to install an application from its APK;
• logcat to see the logs and what happens, very useful!

Restore download mode If your phone is missing download mode, you can recover it with the help of adb and heimdall. You need to grab some official firmware and extract boot.bin and Sbl.bin from it.

$ adb reboot download
$ heimdall flash --primary-boot ~/download/boot.bin --secondary-boot ~/download/Sbl.bin

Be extra careful here. You may brick your phone. Double check that you grab the correct files and that they are really for your phone (there exists some variants). It worked for me.

Installing a new firmware While you can switch from one firmware to another without losing your data, it is better to wipe your system and your data before switching firmware. This means that you will lose all your applications and the data inside them (list of contacts, SMS, preferences). However, nothing will ever modify your data in the internal SD card or in the external SD card (which are both inside the phone). They usually contains your music and your photos. There are two ways to install a firmware:

1. via Heimdall, or
2. using the recovery.

Heimdall When a guide tells you to use Odin, you can use Heimdall instead. Odin takes a TAR file. You should untar it and uses its content with Heimdall. For example:

$ ./heimdall flash --repartition --pit s1_odin_20100512.pit \
>                  --factoryfs factoryfs.rfs \
>                  --cache cache.rfs --dbdata dbdata.rfs \
>                  --param param.lfs --modem modem.bin \
>                  --kernel zImage --secondary-boot Sbl.bin 
Claiming interface again...   Success
Setting up interface...   Success
Beginning session...
Handshaking with Loke...   Success
Uploading PIT
PIT upload successful
Uploading SBL
100%
SBL upload successful
Uploading KERNEL
100%
KERNEL upload successful
Uploading MODEM
100%
MODEM upload successful
Uploading PARAM
100%
PARAM upload successful
Uploading FACTORYFS
100%
FACTORYFS upload successful
Uploading DBDATAFS
100%
DBDATAFS upload successful
Uploading CACHE
100%
CACHE upload successful
Ending session...
Rebooting device...

You may be interested to update your modem using Heimdall. This is usually independent of the firmware you want to use. Also, no need to provide a PIT file if you don t want to repartition. Heimdall can read the current one and flash only one of the partitions.

Recovery mode The base recovery shipped with the Samsung Galaxy S does not have a lot of options. Moreover, it may be locked and will accept to install only signed firmwares. Most firmwares come with ClockWorkMod, a more advanced recovery. Once you get it, you will be able to use any ZIP file to install a new firmware. My advice is to try to get ClockWorkMod as soon as possible. If you are root, you can install ROM Manager that will install it for you. If you are not root, most custom firmwares will provide ClockWorkMod. Therefore, you can just install a custom firmware with Heimdall. There exists special firmwares just for this, like EZbase. If you want to install CyanogenMod, be sure to download a Froyo firmware, not a Gingerbread one. Keep in mind that the recovery is located inside the kernel. It is not self-contained in the bootloader (unlike download mode). If you don t want to flash a whole firmware (and lose everything on your phone) just to get the recovery, you can just flash the kernel. The ClockWorkMod recovery comes with an utility to backup your whole phone. This way, you can easily restore your previous firmware if you don t like the current one. This is what is called a Nandroid backup.

Lagfix A lot of guides will tell you to enable or disable lagfix. Samsung shipped the Galaxy S with some crappy filesystem called RFS (which is some kind of enhanced FAT). It is slow and seems responsible for some lags that may happen on the interface. A lagfix is a way to replace this filesystem by something better, like EXT4 or YAFFS2. The process is pretty straighforward and consist to backup all the partition to the SD card, reformat it with another filesystem and restore the backup. The lagfix may be applied automatically with some firmware (like CyanogenMod) or you may request it in the recovery mode (most modified firmwares work this way). In this case, it will be applied automatically on the next boot. You should disable it before installing another firmware with the recovery mode (no need if you install it with Heimdall).

Applications You can find many free (as in free speech) applications for Android. Unfortunately, Android Market does not allow to use this criteria as a filter. F-Droid is an alternate market featuring only FOSS applications. Here is a short selection of free applications:

• ADW.Launcher is a home replacement app. It is very configurable and themable.
• K-9 Mail is a very nice email client.
• Xabber is a XMPP/Jabber client.
• ConnectBot is an SSH client (as well as a terminal).
• DroidWall is an application firewall (using Netfilter). It lets you select which application can access to Internet depending on your connection (wifi or 3G).
• Barcode Scanner decodes 1D/2D barcode including QR codes.
• OsmAnd is a replacement for Google Maps using OpenStreetMap. The free version on Android Market is out-dated. Buy the plus version or download it throught F-Droid.

Another must-have application is Titanium Backup which allows to backup any application with data. Unfortunately, this is not a free (as in free speech) application.

I have bought a Samsung Galaxy S Android phone some time ago. One of the first thing that you try to do with such a phone is to switch to some alternate firmware (the coined term is ROM ), like CyanogenMod. Flashing a firmware is a whole new universe. You are told about a lot of proprietary tools, you need to download a lot of things from MegaUpload and friends and nobody really explains what s going on under the hood. I was a bit lost at first. I will not provide a step-by-step guide since I cannot afford to stay up-to-date. Such a guide is usually posted on some forum. It assumes you are running Windows and provides appropriate download links. You must follow it (and check that it is recent enough). I will just provide you some background to understand those guides.

Android firmwares There are several Android firmwares. Most of them are specific to a given phone (or its close variations). They can be sorted in three categories:

1. Official firmwares from the phone manufacturer include a kernel with appropriate drivers and, usually, a customized interface (HTC Sense for HTC, TouchWiz for Samsung). Some manufacturers will lag a lot behind Android schedule and you may not get all the new shiny features.
2. Modified firmwares are built from the official firmwares. They usually add a lot of hacks on top of the original firmware, remove some cruft but are still closely related to the official firmware.
3. Firmwares built from Android Open Source Project (the open source version of Android) do not share nothing with the official firmware except some bits related to the kernel (drivers, hacks).

Darky ROM Darky ROM is a modified firmware. It takes the original firmware from Samsung, adds a custom kernel (based on the source of the official kernel), adds a lot of hacks, some additional applications and removes some unwanted cruft. This is a very nice firmware which is quite snappy. This is a drop-in replacement for the default firmware: you will only get improvements. The latest version is 10.1 and there is a neat guide on how to install it.

CyanogenMod CyanogenMod is a firmware built from AOSP. It supports several devices and provide an unified firmware on all of them. Support for the Samsung Galaxy S is recent and is not present in the stable build. However, some RC build is now available. Be sure to read the FAQ (most notably the part saying that you need to install from Froyo 2.2 because the bootloader provided by Samsung with Gingerbread 2.3 is not compatible). You can also grab some information from the wiki. The major drawback of using this firmware instead of going for a modified firmware like Darky ROM is that the battery life may suck. I now need to charge my phone every day instead of once every two days. On the plus side, you get a very clean firmware with a lot of features and almost no cruft. For example, the notification bar can be customized and OpenVPN is available out of the box. Moreover, almost everything is open source (if you don t install Google apps). You can see this firmware as an open source distribution for your phone. There is no need to download random files linked from a random forum to make it work. There is no package manager, though. Despite the bad battery life, I prefer this firmware.

Prerequisites Before trying to flash a new firmware, there are some tools that you need to have. Note that you don t need root access to flash a new firmware.

Download & recovery mode Before trying to install any firmware, you must check that your phone can access download and recovery modes. The download mode allows to flash any new firmware, even if the current firmware does not boot at all. As long as this mode is available, there is very little chance that you brick your phone. To access those modes, you need to use the three-button combo . Here are the steps (your phone should not be plugged):

1. Power off the phone (wait for the phone to vibrate).
2. Hold the Volume down button for download mode. Hold the Volume up button for recovery mode.
3. Hold the Home button.
4. Hold the Power button. The phone will start.
5. Once you have the Samsung logo displayed on the screen, release the Power button.
6. Only release the two other buttons when you enter the recovery mode or download mode. The recovery mode displays a menu. The download mode displays a big yellow Android logo.

If after ten tries, you are unable to access those modes, maybe they have been disabled. Keep reading, there is a solution.

Heimdall Heimdall is a tool to flash a new firmware to your phone. This is not a mandatory tool but you will have to use it if something goes wrong. Most guides will tell you to use Odin. It is a leaked Samsung tool running on Windows only. You can use Heimdall instead.

$ git clone https://github.com/Benjamin-Dobell/Heimdall.git
Cloning into Heimdall...
remote: Counting objects: 423, done.
remote: Compressing objects: 100% (271/271), done.
remote: Total 423 (delta 220), reused 332 (delta 138)
Receiving objects: 100% (423/423), 5.91 MiB   962 KiB/s, done.
Resolving deltas: 100% (220/220), done.
$ cd Heimdall/heimdall
$ sudo apt-get install libusb-1.0-0-dev
$ ./configure && make
[...]
$ sudo cp 60-heimdall-galaxy-s.rules /etc/udev/rules.d
$ sudo /etc/init.d/udev reload

You need to use this tool while in download mode. You can test it, while in download mode, with:

$ ./heimdall print-pit

This will display the partition table of your phone. This is enlightening to know what it contains:

• IBL+PBL is the boot loader, be extra careful with it;
• PIT is the partition table;
• EFS contains some important data like IEMEI, be extra careful with it;
• SBL is the second boot loader;
• SBL2 is the backup of the second boot loader;
• PARAM contains some images used as various stage of the boot process;
• KERNEL is the kernel;
• RECOVERY is the backup of the kernel;
• FACTORYFS contains /system file system which is some kind of root file system;
• DBDATA contains /data file system which is the database to store application parameters;
• CACHE contains /cache file system which contains the Dalvik cache;
• MODEM contains the firmware for the modem.

As we will see, Heimdall is able to flash any of those partitions with flash subcommand.

adb adb stands for Android Debug Bridge. Among other things, this tool allow you to drive your phone through the USB connection. You can get a shell, reboot into download or recovery mode, push files to your Android device, etc. To get this tool, you need to download the full Android SDK.

$ tar zxvf ~/download/android-sdk_r11-linux_x86.tgz
$ cd android-sdk-linux_x86
$ tools/android update sdk
[select Android SDK Platform-tools]
$ platform-tools/adb shell
# uname -a
Linux localhost 2.6.35.7-I9000XWJVH-CL184813 #Dark_Core_2.4 PREEMPT Mon May 16 15:02:38 EEST 2011 armv7l GNU/Linux

The important commands are:

• shell to get a shell on the device;
• reboot recovery to reboot in recovery mode;
• reboot download to reboot in download mode;
• push to put a file on the phone;
• pull to retrieve a file;
• install to install an application from its APK;
• logcat to see the logs and what happens, very useful!

Restore download mode If your phone is missing download mode, you can recover it with the help of adb and heimdall. You need to grab some official firmware and extract boot.bin and Sbl.bin from it.

$ adb reboot download
$ heimdall flash --primary-boot ~/download/boot.bin --secondary-boot ~/download/Sbl.bin

Be extra careful here. You may brick your phone. Double check that you grab the correct files and that they are really for your phone (there exists some variants). It worked for me.

Installing a new firmware While you can switch from one firmware to another without losing your data, it is better to wipe your system and your data before switching firmware. This means that you will lose all your applications and the data inside them (list of contacts, SMS, preferences). However, nothing will ever modify your data in the internal SD card or in the external SD card (which are both inside the phone). They usually contains your music and your photos. There are two ways to install a firmware:

1. via Heimdall, or
2. using the recovery.

Heimdall When a guide tells you to use Odin, you can use Heimdall instead. Odin takes a TAR file. You should untar it and uses its content with Heimdall. For example:

$ ./heimdall flash --repartition --pit s1_odin_20100512.pit \
>                  --factoryfs factoryfs.rfs \
>                  --cache cache.rfs --dbdata dbdata.rfs \
>                  --param param.lfs --modem modem.bin \
>                  --kernel zImage --secondary-boot Sbl.bin 
Claiming interface again...   Success
Setting up interface...   Success
Beginning session...
Handshaking with Loke...   Success
Uploading PIT
PIT upload successful
Uploading SBL
100%
SBL upload successful
Uploading KERNEL
100%
KERNEL upload successful
Uploading MODEM
100%
MODEM upload successful
Uploading PARAM
100%
PARAM upload successful
Uploading FACTORYFS
100%
FACTORYFS upload successful
Uploading DBDATAFS
100%
DBDATAFS upload successful
Uploading CACHE
100%
CACHE upload successful
Ending session...
Rebooting device...

You may be interested to update your modem using Heimdall. This is usually independent of the firmware you want to use. Also, no need to provide a PIT file if you don t want to repartition. Heimdall can read the current one and flash only one of the partitions.

Recovery mode The base recovery shipped with the Samsung Galaxy S does not have a lot of options. Moreover, it may be locked and will accept to install only signed firmwares. Most firmwares come with ClockWorkMod, a more advanced recovery. Once you get it, you will be able to use any ZIP file to install a new firmware. My advice is to try to get ClockWorkMod as soon as possible. If you are root, you can install ROM Manager that will install it for you. If you are not root, most custom firmwares will provide ClockWorkMod. Therefore, you can just install a custom firmware with Heimdall. There exists special firmwares just for this, like EZbase. If you want to install CyanogenMod, be sure to download a Froyo firmware, not a Gingerbread one. Keep in mind that the recovery is located inside the kernel. It is not self-contained in the bootloader (unlike download mode). If you don t want to flash a whole firmware (and lose everything on your phone) just to get the recovery, you can just flash the kernel. The ClockWorkMod recovery comes with an utility to backup your whole phone. This way, you can easily restore your previous firmware if you don t like the current one. This is what is called a Nandroid backup.

Lagfix A lot of guides will tell you to enable or disable lagfix. Samsung shipped the Galaxy S with some crappy filesystem called RFS (which is some kind of enhanced FAT). It is slow and seems responsible for some lags that may happen on the interface. A lagfix is a way to replace this filesystem by something better, like EXT4 or YAFFS2. The process is pretty straighforward and consist to backup all the partition to the SD card, reformat it with another filesystem and restore the backup. The lagfix may be applied automatically with some firmware (like CyanogenMod) or you may request it in the recovery mode (most modified firmwares work this way). In this case, it will be applied automatically on the next boot. You should disable it before installing another firmware with the recovery mode (no need if you install it with Heimdall).

Applications You can find many free (as in free speech) applications for Android. Unfortunately, Android Market does not allow to use this criteria as a filter. F-Droid is an alternate market featuring only FOSS applications. Here is a short selection of free applications:

• ADW.Launcher is a home replacement app. It is very configurable and themable.
• K-9 Mail is a very nice email client.
• Xabber is a XMPP/Jabber client.
• ConnectBot is an SSH client (as well as a terminal).
• DroidWall is an application firewall (using Netfilter). It lets you select which application can access to Internet depending on your connection (wifi or 3G).
• Barcode Scanner decodes 1D/2D barcode including QR codes.
• OsmAnd is a replacement for Google Maps using OpenStreetMap. The free version on Android Market is out-dated. Buy the plus version or download it throught F-Droid.

Another must-have application is Titanium Backup which allows to backup any application with data. Unfortunately, this is not a free (as in free speech) application.

Hello The last version (1.247, available in Debian unstable as libconfig-model-perl) of Config::Model provides a brand new model for /etc/LCDd.conf. With this model, you can edit or validate your lcdproc configuration. To edit this configuration the first time, you will have to run:

config-edit -application lcdproc -force

The -force option is required to load the file the first time. (because the default LCDd.conf file contains configuration options for all drivers, even though only one them if usefull). You will get this screen:
In this screen, you can setup the driver for your adress with a right click on Driver parameter. Once youv e selected the driver and clicked on store , the driver will be listed in the left part of the window so you can tune the parameters of this specific driver: In this screen, I ve turned the backlight off and added a small note to remember why. This small note will be writted in a comment in /etc/LCDd.conf. Once all required modifications are done, it s time to save the configuration file using the menu entry File -> save Now, let s see the resulting file (which is a bit long due to the amount of comments in the original LCDd.conf file):

## This file was written by Config::Model
## You may modify the content of this file. Configuration
## modifications will be preserved. Modifications in
## comments may be mangled.
# LCDd.conf -- configuration file for the LCDproc server daemon LCDd
#
# This file contains the configuration for the LCDd server.
#
# The format is ini-file-like. It is divided into sections that start at
# markers that look like [section]. Comments are all line-based comments,
# and are lines that start with '
#
# The server has a 'central' section named [server]. For the menu there is
# a section called [menu]. Further each driver has a section which
# defines how the driver acts.
#
# The drivers are activated by specifiying them in a driver= line in the
# server section, like:
#
#   Driver=curses
#
# This tells LCDd to use the curses driver.
# The first driver that is loaded and is capable of output defines the
# size of the display. The default driver to use is curses.
# If the driver is specified using the -d  command line option,
# the Driver= options in the config file are ignored.
#
# The drivers read their own options from the respective sections.
[server]
# Where can we find the driver modules ?
# IMPORTANT: Make sure to change this setting to reflect your
#            specific setup! Otherwise LCDd won't be able to find
#            the driver modules and will thus not be able to
#            function properly.
# NOTE: Always place a slash as last character !
DriverPath=/usr/lib/lcdproc/
# Tells the server to load the given drivers. Multiple lines can be given.
# The name of the driver is case sensitive and determines the section
# where to look for further configuration options of the specific driver
# as well as the name of the dynamic driver module to load at runtime.
# The latter one can be changed by giving af File= directive in the
# driver specific section.
#
# The following drivers are supported:
#   bayrad, CFontz, CFontz633, CFontzPacket, curses, CwLnx, ea65,
#   EyeboxOne, g15, glcdlib, glk, hd44780, icp_a106, imon, imonlcd,
#   IOWarrior, irman, joy, lb216, lcdm001, lcterm, lirc, lis, MD8800,
#   mdm166a, ms6931, mtc_s16209x, MtxOrb, mx5000, NoritakeVFD, picolcd,
#   pyramid, sed1330, sed1520, serialPOS, serialVFD, shuttleVFD, sli,
#   stv5730, svga, t6963, text, tyan, ula200, xosd
Driver=imonlcd
# Tells the driver to bind to the given interface
Bind=127.0.0.1
# Listen on this specified port; defaults to 13666.
Port=13666
ReportLevel=3
# Sets the reporting level; defaults to 2 (warnings and errors only).
# ReportLevel=3
# Should we report to syslog instead of stderr ? [default: no; legal: yes, no]
# ReportToSyslog=yes
# User to run as.  LCDd will drop its root priviledges, if any,
# and run as this user instead.
User=nobody
Foreground=no
Hello=    Hello
Hello=    LCDproc!
GoodBye=    GoodBye
GoodBye=    LCDproc!
# The server will stay in the foreground if set to true.
# Foreground=no
# Hello message: each entry represents a display line; default: builtin
# Hello="  Welcome to"
# Hello="   LCDproc!"
# GoodBye message: each entry represents a display line; default: builtin
# GoodBye="Thanks for using"
# GoodBye="   LCDproc!"
# Sets the default time in seconds to displays a screen.
WaitTime=5
# If yes, the the serverscreen will be rotated as a usual info screen. If no,
# it will be a background screen, only visible when no other screens are
# active. The special value 'blank' is similar to no, but only a blank screen
# is displayed. [default: on; legal: on, off, blank]
# ServerScreen=no
# Set master backlight setting. If set to 'open' a client may control the
# backlight for its own screens (only). [default: open; legal: off, open, on]
# Backlight=open
# Set master heartbeat setting. If set to 'open' a client may control the
# heartbeat for its own screens (only). [default: open; legal: off, open, on]
# Heartbeat=open
# set title scrolling speed [default: 10; legal: 0-10]
# TitleSpeed=10
# The "...Key=" lines define what the server does with keypresses that
# don't go to any client.
# These are the defaults:
ToggleRotateKey=Enter
PrevScreenKey=Left
NextScreenKey=Right
ScrollUpKey=Up
ScrollDownKey=Down
# ScrollUpKey=Up
# ScrollDownKey=Down
# If you have only 4 keys, you can choose to use this:
# ToggleRotateKey=Enter
# PrevScreenKey=Up
# NextScreenKey=Down
# If you have only 3 keys, you can choose to use this:
# ToggleRotateKey=Enter
# PrevScreenKey=Up
[menu]
# You can configure what keys the menu should use. Note that the MenuKey
# will be reserved exclusively, the others work in shared mode.
# The following works excellent with 4 keys or more.
MenuKey=Escape
EnterKey=Enter
UpKey=Up
DownKey=Down
LeftKey=Left
RightKey=Right
[imonlcd]
Protocol=0
OnExit=2
Device=/dev/lcd0
# My fishes dont like the glow
Backlight=off
DiscMode=0

You will notice a few things:

• Comments from the original file in section [server] and [menu] were kept
• Unused drivers sections are gone
• The fishy note about backlight was saved as a comment above the backlight parameter

If you need to update the file, you will have to run:

sudo config-edit -application lcdproc

The -force option is no longer needed. If you don t like to click, you can run:

config-edit -application lcdproc -ui none -save

For instance:

config-edit -application lcdproc -ui none -save 'server driver=imonlcd - imonlcd Device="/dev/lcd1" '

Further reading If you want to know more about lcdproc model, you can view:

• LCDd model and all models for the drivers
• LCDd documentation and the drivers documentationgenerated from these models

Under the hood I was too lazy to write myself the models of all drivers (about 3500 lines for them all). All models were generated from the LCDd.conf template file provided by lcdproc project. This blog explains how this was done. But the result is far from perfect. Event though LCDd.conf comments give a lot of semantic information, parameter types could be better adjusted and some of the examples provided in LCDd.conf confuse the model generator.
So the current comments are good, but not enough. In the future, we could decide on better structural conventions for the comments that would give users the information they need and give a model generator enough information to generate better models. This will hopefully be the topic of yet another blog All the best

Two weeks ago, I updated the packages containing the BioPerl modules bioperl and bioperl-run, which allowed to resume the work done on GBrowse, one of the genome browsers available in Debian. As many Perl modules, BioPerl has extensive regression tests. Some of them need access to external services, and are disabled by default as the Internet is not available in our build farm. Nevertheless, they can be triggered through the environment variable DEB_MAINTAINER_MODE when building the package locally. Bioperl successfully passes all off-line tests, and a part of the on-line tests is already corrected its development branch. In contrary, BioPerl-Run fail the tests for Bowtie, DBA, EMBOSS, Genewise, Hmmer, PAML, SABlastPlus, T-Coffee and gmap-run. In some cases, like EMBOSS, it is because a command has been renamed in Debian. In other cases, in particular DBA et Genewise, it is much more difficult to figure out on which side is the problem. Regression tests are essential to determine if a package works or not on ports others than the one used by the packager (amd64 in my case). Even simple ones can be useful. In the case of T-Coffee, that has a rudimentary test that I have activated recently, it showed that the packages distributed on armel are not working at all. Running regression tests when building packages have advantages, in particular to have the results published for each port automatically as part of the build logs. But is also cause problems. First, a package would need to build-depend on every software it can interact with, in order to test it comprehensively. In the example of bioperl-run, it makes it impossible to build on armel as long as t-coffee is broken there. Second, this approach does not help the user to test similarly a program installed on his computer. Maybe the Debian Enhancement Proposal 8, to test binary packages with material provided by their source packages, will solve these two problems.

LDAP's "Country" entry reads "France" The correlation among quiet times for a blog and quiet times in its owner's life is often negative. My past two months are no exception. Beside my regular Debian activities, I've used a good chunk of my day time to (try) settle down and stop wandering around Europe, one temporary academic position after another. In the end, it has turned out very well. Starting September 1st, I'll be joinining the PPS laboratory as a Ma tre de Conf rences, a tenured academic position roughly equivalent to US' Associate Professor (at least according to Wikipedia; see the high quality references that tenured people resort to use?). More specifically, I'll continue to work in the context of IRILL (Research and Innovation on Free Software), an exciting new entity that I've helped bootstraping over the past couple of years. Thanks to IRILL and to his director Roberto Di Cosmo, I've been able not only to pursue quite some research on FOSS distros, but I've also been supported (rather than discriminated) in my Debian activities, including acting as DPL around the world. Last but not least, within IRILL I have also been able to offer support to several Free Software communities such as: Debian itself (hosting Sprints and sponsoring DebConf hardware), GNU, OSI, OCaml, Darcs, and many others. I realize how lucky I've been ending up in a place like IRILL and I'm glad to know I'll be around here for quite some time. The main change I'll expect to happen from September on is that I'll get back to do some teaching, trading-off time from research activities. I've been teaching only on and off since I've moved to France in 2008 and I miss that quite a bit. It looks like that next year I'll be teaching various classes on FOSS-related (or at the very least UNIX-y) topics. Time looks scarce, but who knows, maybe I'll also find a way to mix-in the nice packaging tutorial that Lucas has recently put together. Wish me luck!

In a series of experiments performed over the past few days, I've determined that the actual mechanism by which "water saving" shower heads work is not, as you might naively imagine, reducing the amount of water dispersed per unit time. Instead, they make showering such an unpleasant experience that you perform amazing feats of speed washing so you can get out as quickly as possible. In extreme cases, I can imagine you would save even more water by just not washing at all.

Right around the time I immigrated to the US Alex Trebek began a revival of a TV game show originally hosted by Art Fleming called Jeopardy. In fact I believe I saw the first episode or one of the first ones anyway. And ever since I began watching, people have said to me I ought to be a contestant. I've tried to get on every now and again with little success until this year. In February I took the online entrance test not expecting any results as usual. Indeed nothing happened at first then suddenly, a few weeks ago, I was surprised to receive an email inviting me to an audition. So today (or yesterday depending on when you read this. June 27th.) I went to a conference room in the New York Sheraton Towers hotel to show off my telegenic looks, rapier wit and mastery of general knowledge to the Jeopardy producers. I had to bring in a list of five fun facts about myself for the between-round amusing banter. You'll have to wait until I actually appear on the show (if in fact I do. See below.) but let me assure you my banter is very amusing. My spirit flagged a bit when they took a photo of me for their files. I managed to do a convincing impression of Tow Mater from Cars 2 which is not quite the showbiz look I was going for. My morale rose again after the next portion of the audition in which you had to answer 50 trivia questions in about 8 minutes. They don't tell you your score but based on my conversations with fellow auditionees (there were about 20 of us) I think I only got 1 wrong. The next part of the audition was a mock game with a real board and buzzers etc. I was in the first group of three to play which further leads me to believe I got a good score in the questions. Unfortunately I had a bit of bad luck in the categories half of which were not in my strong subjects but I did ok. More importantly I demonstrated a good speaking voice (a lot of people mumble or speak too softly), good buzzer technique and as I may have previously mentioned, amusing banter. Does this mean I am actually going to be on TV? I don't know. Every year they select approximately 2,000 people for auditions and of those, around 400 are selected for the contestant pool. So I have a 1 in 5 chance of making it. The consensus in the group was I had done pretty well for a first timer (Some were making their second or third attempt.) so I am optimistic. All I know is that sometime in the next 18 months I might receive the call to fly to Los Angeles and fulfill my destiny. Btw, in case you were wondering about the title.

In a series of experiments performed over the past few days, I've determined that the actual mechanism by which "water saving" shower heads work is not, as you might naively imagine, reducing the amount of water dispersed per unit time. Instead, they make showering such an unpleasant experience that you perform amazing feats of speed washing so you can get out as quickly as possible. In extreme cases, I can imagine you would save even more water by just not washing at all.

As part of trying to help with Freedom Box, I gained access to a Dream Plug The Dream Plug is one of the leading possible platforms for Freedom Box. Computationally it s sexy for a low-power device. There s a 1200 mhz arm with 512m of RAM. As a platform to enable people to create novel applications, it s great. It has multiple USB ports, two ethernets, a built-in 802.11B/G access point, bluetooth, audio, ESATA, Micro SD and full-sized SD. So, whether you application needs storage, networking, audio, or some interesting side device, you re covered. With the optional JTAG adapter it s even fairly friendly to developers: there are options for recovering from most failures and full console access. If you re looking at a reference platform that s still nominally embedded, but that allows you to play around thinking about what your application could do, this is a great option. However, especially for Freedom Box, it s important to remember that the reference board a developer wants is not the same as a cost-reduced product on which to actually deploy something for people to buy. The Dream Plug is wrong for every actual deployment I ve imagined. First, it s huge. If you happen to have free power plugs on your wall with lots of space above and below them, it might be an option. If however, you re like everyone I know and have power strips, constrained spacing, etc, then the industrial engineering will disappoint at every turn. I was hoping for something that kind of looked like an Apple Airport Express. It s significantly larger than that in every dimension. Also, the plug is oriented the wrong way for minimizing the fraction of the power strip it takes up. The power supply part of the device can be detached, although even that is way too huge for a power strip, and the cable between the power supply and the computer is fairly short. You can reconfigure the device without its plug nature: running a cord from a normal power outlet to the power supply. But then if you have to detach the power supply for heat management reasons, you get a cord from the outlet to the power supply and another cord from the supply to the device. Add a few USB or ESATA devices and the octopus of cables begins to resemble some arcane mechanism. (So far, no elder gods have appeared though.) The other issue is that you almost never want all the functionality. You pay for the bluetooth, audio and ESATA in terms of cost, heat and space regardless of whether you use them. I don t have a lot of applications that really take advantage of the full array of hardware. The firmware update mechanism is decidedly not targeted at end-users. The version I obtained had a hacked copy of Debian lenny. No mechanism was provided for replacing the image in a safe manner that did not potentially require the optional highly-non-end-user-compatible JTAG board if something got interrupted. You could either unscrew the device and get to the micro SD card containing the image, or run software to replace the image from within Debian lenny. It s possible to configure the boot loader to run an update image off USB or SD until that succeeds, but doing that is also a non-end-user operation. In conclusion, the name is perfect. This is exactly what hackers need to dream about the power of small computers everywhere. However we must not forget that there s a step required to turn dreams into reality. Just as with any fully proprietary product, Freedom Box will require cost reduction steps, semi-custom boards and actual OEMs to truly be usable. The claim in the previous sentence that the Freedom Box may have proprietary elements is disquieting to some. I think we can put together a software stack that is free with the possible exception of some device firmware. However, my suspicion is that anyone who turns that into a fully realized end-user product will add proprietary elements. I suspect some of the results of the cost reduction process such as resulting semi-custom boards will be proprietary. In many cases though, I suspect some proprietary software elements will be introduced.

In the aftermath of the World IPv6 Day YouTube seems to be serving its content over IPv6 now. Interestingly the frontpage is still served via IPv4 (if you're not in a Google IPv6 whitelisted network). But all the Flash and HTML5 video content is served through IPv6 if available, as the cache servers return proper AAAA DNS records. Apparently that's the case unless your network is blacklisted because of bad IPv6 support and even if Google has some caches at your provider's site (which is the case for Alice DSL in Germany, at least).

I think that's quite some motivation for the providers to at least fix IPv6 connectivity if available and to suppress rogue IPv6 router advertisements in their networks. I had to ensure the former today and the latter is a constant source of grief with the bulk of L2 switches and Wi-Fi access points not being IPv6 ready.

As a Debian/Ubuntu user, you re likely to be exposed at some point to an error reported by dpkg. In a series of articles, I ll explain some of the errors that you might encounter. Some error messages can be confusing at times. Most of the error strings do not appear very often and developers thus tend to use very terse description of the underlying problem. In other cases the architecture of the software makes it difficult to pin-point the real problem because the part that displays the error is several layers above the one that generated the initial error. This is for example the case with this error of dpkg:

Unpacking replacement xulrunner-1.9.2 ...
dpkg-deb (subprocess): data: internal gzip read error: '<fd:0>: too many length or distance symbols'
dpkg-deb: error: subprocess <decompress> returned error exit status 2
dpkg: error processing /var/cache/apt/archives/xulrunner-1.9.2_1.9.2.17+build3+nobinonly-0ubuntu1_amd64.deb (--unpack):
 short read on buffer copy for backend dpkg-deb during  ./usr/lib/xulrunner-1.9.2.17/components/libdbusservice.so'

First, the decompression layer discovers something unexpected in the data read in the .deb file and dpkg-deb outputs the error message coming from zlib ( too many length or distance symbols ). This causes the premature end of dpkg-deb --fsys-tarfile that dpkg had executed to extract the .data.tar archive from the deb file. In turn, dpkg informs us that dpkg-deb did not send all the data that were announced (and hence the short read in the error message) and that were meant to be part of the file /usr/lib/xulrunner-1.9.2.17/components/libdbusservice.so . That s all nice but it doesn t help you much in general. What you must understand from the above is that the .deb file is corrupted (sometimes just truncated). In theory it should not happen since APT verifies the checksums of files when they are downloaded. But computers are not infallible and even if the downloaded data was good, it can have been corrupted when stored on disk (for example cheap SSD disks are known to not last very well). Try removing the file (usually with apt-get clean since it s stored in APT s cache) and let APT download it again. Chances are that it will work on the second try. Otherwise consider doing a memory and HDD check as something is probably broken in your computer.

Join my free newsletter and learn more tips for users.

4 comments Liked this article? Click here. My blog is Flattr-enabled.

I haven t blogged for a while, because I ve been doing so many things that I scarcely had time nor will for it. Among all those things, and during the weekends of the last few months, we have been teaching kids (8-12 y.o.) about computers, Free Software and technology. Those kids are great, very intelligent, very motivated, and very funny to be with. I miss them a bit after the program has ended. In any case, I ve been given the chance to teach some more kids during summer weekdays, and I m really looking forward to it. The downside of this is that I won t have any summer holidays and, thus, I finally won t be able to attend DebConf 11 in Banja Luka, which was something I was also looking forward too. But, even though that s something I d really love to do, one cannot be in two places at the time, so this year I finally won t be able to attend DebConf either. Have lots of fun! I ll miss you! In case you want to know more about all of this (sorry, links are in Spanish):

• La Servilleta de Paco Prieto [feb 26 2011]: J venes descubriendo talento: tecnolog a, ciencia, emprender y matem ticas
• La Servilleta de Paco Prieto [jun 21 2011]: Estudiantes que quieren m s ca a !!!

Oh, and to show you what I m exchanging you for (nothing personal): I wouldn t like to end this post without thanking all the kids from both Campus TIC and Yo Programo for being so cool, and also to welcome the kids from Fantastic Park, in case any of them -or their parents- are reading. Oh, and all of you who attend DebConf this year, have a lot of fun!

The goal of this lab is to setup a site-to-site IPsec VPN. This lab is similar to my first lab using UML. The major differences are:

• We only setup one VPN instead of two.
• Static routing is used in place of BGP for inter-site routing. Moreover, BIRD is used as a routing daemon.
• VPN are using an external network for Internet access.
• Both internal network and external network are redundant using one OSPF instance each.

The lab

The big picture The main point of this architecture is that you get two redundant networks for each site. The external ones are used when hosts need Internet access. The internal ones are used when they want to communicate with each other. Because we don t want hosts from the first site to communicate with hosts from the second site through the external network, we extend the internal network with the help of a site-to-site IPsec VPN. Each set of networks is using two layer-3 networks on top of two layer-2 networks. OSPF is used to provide redundancy and aggregation. For example, R1 has two routes through V1 to access R2 which is on the other site:

# ip route show 192.168.96.0/19
192.168.96.0/19  proto zebra  metric 10000 
        nexthop via 192.168.1.100  dev eth0 weight 1
        nexthop via 192.168.2.100  dev eth1 weight 1

Setting up the lab First, grab the source of the lab:

$ git clone https://vincentbernat@github.com/vincentbernat/network-lab.git
$ cd network-lab/lab-s2s-vpn

You may try to run ./setup directly. It may be safer to build an image of Debian inside inside a directory and use it as a base for the lab.

$ sudo debootstrap sid ../sid-chroot http://ftp.fr.debian.org/debian/
[...]
$ sudo chroot ../sid-chroot /bin/bash
# apt-get install iproute zsh rsyslog less makedev tcpdump
# apt-get install bird quagga racoon
# exit
$ ROOT=../sid-chroot ./setup

You still need a working UML kernel. On Ubuntu, the one provided in user-mode-linux does not contain the aufs.ko module. I did not find a simple workaround. You can just grab the package from Debian and install it on your Ubuntu with dpkg -i.

Use of BIRD With the previous lab, Quagga was used as an OSPF routing daemon. We still use it on R1, R2, E1 and E2. However, Quagga is not able to run multiple instances of OSPF. BIRD can. Therefore, we use it on V1 and V2 because we need two OSPF instances: one for the external network and one for the internal network. Since we also need ECMP, we need at least BIRD 1.3.0. BIRD allows the definition of multiple routing tables. Those tables are independant of the kernel routing tables. Each protocol will maintain its own set of routes and will allow to export (or import) routes from one of the routing table maintained by BIRD. In our setup, we use four protocols and only one routing table (the default one). The ospf EXTERNAL protocol is one of the two OSPF instances we use on V1. We import all the routes learned through the OSPF process into the internal BIRD routing table. We don t export any route from the BIRD routing table to this OSPF instance. Here is the configuration of this protocol:

protocol ospf EXTERNAL  
   ecmp yes;
   import all;
   export none;
   area 0.0.0.0  
      networks  
         203.0.113.0/26;
         203.0.113.64/26;
         203.0.113.150/32;
       ;
      interface "eth2";
      interface "eth3";
      interface "lo"  
        stub yes;
       ;
    ;
 

203.0.113.150/32 is defined on the loopback interface of V1. This is the IP of the local VPN endpoint. The ospf INTERNAL protocol is the second OSPF instance. We import all routes from this protocol to the BIRD routing table. We also want to advertise the route to the remote site. This route is defined in the static STATIC protocol and imported into BIRD routing table.

protocol static STATIC  
   import all;
   export none;
   route 192.168.96.0/19 via "lo";
 

Therefore, ospf INTERNAL protocol export all routes originating from the static STATIC protocol. This is done using filters:

protocol ospf INTERNAL  
   ecmp yes;
   import all;
   export filter  
     if proto = "STATIC" then accept;
     reject;
    ;
   area 0.0.0.0  
      networks  
         192.168.1.0/24;
         192.168.2.0/24;
       ;
      interface "eth0";
      interface "eth1";
    ;
 

The kernel protocol is managing one kernel routing table. By default, it handles the main table. We don t import any route from the kernel. However, we copy routes that come from other protocols, except the static route because we already have a default route and the static route is some kind of blackhole, we don t want to use it for real routing.

protocol kernel  
   persist;
   import none;
   export filter  
     if proto = "EXTERNAL" then accept;
     if proto = "INTERNAL" then accept;
     reject;
    ;
 

The filtering mechanism built inside BIRD is pretty powerful.

Testing After starting the lab, you need to wait a few seconds. You should then be able to ping R2 from R1:

R1# ping -c3 -I 192.168.15.1 192.168.115.1
PING 192.168.115.1 (192.168.115.1) from 192.168.15.1 : 56(84) bytes of data.
Warning: time of day goes back (-5435us), taking countermeasures.
64 bytes from 192.168.115.1: icmp_req=1 ttl=62 time=0.921 ms
64 bytes from 192.168.115.1: icmp_req=2 ttl=62 time=0.569 ms
64 bytes from 192.168.115.1: icmp_req=3 ttl=62 time=0.698 ms
--- 192.168.115.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2009ms
rtt min/avg/max/mdev = 0.569/0.729/0.921/0.147 ms

On V1, you can check BIRD internal routing table using birdc:

> show route 
0.0.0.0/0          multipath [EXTERNAL 19:43] * E2 (150/10/1) [0.0.0.11]
        via 203.0.113.1 on eth2 weight 1
        via 203.0.113.65 on eth3 weight 1
192.168.96.0/19    dev lo [STATIC 19:42] * (200)
192.168.1.0/24     dev eth0 [INTERNAL 19:42] * I (150/10) [0.0.0.100]
192.168.2.0/24     dev eth1 [INTERNAL 19:42] * I (150/10) [0.0.0.100]
192.168.15.0/24    multipath [INTERNAL 19:43] * I (150/20) [0.0.0.10]
        via 192.168.1.10 on eth0 weight 1
        via 192.168.2.10 on eth1 weight 1
203.0.113.0/26     dev eth2 [EXTERNAL 19:42] * I (150/10) [0.0.0.100]
203.0.113.64/26    dev eth3 [EXTERNAL 19:42] * I (150/10) [0.0.0.100]
203.0.113.150/32   dev lo [EXTERNAL 19:42] * I (150/0) [0.0.0.100]

The kernel routing table is similar except it does not contain the static route.

Adding more redundancy The first goal of this lab was to test multiple OSPF instances and ECMP with BIRD. It could be completed:

• Adding a redundant VPN is easy: this is just a matter of duplicating the setup of the existing VPN.
• Each router should be redundant by getting a sibling with the same configuration. In the case of R1 and R2, a VIP could be shared between the router and its sibling with VRRP to allow hosts behind to have a single gateway and not use a routing protocol.
• Because of the use of static routes instead of BGP, there is nothing to detect a VPN failure (which may be problematic if we setup a redundant VPN). Some VPN are able to invalidate a route when the associated VPN is down. This is not our case. Moreover, there may be some duplication in routing. This is not the case here because each site has its own internal network.

The goal of this lab is to setup a site-to-site IPsec VPN. This lab is similar to my first lab using UML. The major differences are:

• We only setup one VPN instead of two.
• Static routing is used in place of BGP for inter-site routing. Moreover, BIRD is used as a routing daemon.
• VPN are using an external network for Internet access.
• Both internal network and external network are redundant using one OSPF instance each.

The lab

The big picture The main point of this architecture is that you get two redundant networks for each site. The external ones are used when hosts need Internet access. The internal ones are used when they want to communicate with each other. Because we don t want hosts from the first site to communicate with hosts from the second site through the external network, we extend the internal network with the help of a site-to-site IPsec VPN. Each set of networks is using two layer-3 networks on top of two layer-2 networks. OSPF is used to provide redundancy and aggregation. For example, R1 has two routes through V1 to access R2 which is on the other site:

# ip route show 192.168.96.0/19
192.168.96.0/19  proto zebra  metric 10000 
        nexthop via 192.168.1.100  dev eth0 weight 1
        nexthop via 192.168.2.100  dev eth1 weight 1

Setting up the lab First, grab the source of the lab:

$ git clone https://vincentbernat@github.com/vincentbernat/network-lab.git
$ cd network-lab/lab-s2s-vpn

You may try to run ./setup directly. It may be safer to build an image of Debian inside inside a directory and use it as a base for the lab.

$ sudo debootstrap sid ../sid-chroot http://ftp.fr.debian.org/debian/
[...]
$ sudo chroot ../sid-chroot /bin/bash
# apt-get install iproute zsh rsyslog less makedev tcpdump
# apt-get install bird quagga racoon
# exit
$ ROOT=../sid-chroot ./setup

You still need a working UML kernel. On Ubuntu, the one provided in user-mode-linux does not contain the aufs.ko module. I did not find a simple workaround. You can just grab the package from Debian and install it on your Ubuntu with dpkg -i.

Use of BIRD With the previous lab, Quagga was used as an OSPF routing daemon. We still use it on R1, R2, E1 and E2. However, Quagga is not able to run multiple instances of OSPF. BIRD can. Therefore, we use it on V1 and V2 because we need two OSPF instances: one for the external network and one for the internal network. Since we also need ECMP, we need at least BIRD 1.3.0. BIRD allows the definition of multiple routing tables. Those tables are independant of the kernel routing tables. Each protocol will maintain its own set of routes and will allow to export (or import) routes from one of the routing table maintained by BIRD. In our setup, we use four protocols and only one routing table (the default one). The ospf EXTERNAL protocol is one of the two OSPF instances we use on V1. We import all the routes learned through the OSPF process into the internal BIRD routing table. We don t export any route from the BIRD routing table to this OSPF instance. Here is the configuration of this protocol:

protocol ospf EXTERNAL  
   ecmp yes;
   import all;
   export none;
   area 0.0.0.0  
      networks  
         203.0.113.0/26;
         203.0.113.64/26;
         203.0.113.150/32;
       ;
      interface "eth2";
      interface "eth3";
      interface "lo"  
        stub yes;
       ;
    ;
 

203.0.113.150/32 is defined on the loopback interface of V1. This is the IP of the local VPN endpoint. The ospf INTERNAL protocol is the second OSPF instance. We import all routes from this protocol to the BIRD routing table. We also want to advertise the route to the remote site. This route is defined in the static STATIC protocol and imported into BIRD routing table.

protocol static STATIC  
   import all;
   export none;
   route 192.168.96.0/19 via "lo";
 

Therefore, ospf INTERNAL protocol export all routes originating from the static STATIC protocol. This is done using filters:

protocol ospf INTERNAL  
   ecmp yes;
   import all;
   export filter  
     if proto = "STATIC" then accept;
     reject;
    ;
   area 0.0.0.0  
      networks  
         192.168.1.0/24;
         192.168.2.0/24;
       ;
      interface "eth0";
      interface "eth1";
    ;
 

The kernel protocol is managing one kernel routing table. By default, it handles the main table. We don t import any route from the kernel. However, we copy routes that come from other protocols, except the static route because we already have a default route and the static route is some kind of blackhole, we don t want to use it for real routing.

protocol kernel  
   persist;
   import none;
   export filter  
     if proto = "EXTERNAL" then accept;
     if proto = "INTERNAL" then accept;
     reject;
    ;
 

The filtering mechanism built inside BIRD is pretty powerful.

Testing After starting the lab, you need to wait a few seconds. You should then be able to ping R2 from R1:

R1# ping -c3 -I 192.168.15.1 192.168.115.1
PING 192.168.115.1 (192.168.115.1) from 192.168.15.1 : 56(84) bytes of data.
Warning: time of day goes back (-5435us), taking countermeasures.
64 bytes from 192.168.115.1: icmp_req=1 ttl=62 time=0.921 ms
64 bytes from 192.168.115.1: icmp_req=2 ttl=62 time=0.569 ms
64 bytes from 192.168.115.1: icmp_req=3 ttl=62 time=0.698 ms
--- 192.168.115.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2009ms
rtt min/avg/max/mdev = 0.569/0.729/0.921/0.147 ms

On V1, you can check BIRD internal routing table using birdc:

> show route 
0.0.0.0/0          multipath [EXTERNAL 19:43] * E2 (150/10/1) [0.0.0.11]
        via 203.0.113.1 on eth2 weight 1
        via 203.0.113.65 on eth3 weight 1
192.168.96.0/19    dev lo [STATIC 19:42] * (200)
192.168.1.0/24     dev eth0 [INTERNAL 19:42] * I (150/10) [0.0.0.100]
192.168.2.0/24     dev eth1 [INTERNAL 19:42] * I (150/10) [0.0.0.100]
192.168.15.0/24    multipath [INTERNAL 19:43] * I (150/20) [0.0.0.10]
        via 192.168.1.10 on eth0 weight 1
        via 192.168.2.10 on eth1 weight 1
203.0.113.0/26     dev eth2 [EXTERNAL 19:42] * I (150/10) [0.0.0.100]
203.0.113.64/26    dev eth3 [EXTERNAL 19:42] * I (150/10) [0.0.0.100]
203.0.113.150/32   dev lo [EXTERNAL 19:42] * I (150/0) [0.0.0.100]

The kernel routing table is similar except it does not contain the static route.

Adding more redundancy The first goal of this lab was to test multiple OSPF instances and ECMP with BIRD. It could be completed:

• Adding a redundant VPN is easy: this is just a matter of duplicating the setup of the existing VPN.
• Each router should be redundant by getting a sibling with the same configuration. In the case of R1 and R2, a VIP could be shared between the router and its sibling with VRRP to allow hosts behind to have a single gateway and not use a routing protocol.
• Because of the use of static routes instead of BGP, there is nothing to detect a VPN failure (which may be problematic if we setup a redundant VPN). Some VPN are able to invalidate a route when the associated VPN is down. This is not our case. Moreover, there may be some duplication in routing. This is not the case here because each site has its own internal network.