Daily installer image available for QNAP TS-109, TS-209 and TS-409

Daily installer images are now available for the QNAP TS-109, TS-209 and TS-409. This means that complete installations of Debian testing are possible now.

You can consider the daily image as a beta release of RC1 of the debian-installer for Debian lenny. It should only be used by experienced users and only if you can make a serial console in case something goes wrong. As the name suggests, the daily images change on a daily basis and they install Debian testing which also changes on a daily basis (although testing should be fairly stable since we're close to the freeze of testing in preparation for the release of Debian lenny).

If you install Debian with these installer images, please send an installation report to debian-boot send an email to me so I can let you know in case there are any important news you should be aware of.

There is a web site now with complete installation instructions and other information about Debian on QNAP Turbo Station. If you have any questions or suggestions, please let me know.

New behaviour for oldsys-preseed regarding default settings

I've just changed the behaviour of oldsys-preseed in the case when a static IP address is set in the configuration of the device that is the default setting from the vendor. In the past, oldsys-preseed would try to be smart in this case and do DHCP in the assumption that the users never configured the static IP address themselves and might not want to have that setting. However, Mike (mwester) convinced me that doing DHCP when the configuration clearly says to use a static IP is a bad idea. Apparently quite a few users got confused by the old behaviour of oldsys-preseed. The new behaviour exists as of version 2.0 of oldsys-preseed which will be in rc1 of debian-installer for lenny. This change affects the Linksys NSLU2 and Thecus N2100.

Debian support for HP mv2120: putting everything together

I managed to get my hands on a HP Media Vault mv2120, a nice ARM based NAS device, a few months ago with the intentions of porting Debian to it. Unfortunately, I have been really busy lately and most of my time was spent on adding support for the QNAP TS-109/TS-209 and TS-409 (which required a lot of generic work to get Marvell Orion support into Debian, a new SoC used in many NAS devices, including the QNAP TS-x09 and HP mv2120).

There were a number of things that had to be worked out before Debian would run on the mv2120. The good news is that Marc Singer and Eugene San have done all of the heavy lifting in the last few weeks in figuring out how the mv2120 works and that now it's just a matter of putting everything together for Debian to work.

Here are the issues that had to be worked out:

• Figure out how the rescue mode works and how to construct a rescue image that the device can boot: I knew that the mv2120 had a rescue mode that can be activated by keeping the the power and reset buttons pressed when starting that would request a rescue image via the network. This rescue mode can be used to start the Debian installer. Eugene San figured out how to construct a rescue image that the mv2120 would accept. Marc Singer has also written a tool, uphpmvault, to serve such rescue images from Linux.
• Figure out the best way to make one image that contains the kernel and ramdisk: the mv2120 only loads a kernel and no ramdisk, but a ramdisk is needed to start Debian. I discussed some really ugly hacks with Marc Singer to get the mv2120 to accept an image consisting of kernel and ramdisk but Marc wanted to try something else first. u-boot, the boot loader used on the mv2120, can accept something called a multipart image which can consist of a kernel and a ramdisk. When Eugene San heard that we were trying to load a multipart image, he went ahead and figured out how to construct an image that the mv2120 would boot.

Now that these two issues are resolved, I simply need to put everything together and add support for the mv2120 to a number of debian-installer components. We already have Orion kernel images in unstable that support the HP mv2120 (along with a number of other Orion based NAS devices) and the rest shouldn't take too long.

NSLU2 Debian installer for lenny beta 2

The Debian installer team has published the second beta release of the installer for lenny (what will become Debian 5.0). I repacked the image for the Linksys NSLU2 with the proprietary IXP4xx microcode so Ethernet will work.

The installer is now available in two flavours for the ARM architecture: arm is the old ARM port whereas armel is the new ARM port using the EABI which offers better support for floating point and other features. Both the arm and armel architectures will be supported for lenny but the old arm port will be dropped after the release of lenny. At this point, I therefore recommend that people use armel for new installations.

The beta 2 installer image for NSLU2 can be found on my site: armel image (recommended) and arm image.

The NSLU2 causing trouble recently...

We've had two serious bugs on the NSLU2 recently that both caused the system not too boot anymore. The first one was related to initramfs-tools. Kevin Price reported that after upgrading to initramfs-tools 0.92 the system would hang during boot waiting for the root filesystem. When I booted my NSLU2 and looked at the output, I noticed that no root device was set. When I mentioned this to maks, the maintainer of the initramfs-tools package, he immediately knew what was wrong and uploaded a fix. On the NSLU2, the boot loader doesn't pass a root device to the kernel so we set one in the initramfs itself. The code that loads this config variable is not used by many devices so nobody noticed that this got broken in 0.92 until the package moved to testing.

The second problem, reported on Saturday by Paul Collins and diagnosed today with some help from Kevin Price is also related to the strange way the NSLU2 boots. The NSLU2 has 6 MB available for the ramdisk but due to a bug in APEX (the second stage loader used on the NSLU2 by Debian) only 4 MB are actually used. When you write a ramdisk that is larger than 4 MB but smaller than 6 MB, flash-kernel will happily write the full image, but APEX will only tell the kernel about the first 4 MB. As it turns out, everything works fine on arm with 2.6.25, but on armel some additional SCSI modules are enabled that result in the ramdisk becoming too large. The short term solution is to disable these modules, but really APEX should finally be fixed (patches have been available for quite a while thanks to Gordon Farquharson). Fortunately 2.6.25 hasn't moved to testing yet and this problem only occurs on armel, so few people were impacted.

The nice thing about the NSLU2 is that you can write a new flash image via the network, so you can flash a good image in case your machine no longer boots. Nevertheless, we have to make sure such serious bugs don't occur in the future or that they are at least caught very early. Special thanks go to testers like Kevin Price.

QNAP TS-109/TS-209 and TS-409 experimental developer release

Yesterday I completed the first successful installation of Debian on a QNAP TS-209 using a custom debian-installer image with 2.6.25 from unstable. I made the installer image for QNAP TS-109 and TS-209 available as an experimental developer release and today I also uploaded images for the TS-409. More on my plans to support the QNAP TS-109/TS-209 and TS-409 in the upcoming release of Debian (starting with beta3 of debian-installer) soon.

GCC 4.3 porting guide

Benjamin Kosnik of Red Hat put together a guide on the GCC web site with information on porting applications to the upcoming GCC 4.3 release. He integrated some information from my blog and added a number of new items. If you run into any issues while moving to GCC 4.3, I suggest you consult this guide.

Installer finally working again on Linksys NSLU2

The release release team of Debian released 4.0r2 today which fixes the bug that kept the installer from working on ARM based systems, such as the Linksys NSLU2. This means that installations are finally possible again. I've updated my installation instructions accordingly.

I've also updated the tar ball used for the manual installation to 4.0r2 but I doubt many people are interested in this method now that the installer is working again.

Joining HP

I joined HP's Open Source and Linux Organization (OSLO) at the beginning of the month as an Open Source Community Expert. I spent the last three weeks in Ft. Collins for some training and to get to know the team, but normally I'll be working from home in Europe. The main focus of my work will be governance issues related to the deployment of FOSS in enterprise environments. However, I've already started to get involved in a number of other areas I'm interested in, such as community relations. I'm pretty excited about my new position because it is a good fit for my skills and interests.

GCC 4.3 related build problems: duplicate function parameters

GCC 4.3 now prints an error message when C++ code contains duplicate function parameter names in function prototypes. You'd think that's a pretty obvious problem, but we still have about 15 packages in the archive that contain such code.

Anyway, for code like this:

class foo {
    foo(int w, int w);
};

GCC will as of 4.3 show the following error message:

t.cc:2: error: multiple parameters named 'w'

N2100 network troubles due to r8169 bug

Daniel Smolik reported problems with NFS on a Thecus N2100 a few days ago. I confirmed the bug with 2.6.18 and 2.6.22 but found that the problem didn't occur with 2.6.23. I started a git bisect and a few hours later located a fix that Francois Romieu, the maintainer of the r8169 driver, had put in. Apparently the driver had some confusion regarding hardware and IP header alignment. The good news is that the patch is very small and can easily be backported to our 2.6.18 kernel in stable. Also, packages of 2.6.23 were uploaded today and should be in the archive soon.

Tips on reducing memory and running Linux on a flash device

David Härdeman has contributed two really valuable guides to my Debian on NSLU2 site that will be of great interest to many NSLU2 users:

• The first guide is for people running Linux on a flash device, such as a USB flash stick. Since flash only supports a limited number of writes, it is important to reduce the wear and tear on the underlying flash device. David's guide gives some practical advice of how to achieve this.
• The second guide gives a few tips and tricks that can be used to reduce the amount of RAM a system uses. This is particularly interesting to NSLU2 users since 32 MB of RAM is not a lot.

These guides mention Debian but most of the advice applies to other NSLU2 firmware flavours and to Linux in general.

NSLU2 tar ball for Debian 4.0r1

I updated the tar ball for the manual Debian/NSLU2 installation to Debian 4.0r1 (including the new 2.6.18-5 kernel) today. The proprietary NPE microcode from Intel is now included in the tar ball since the code no longer has a click-through license.

Dr Michlmayr

Having passed all requirements for the Doctor of Philosophy, I had my graduation today.

GCC 4.3 related build problems: pedantic preprocessor warnings in C++

Update: This change has been reverted from 4.3 again and won't be in the final release of 4.3.

GCC 4.3 changed pedantic preprocessor warnings in C++ code into errors, in line with the C++ front-end. Because of this change, preprocessor warnings are now errors.

This change has caused at least the twofollowing errors which are all fairly common:

error: "xxx" redefined

It's not allowed to #define something twice, as in this example:

#define TEST "foo"
#define TEST "bar"

This code will lead to the following error:

test2.cc:2:1: error: "TEST" redefined
test2.cc:1:1: error: this is the location of the previous definition

Most typically, this occurs because something is defined in a header that is included and then redefined in the current source file. It can also happen when a #define is put in the code but also on the command line, e.g. via -DTEST="bar". This will lead to:

test2.cc:1:1: error: "TEST" redefined
<command line>:1:1: error: this is the location of the previous definition

The correct solution is to avoid redefinitions directly or to use #ifndef to make sure that something has not been defined already.

extra tokens at end of #endif directive

While an #ifdef obviously needs a second parameter, it's not allowed to give one to #else and #endif. Unfortunately, this is commonly done as a reminder for what is being tested for:

#ifdef TEST
#endif TEST

This code will lead to the following error:

test3.cc:2:8: error: extra tokens at end of #endif directive

GCC 4.3 related build problems: missing #include

In GCC 4.3 the C++ header dependencies have been cleaned up. In the past, compilation would often be quite slow because including a simple header would indirectly include a lot of other headers, even if they were not needed to compile the current code. Many headers have now been cleaned up with the result that compilation is quicker. The downside is that programmers cannot rely on indirect inclusion of headers they may need anymore. Instead, everything that is needed has to be directly referenced with an #include.

Typical errors look like these:

error: 'find' is not a member of 'std'
error: 'exit' was not declared in this scope

Below is a table showing which header needs to be included for a number of common functions:

Functions and defines	Header
find, for_each, sort	algorithm
isalnum, toupper	cctype
INT_MIN, RAND_MAX	climits
printf	cstdio
atoi, free, rand	cstdlib
EXIT_FAILURE	cstdlib
strcmp, memcpy	cstring
auto_ptr	memory
fd_set, mode_t	sys/types.h
typeid	typeinfo

GCC 4.3: common build failures

Even though GCC 4.2 has seen many delays and still hasn't been released (although it's finally getting close), a lot of development has already been done on trunk for the release of GCC 4.3. I started testing 4.3 in March and in addition to finding and reporting compiler issues I have filed bugs on packages that fail to build with GCC 4.3. The idea is to give people an advance warning and to be ready for GCC 4.3 when it will be released.

We have almost 500 bugs related to GCC 4.3 already, mostly due to a clean-up of C++ headers in GCC that has exposed sloppy programming in many programs. Fortunately, these bugs are easy to fix. As I'm finding common mistakes in packages, I will document these problems and way to make sure a program is ready for GCC 4.3.

Common problems

• Missing #include directives
• Duplicate parameters in function prototypes

Update: there is now a GCC 4.3 porting guide that describes the most common problems people will face when moving to GCC 4.3.

Links

Here are a number of links to various postings and other information related to my research about release management in free software projects:

• Bruce Byfield wrote an article about my research for Linux.com.
• I recently gave a presentation about my research at Google as part of their Tech Talks series. A video of this talk is now available.
• MORITA Hajime kindly translated my blog postings about my research to Japanese.
• Matt Asay briefly discussed my work in his blog and relates it to commercial and proprietary software development. Roberto Galoppini relates my findings to his work and concludes that hierarchy is a must. Murray Cumming summarizes what he believes are the key findings of my research.

X.org

In previous times, most Linux distributions and other free software projects relied on the XFree86 system. Over the years, the structures within the XFree86 project became were rigid and the project failed to innovate and keep up with the pace of the wider free software community. When XFree86 changed its license in February 2004, the active community and the majority of vendors quickly moved to X.org. X.org is a very active community and they decided to break up the monolithic code base and to adopt a more modern build system. As of X.org 7.0, the project moved to the modular system in which components are developed and released separately. Effectively, the project introduced a development mechanism which features two release mechanisms: individual components can be released as needed and there is an overall release of X.org in which all stable components are put together. These roll-up releases take place every six months.

Version	Date	Months
7.0	2005-12-21
7.1	2006-05-22	5
7.2	2007-02-15	9

Past problems

• XFree86 made only infrequent releases every few years, had no plan, and the project's structures were very rigid.
• The code base was huge and monolithic. It had an archaic build system that few new developers were comfortable with. This made it hard for new contributors to get involved and was bad for testing.

Solutions

• X.org moved from a monolithic to a modular system. This made it easier to perform testing and it made it possible to give contributors write access to specific components.
• The move to the modular system allowed them the introduction of two release mechanisms: individual components can make releases on an ongoing basis and roll-up releases take place every six months.
• The roll-up releases have a fall back mechanism in case a specific component is not ready for release: the former release of this component can be incorporated.

Outstanding problems

• The project needs to work the interface between the server and drivers, so updates to hardware drivers can be released more often than other components.

Plone

Plone is a content management system that is built on the powerful Zope application server. The project experienced many delays with its 2.1 release. This made it difficult for Plone consultants to choose whether to use the old release or wait for the new one, and users faced many upgrade issues when 2.1 was finally released and had many changes. Partly to address these problems and partly in order to sync their releases with Zope, they decided in 2005 to move to a six month time based release cycle.

Version	Date	Months
1.0	2003-02-06
2.0	2004-03-23	13
2.1	2005-09-06	17
2.5	2006-06-16	9

Past problems

• Releases, in particular version 2.1, took a long time to get out.
• Releases had many changes and caused some migration problems.
• Many Plone developers work as consultants building web sites. Because of the unpredictability of Plone, it was difficult for them to decide which version to use for future projects.

Solutions

• Plone moved to a time based release, partly because the Zope framework on which it builds has done so. This allows them to make use of new Zope features in their software.
• Time based releases allowed the project to implement more structure. For example, new features have to be proposed as a Plone Improvement Proposals (PLIP) which the framework team reviews.
• Deadlines have motivated developers to get their features done within a certain time frame.
• Plone consultants can decide in advance which version of Plone to use for future commercial projects.

Outstanding problems

• As the project has moved to time based releases only recently, they still need to show whether they can consistently release on time.