Annvix Development Blog

I’m looking at possibly upgrading the build system for Annvix. It’s currently using a 3-year-old dual opteron system that’s starting to show it’s age (dual 1.8GHz, 2GB RAM).

The system I’m looking at replacing it with is a Sunfire X2200 M2 which would be a quad-core 2.6GHz opteron (dual CPU, dual core) with 4GB RAM. Suffice it to say, that’s a pretty good upgrade that will make compiling things much faster, not to mention save some energy by dropping from a big 3U system to a 1U system.

Problem is, even with Sun’s 25% off try-and-buy, it will still cost about $2750CAD (once you throw taxes and such in there). I don’t really have $2700 to throw at Annvix right now, but I think a new build machine is important (especially as I’d like to get more people involved and they would have access to the machine to compile stuff as well).

If I could raise even half of this in donations (let’s say $1500CAD), then it would be viable for me to invest the rest (including new/larger HDDs).

Donation “drives” for Annvix have rarely been successful in the past… I’m not sure if this time will be any different, but if you like and find Annvix useful, please consider making a donation. If you’ve thought of donating before but didn’t want it to just end up “somewhere”, at least now you’ll know it’s going into hardware (unless someone wants to donate an equivalent system?). Now would be a good time to donate if you’ve thought about it and haven’t done so in the past. This development machine would get quite a bit of mileage and would be a real boon to the project.

Info on donating can be found on the donations page. Thank you for the consideration!

I’ve put up a few boot charts on the website and compared Annvix boot time to Mandriva’s Corporate Server 4. I don’t mean to pick on CS4, but I think CS4 is pretty decent and pretty quick… and I had it on hand. I may add CentOS 5.1 to the page as well… I do have it installed in vmware.

While the charts themselves are kinda cool to look at, the thing that I think is really cool is the boot times: 12s on a default install and 12s with a half dozen services added and starting. In comparison, CS4 took 26s. These are in vmware, of course, with modest amounts of RAM allocated (although the host system is a mac pro running 2 2.66Ghz dual-core xeons).

Anyways, it’s interesting stuff… if you’re interested in that kind of thing (although, I think for a server OS the boot speed is a pretty minor consideration since it’s not supposed to be booting that often (and if it is, you have other problems)).

I have been running annvix as server, (e.g. email, DNS, web, source control…etc) since 1.0. Recently, I have been using it as development machines for my RD Department.

My group is focusing to embedded Linux development, which means we need to have a perfectly working (and standard compliance) machine to install tons of cross compilers and tools for each different Hardware/solution providers. The previous group was using mostly Fedora, Ubuntu based distributions, although they look ok at first glance, it fails in a lot of areas since Fedora and Ubuntu is trying to be too user friendly. This is especially true for Ubuntu, the shell script inside the Makefile doesn’t even work as ‘expected’ without some tuning. (trust me, I have used more than 5 well known distributions, ubuntu was very troublesome for embedded development environment)

Of course, my post is not about how bad other ones are, and how good annvix are. Different distribution serves for different purposes.

I just want to express my success with annvix distribution and proud to be one of the developer .

My RD department currently have one source control server and four development server (aka, build machines) and engineers are really happy with the stability and performance of the system.

This is great work!

There’s some really good news in ports-land tonight (this morning?). I’ve just got a preliminary dependency resolver implemented in the builder script along with a few other fixes and tweaks. It actually works quite nicely although I need to make it less prone to breaking and to handle deeper nested dependencies. This isn’t urgent as there’s only a few packages that have ports-based dependencies.

With annvix-ports 1.8, I built autogen (builder -p autogen), which required guile, which in turn required umb-scheme. builder did the right thing… it built and installed umb-scheme first, then guile, installed it, then built autogen. And was successful. =) Of course, if umb-scheme required something else, or if guile and autogen both required something else, I’m not sure how well it would hold up. Like I said, it’s preliminary, but it handles the scenario we currently have in ports (AFAIC, there are no other inter-ports-dependencies right now).

This is probably the biggest “issue” I had with ports, and it’s just been solved, which is nice. No, it’s not perfect, but it’s working and gives me the basis to tweak and refine it further although as things sit right now, until I have a more complicated “test scenario” I really can only theorize how it will work.

Of course, only 2.1-CURRENT is getting the new builder. 2.0-RELEASE is pretty much done; at the rate I’m going, if all goes well, 3.0-RELEASE will be available for Christmas. =)

I plan on doing my upgrades this week, but so far so good… I have a (working in vmware/testing) script that will upgrade 2.0-RELEASE to 2.1-CURRENT and so far it does it quite well. The only thing I’m unhappy about is it requires a double-reboot… the installer creates a “fat” initrd image with all of the IDE drivers in it for the first reboot, and then some hooks in rc.local execute on the first reboot to setup the ide-controller settings in /etc/modprobe.conf and then regenerates the initrd image. The next reboot will use the proper module (loading one instead of a dozen or so), and is highly recommended to make sure the script got it right (I don’t anticipate problems as it’s roughly the same code the installer uses).

I’ll be putting it to a real test tomorrow probably when I upgrade the build machine and if that goes well, I’ll probably be going through the rest of the machines to upgrade them all too. I don’t anticipate any major problems. The upgrade script can be downloaded here for those of you interested in testing or upgrading yourself (and testing is very much welcome!).

Version freeze for 3.0-RELEASE is set for the 17th. A new beta ISO should also be available then which, barring any bugs, will be the last.

Also, having an interesting issue with upgrades. A simple change in /etc/apt/sources.list followed by “apt-get update && apt-get dist-upgrade” seems to take care of everything *except* the new IDE drivers. 2.6.17 has no concept of these, so kudzu and whatnot don’t look for or find them. Of course, if you’re booting off an IDE drive, the kernel will panic on reboot because there is no defined ide-controller module in /etc/modprobe.conf, which is where mkinitrd is pulling info from in order to build the initrd image when the new kernel gets installed.

So I’m at a bit of a loss here. How do you detect this without actually running the 2.6.22 kernel with the drivers? I.e. if there is no current module as “piix” in 2.6.16, but you need that to properly boot 2.6.22, how do you detect or figure that out, short of booting off an Annvix install CD, seeing what IDE modules are loaded, then rebooting back into Annvix, updating modprobe.conf, and then starting the upgrade?

That’s kind of a sucky way to have to do an upgrade, but I’m not sure how to do this detection. Anyone have any ideas? Of course, this is only a problem for people booting off IDE drives; SATA and SCSI boot drives should be fine (and even with IDE drives, they may not mount on boot, but then you’ll be able to take advantage of kudzu’s detection and modify /etc/modprobe.conf accordingly).

From what I can see right now, this is the *only* upgrade issue.