My new apartment

Yesterday I moved to my new apartement. Moving was not really easy as it was running cats and dogs. The apartement now looks a bit empty, as I currently only have a camping mattress, a sleeping bad, a few clothing, without forgetting my computers... I need to buy a mattress, a fridge, solid plates, etc.

In the next few days, I'll have to open a telephone line, with an ADSL connection. I hope it wouldn't take too much time, as it's not very easy to only have an Internet access at work. That's why I am not so active into Debian by now, though I am still reading my mails and uploading packages.

Switching to kernel 2.6 (part 2)

Yesterday I switched all of my machines but one to kernel 2.6. The last one to migrate is a SparcStation 4. It is a little bit complicated as the BIOS refuse to recognize my hard-drive since I changed it from a 2.1GB one to a 9.1GB. After an afternoon of tests, I decided to boot this workstation via the network, as the Linux kernel recognizes it.

Using a 2.4 kernel was very easy, you just have to convert the Debian kernel in aout format using zcat and elftoaout. For a 2.6 kernel, it is a little more complicated as Debian ships them with an initrd image. After a few minutes searching google, I found the solution:

zcat /boot/vmlinuz > vmlinux
elftoaout -o netboot.img vmlinux piggyback netboot.img /boot/System.map /boot/initrd.img

It seems to work well, however the image is 271,654,944 bytes long. I still don't understand why.

Switching to kernel 2.6

I decided to switch all my machines to kernel 2.6. I now consider the kernel 2.6 stable enough, at least for the use of my machines. Except for my workstation on which I like to add some patches, I am using Debian kernels for my other machines. Moreover some of them are very slow (a parisc@60 MHz and a sparc@110 MHz), and building a kernel on such machines takes very long time.

I started with my a backup server, it was very easy, apt-get install and voilà!

Then I switched my firewall. It was not so easy as for my backup server, as I only have a 256 MB disk (actually a compact flash card). Because of its size, it was not possible to have two kernels at the same time on the disk. I decided to remove the old 2.4 kernel (/boot and /lib/modules), to install the new 2.6 kernel. Then I typed reboot, and started to pray. As I don't have neither a display nor a keyboard on that machine, I started to look both at the hard disk's LED and at a console on my workstation on which I started ping fourier. After a some time (I don't know exactly how much, in such situations seconds are like minutes), there was some echo reply. Wonderful!

After such successes, I decided to continue and to switch my hppa machine. Again apt-get, then a quick look at the palo's documentation to know how to specify an initrd image, and then reboot. After a lot of time, it was still not possible to ping the machine. Shit! PALO has the possibilty to specify an alternate kernel in case of a problem, however in that case it seems it has failed... or the boot was mabe successfull. Half an hour later, after I plugged a screen, a keyboard and a null-modem serial cable, I understood the problem: the module for the network card was not loaded (whereas it was directly binded into the 2.4 kernel). And hotplug doesn't load it as it is not on a PCI bus. I tooked my keyboard and started to write my login. Nothing. The keyboard's module was also not loaded. I switched back to the 2.4 kernel, I put a lot of modules into /etc/modules (network card, keyboard, mouse, sound card, parallel port, serial port, etc.). And it worked!

Moral: Don't change your kernel when you only have very few time to do that. It always take a lot longer than expected.

Fixing gcc-m68h1cx

Today, I spent all the day fixing gcc-m68hc1x. It is gcc built for cross-compiling to 68HC11 and 68HC12 microcontrollers. There was a strange bug: an ICE on 64-bit hosts. Actually the bug was there for a long time, but I had decided that the version currently in testing will be enough. However, yesterday a bug was filled as a package need to build it was not available anymore in testing.

So I started to try to debug it. It was the first time I was looking at gcc's sources. Whow! I didn't know were to start to find the bug. I asked on IRC on #gcc, but people were no encouraging me: "aurel32, that bug is not easy to tackle for newbies". I first reduced the file causing the ICE to a single line in a function, I added a lot of printf in gcc's sources, and then tried to compile the same testcase both on a 32-bit host and a 64-bit host. At the end of the day I found some differences, and with that, the bug!

As the ICE was triggered by the build of libgcc2, gcc-m68hc1x was unbuildable on 64-bit hosts. Now that this bug is fixed, it means one RC bug less.

And in short for any people writing code: please don't assume that a 64-bit number needs two int to be represented!