Frans Pop reported recently that the initramfs did not fit in the flash of the QNAP TS-109 when you used LVM. We had problems with initramfs images that were too large before (on the NSLU2). By default, initramfs-tools uses the MODULES=most setting which puts all modules that might be of interest to booting a machine in the initramfs. This is a good idea on a PC where the hardware can change a lot, but it makes less sense on most NAS devices.

Frans has now changed debian-installer so the MODULES policy can be chosen during the installation. His change allowed architecture specific defaults, so I've changed ARM to use MODULES=dep. debian-installer will now create the file /etc/initramfs-tools/conf.d/driver-policy with a MODULES setting that will override that from /etc/initramfs-tools/initramfs.conf. On QNAP devices, I intend to only support MODULES=dep installations, so please change your configuration if you've installed Debian already. On the NSLU2, MODULES=most will of course continue to be supported.

Someone asked me the other day what it would take to add Debian support for the D-Link DNS-323. Since we support a number of Orion based devices in debian-installer already, adding support for another device is typically fairly easy. I don't have a D-Link DNS-323 myself, but I looked around the useful DNS-323 wiki and this is what I came up. I'm sharing this list in the hope that other people are interested in working on DNS-323 support.

• The Orion kernel in Debian has support for the D-Link DNS-323 but it needs testing. Also, some patches, such as support for the fan speed chip, are not included in the mainline kernel yet.
• flash-kernel (which writes the kernel and ramdisk to flash) needs support for the DNS-323. I actually implemented this in the meantime but it's completely untested.
• oldsys-preseed reads the network configuration from your existing firmware and uses it to configure the network for debian-installer. This also needs support for the DNS-323.
• Some tools to generate proper firmware images need to be packaged for Debian.
• The debian-installer needs to generate a boot image for the DNS-323 (easy once the tools are packaged).
• Apparently the MAC address is not set automatically in u-boot and you have to run a tool called mac_read to set it. This is problematic because at the moment there's no code to set the MAC address in d-i and to make sure the newly installed system will automatically set the MAC address. This needs some work.

Otavio has updated kernel-wedge in SVN to 2.6.26, so I updated ARM and MIPS today. The udebs built after minor modifications and I can also build installer images after having fixed some bugs in the build process. I tested a 2.6.26 based image on the QNAP TS-409 (armel) as well as in QEMU (mipsel).

2.6.26 will bring major improvements on ARM. Orion support is much better and our 2.6.26 has a number of patches from Marvell that help with performance on Orion. Our 2.6.26 also has Riku Voipio's LED driver for Thecus N2100 which has been accepted for the 2.6.27 mainline kernel.

I haven't actually uploaded the udebs yet because I'm waiting for the go-ahead as well as for the new version of the 2.6.26 kernel package to build. But at least we're getting closer to having 2.6.26 as the kernel for lenny.

I've created a web site with information for running Debian on the HP mv2120. The HP mv2120 is a NAS device based on Marvell's Orion platform and has a 500 MHz ARM CPU, 128 MB RAM and two SATA slots.

All components needed to support Debian on the HP mv2120 have been integrated into Debian and Debian installer. However, a new release of the Debian installer is required so installations of Debian testing are actually possible.

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.

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.

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.

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.

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.

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.

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.

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.

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 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'

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.

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.

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.

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

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

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: