Today I upgraded my BIOS in the hope to solve various issues. When I rebooted the machine, it didn’t get an IP address through DHCP: the Ethernet MAC address has been changed by the BIOS upgrade.
Now compare the old and the new Ethernet MAC addresses:
old address: 0:1a:4d:60:72:e0
new address: e0:72:60:4d:1a:0
Time to laugh…
ldmeqib r9!, {r1, r8, ip}^
ldclsl 3, cr14, [r4, #-364]!
stmleda r1, {r0, r2, r6, r7, r9, sl, ip, lr}^
cmppl r6, #12582912
This program does not work, but it still has a meaning.
Hint: Each instruction is 32-bit long, the total length is 128 bits.
I am really upset by the way the ARM build daemons are managed. The packages are not uploaded regularly, with sometimes three days between two uploads. Well it should not be a problem, if packages that have failed to build due to some packages not uploaded fast enough (see for example python-gnome, or rkward) were requeued, but that’s actually not the case. Also last week, the build daemon named “cats” stopped to upload packages, despite it continued to build them. 11 days later, nothing has changed even after a mail to arm@buildd.debian.org. And I do not speak about build daemons building nothing.
All of that resulted in ARM being the slowest architecture to build packages. It looks like the ARM build daemon maintainer does not know the excellent page made by Jeroen.
As arm@buildd.debian.org is everything but responsive (well if you can assign a level of responsiveness to /dev/null), I have decided to act. I have installed QEMU on an 8-way Opteron machine, and created 8 emulated ARM machines, which 256MB of RAM and 10GB of disk for each, all running buildd + sbuild. Altogether those 8 emulated ARM machines should be faster than all the Debian ARM build daemons. I have setup a wanna-build database on my server. During the day it has built around 100 packages.
Yes I agree that real machines would be better, but I don’t have a stack of fast ARM machines at home. Anyway when you see random segfaults on the build daemons, or strange failures (that happen for weeks) on the build daemon named “netwinder“, you may think to that again.
Unfortunately the machine I use for that is only available for a few months, and I will have to stop the emulated machine then. I just hope that the situation with respect to the build daemons will improve, so that I can stop them even before.
In addition to the ARM platform, it is now possible to emulate a MIPS (big endian) or MIPSEL (little endian) machine running Debian under QEMU. It could be used as a cheap MIPS/MIPSEL development machine to test your packages, provided that you have a not to slow i386, AMD64 or PowerPC computer.
Running on an Athlon 64 X2 3800+ the emulated system is around 10% faster than my SGI Indy R4400SC 200MHz and possibly with much more RAM (my emulated system has 512 MB of RAM). Also for the ones who know about the Indy SCSI controller, the transfer rate is around 13 MB/s on the emulated system.
I have written a small howto explaining how to install Debian Etch on such an emulated MIPS or MIPSEL machine, using Debian-Installer RC1, which has just been released.
Thanks to Daniel Jacobowitz who has recently improved QEMU/MIPS a lot, and to Thiemo Seufer who has started the integration of the MIPS QEMU platform in Debian-Installer and in the Debian kernel.
Note 1: I have written this howto very quickly, so there are probably some mistakes. Comments are welcome.
Note 2: I have updated the ARM howto to take in account improvements from Debian-Installer RC1
Martin, I can’t let you say that experimental is autobuilt. I have uploaded a few versions of the glibc to experimental in the last few months and only arm, hppa and alpha have tried to build them. Before the summer mips and mipsel also have tried to build the experimental glibc. And the last version has not been tried on alpha, despite the fact it includes a fix and should now build correctly on this architecture.
Hopefully I have most Debian architectures at home, but alpha, m68k and ia64, so I can build the glibc on my own machines. For m68k and ia64, I can use debian.org machines. Concerning alpha, the debian porting machine, ie escher.debian.org, is locked down since the compromise about 4 months ago. And no answer to my mail to debian-admin… Hopefully a user kindly gave me an access on his machine, thanks. The glibc 2.5 is now building correctly on this machine, but I can’t upload the package because I can’t trust the machine. That really sucks.
What about removing alpha from the release architectures? After all, it fails to comply with the etch candidate release architecture criteria for months.
Update: Some build daemons had glibc in “weak-no-autobuild”. Thanks Martin for fixing that.
You want a cheap ARM development machine to test your packages? You can actually have one for free (both as in beer and as in speach 
) provided that you have a not to slow i386, AMD64 or PowerPC computer. The solution is called QEMU, a generic and open source processor emulator which can emulate i386, x86_64, ARM, MIPS, PowerPC and Sparc systems.
Running an Athlon 64 3800+ the emulated system is around 20% faster than the popular NSLU2 and possibly with much more RAM (my emulated system has 256 MB of RAM).
I have written a small howto explaining how to install Debian Etch on such an emulated ARM machine.
Note: I have written this howto very quickly, so there are probably some mistakes. Comments are welcome.
I gave a talk about Debian GNU/kFreeBSD at FOSDEM 2006. It tooks me time, but I finally have made the slides available.
Yesterday I have setup a kfreebsd-amd64 (ie GNU/kFreeBSD on an amd64 CPU) build daemon. Its name is shockley.aurel32.net (all my machines are named related to electronics), and it has Sempron 2600+ CPU.
As you can see on the photo, it is still missing a decent case. There are actually two machines on the the photo, the motherboard in the case is maxwell’s one (one of the kfreebsd-i386 build daemon), while the one on the top front is shockley’s one. That’s a bit strange, but the amd64 motherboard needs a power supply with a P4 connector, while the other one only needs a small power supply.
Thanks to Ingo Juergensmann, the kfreebsd-amd64 architecture is now listed on http://buildd.net. As you can see on the graph, this machine is very fast (it only runs for 24 hours!).
Thanks to Ingo Juergensmann, the kfreebsd-i386 architecture is now listed on http://buildd.net. That means that Debian developers can now easily check the state of their packages, and if they fail to build, to find why.
The requirement to appear on http://buildd.net was to use wanna-build and make its output available somewhere on the web. As I was still using a set of (very) ugly shells scripts to handle the build-daemon, I spent a part of the last days to setup wanna-build, and to understand how it works. With wanna-build a lot of thing is automatic, and almost everything could be controled via the mail interface. That would save me some time that I could invest in porting packages to GNU/kFreeBSD.
The machine on the photo below is currently somewhere between France and Switzerland. It runs Debian GNU/kFreeBSD, and will be accessible to all Debian developers. Thanks to Gürkan Sengün, the ETH Zürich will host it.
I am running a build daemon for the Debian GNU/kFreeBSD port. It was a bit overloaded by the high number of packages to build since the CXX ABI transition has begun. I decided to use the old mainboard of my main computer to upgrade it from an AMD K6-2 500 to an Athlon XP 1800+. I also had to buy a new box since the old mainboard was an AT one, whereas this mainboard is an ATX one. The hard disks (an old 8.4 GB IDE disk for the system and an old 4.3 GB SCSI disk for the build daemon stuff) are still a bit slow, that is probably the next thing I’ll upgrade.
It runs for a few hours now and has already reduced the backlog. Currently 83% of the Debian packages are built for the kfreebsd-i386 architecture.
I have just upgraded my main computer with a new motherboard and a new CPU. It now has and Athlon 64 3000+ CPU, it is a lot faster than my old Athlon XP 1800+.
I have four SATA disks in a software RAID 5 array, and with my old mainboard the SATA controllers were on two PCI cards. The PCI bus was limiting the maximum transfer rate to about 60 MB/s. My new mainboard has an NForce 3 chipset, which has two SATA controllers connected directly to the HyperTransport bus, so that I can reach 158 MB/s. That’s a great improvement!
I have a total of 5 hard-disks, 1 DVD-ROM drive and 1 DVD-RW drive resulting in a lot of cables and a big mess in the mini-tower box, as it could be seen on the photo below. Hopefully I now have less PCI cards as the soundcard, the SATA controllers and the ethernets controllers are now integrated on the mainboard.
Now that the hardware is setup, I’ll have to look at the software, as my computer is still running in 32-bit mode.
Sam has got a laptop with a very strange keyboard. Have a look:
No, it’s not a DVORAK one.
Actually he explained me he tried to convert the QWERTY keyboard into a DVORAK one, but some of the keys can not be swapped because of the trackpoint. And he is using it as a QWERTY keyboard.
I have got two hardware problems today.
First my UPS died, leaving my servers at home as well as my ADSL modem without any power. The bad thing is that I am not at home, but in Helsinki for Debconf 5, so I had to managed to get it replaced by simple wires, by phone. That was not that easy, because the person that did the changes (thanks a lot Dominique) hasn’t my keys, and thus have to get it first.
The second problem I got today concerns my laptop. It seems the memory has not supported the flight to Helsinki, and I had to remove half of it 
During the last few days, I experienced a high load on my server (sometimes up to 15). Each time it happens, I observed that apache was unable to serve pages. Restarting it regularly seemed to fix the problem.
Yesterday, I started to investigate the problem. Actually it was “referer spam”. The stats of my blog are generated with webdruid and are available on http://blog.aurel32.net/stats/ . Some spammers tried to increase their website’s page rank by submitting spoofed referers. It seems that they use zombie hosts, as the requests come from many IPs. The bad thing is that the hosts don’t close the TCP connections, causing a lot of apache processes to be unable to serve pages. It’s like a DoS, though this was not the aim.
A search on Google gave me a way to stop that. I added the following lines to /etc/wordpress/htaccess:
RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://www.spammersite1.com [OR]
RewriteCond %{HTTP_REFERER} ^http://www.spammersite2.com
RewriteRule .* - [F,L]
The load started to go down. Good! I also added a robots.txt, so that the stats pages are not indexed anymore by the search engines (note to the wordpress maintainer: it would be nice to have a /etc/wordpress/robots.txt).
After a day, I grepped the apache logs to find all the zombies IPs, and I blacklisted all of them on my firewall with iptables, ie. 217 IPs!
This event reminds me that my server doesn’t have enough RAM and that I should add some more.
My ADSL line was opened yesterday, so I am back on the Internet! Actually during the last two months, I still had an Internet connection, but only though a 56k modem, not really useable for maintaining Debian packages or for doing an “apt-get upgrade” on my machines (and a bit costly).
I am in my apartment for a month, and it tooks two weeks to get the invoice of my telephone line, one more week to get the ADSL line and one more week to get my modem from the post.
The connection is an ADSL2+ connection, so there is enough upload rate to be able to host websites. I moved all my websites to my home server, and I am just waiting the activation of the reverse DNS to be able to host an SMTP server.
In my latest post (Switching to kernel 2.6), I spoke quickly about my firewall. In the comments, I was asked for information about it. So I decided to write a new post.
My firewall is based on a micro-ATX PIII mainboard with an Intel Celeron 600. I know that it is too much for my use (the load is almost always 0), however I already had the mainboard. This processor is one of the slowest processor that the mainboard accepts (the lowest speed is 500 MHz). Anyway that kind of processor is a good choice for such a computer, as it is one of the first processor using a 0.18µm technology, thus it doesn’t need a lot of power (for an x86). Using an Aqua 690 heatsink it can run without a fan.
This mainboard has an integrated Ethernet adapter, and 3 PCI ports. I chose to use them to plug three Ethernet adapters, that is to say a total of four. Currently three of them are setup in bridge, but I can later un-bridge one or more ports if I need. It could be useful to plug a WiFi access point, or to create a DMZ for my servers (just for the fun as I am the only user of my LAN).
Instead of using an hard-drive, that makes noise and heat, I chose to use a 256MB Compact Flash instead. I made a CF/IDE adapter using the article published in Elektor (April 2002 for the French edition). It is now possible to find such an adapter in some webshops.
I packed all that stuff in a metal box, with a 120W Shuttle Power Supply. The longest part was to machine the metal, with a drilling machine and a file in my case.
On the software side, this firewall is running Debian, with two scripts of my own using iptables: one for IPv4 and one for IPv6. 256 MB is enough for that and some useful packages (ADSL modem drivers, radvd, ping, traceroute, tcpdump, ethstatus, lm-sensors, snmpd, ntp, logcheck, etc.).
Below is a photo of the inside (sorry for the poor quality, I took it with my webcam as I still don’t have a digital still camera):
You can see a fan grille on the front, however there is no fan behind it. I removed it as it was making noise, and was not really necessary. Concerning the processor’s fan, I control it using lm-sensors, and it is almost always off, resulting in a very silent firewall.
I used the same box for my servers, however they are using an hard-drive. It is possible to put up to two hard-drives (useful for RAID1) in a such box, if you are using low profile RAM.
