Annvix Development Blog

There was some discussion on the dev@ mailing list about a week ago regarding the path for 2.0 that needs to be defined now. The things on the table were gcc 4.1 (we’re using 4.0.3) and glibc 2.4 (we’re using 2.3.6). Although implementing these may push the release for 2.0-RELEASE back a bit, the other alternative was to wait until the 3.0-CURRENT cycle to implement them as I’m not too keen on dropping glibc 2.4 on a .1 or .2 release.

Anyways, we decided we were going to hold off on glibc 2.4 until 3.0 and integrate gcc 4.1 now (primarily for SSP). One big reason for holding back glibc is that 2.4 essentially requires a 2.6 kernel… from my understanding, it will absolutely not work with a 2.4 kernel. So for those people who still want to use a 2.4 kernel (even if we are using 2.6 by default now), glibc 2.3 is staying for a while yet. The downside is that we have to build libssp as a separate library instead of having it a part of glibc itself, but that’s a tradeoff we’re willing to make.

So tonight I upgraded gcc to 4.1 just to see how much work I had ahead of me and it actually went quite smoothly. It looks to be compatible enough with stuff compiled with 4.0.3 which is fantastic… I upgraded it, installed libssp beside it, rebooted, and everything worked smoothly so I’m quite impressed with that… means we may not have to push things back further than I had thought (I like to allot myself a lot of time when it comes to gcc and glibc because they’re both voodoo as far as I’m concerned and I’ve wasted tonnes of time on them in the past).

I’ve left a message to the same effect on the dev@ mailing list and am waiting for a few opinions (and plan to do some more testing over the next day or two) before committing it and putting it officially into 2.0-CURRENT, but so far so good.

The new init system is basically complete. This probably needs some good banging on by folks willing to test it. The jist of it is that chkconfig is gone, as are the /etc/rc?.d/ directories/files. There’s no reason to have 6 usable runlevels when we could have one hundred (if we wanted); and we can do this now as our init system is based more on Gentoo than the typical RH/Mandriva style. I’ve been looking forward to implementing something like this for a while, and it was a fairly major job. All the bits and pieces are in place now and it looks great.

The initscripts still have to stick around (there are some useful tools/functions there, not to mention the network support scripts), but it’s been stripped down some since we forked it (needs a lot more cleaning tho). As a result, some files have moved from the initscripts package to the runit package (in the form of the annvix-runit tarball). All of the initscripts have been updated to use the new system (there were less than a dozen), and a bunch have been removed. In the grand scheme of things, this doesn’t mean a lot since runit handles all of our services and the traditional system will have 3-4 initscripts (networking, network filesystem support, iptables, shorewall, kudzu, etc.). These are one-time services that do their thing, exit, and are forgotten about.

Because of this, chkconfig is no longer used to manipulate runlevels but we’re using a mangled rc-update from Gentoo to do it. This also means that initscripts from third-parties won’t work (yes, you’ll need to rewrite them a little bit, but the format isn’t too different).

The next step is to have runlevel-based /service entries. This means that /service will be moving to /etc/runlevels/default/service (where “default” is the name of the runlevel). So, for instance, you could have the default runlevel for everything, you could have the “single” runlevel that starts absolutely nothing, then “singlenetwork” which would start the network, and just sshd, by having “network” added to the “singlenetwork” runlevel (via ‘rc-update add network singlenetwork’) and then symlink the sshd service to /etc/runlevels/singlenetwork/service.

There are all kinds of things that could be done with this type of setup and I’d like to eventually explore more possibilities (ie. eth0 and eth1 come up in default, but only eth0 comes up in singlenetwork, etc.). That’s further down the road, however.

There are still a few things left to do with this, but on the whole it’s there and it works. =)

It’s been a while in the works, but I’ve just put onto the mirrors the new and improved install ISO for 2.0-CURRENT. This second alpha installer works pretty good, and it has a lot of new features. It cuts down on a lot of the manual stuff that needed to be done before, although there’s still some manual stuff remaining. The stuff that’s remaining is mostly dealing with partitioning, formatting, and mounting the filesystem as you want it; I didn’t see a compelling reason to try to automate that (mostly because I don’t think I’d ever get it good enough than using fdisk, mount, and mke2fs/mkfs.xfs directly).

So what’s new? Read on for a list of the more notable changes.

• man-pages are installed by default now
• SATA and SCSI devices are autoprobed again (was missing in the first alpha)
• no more questioning about locales (since we only support english)
• More robust error handling (ie. when you pick a bad mirror or mistype a URI, you get a chance to do it again (and again, until it’s right) because we now check the validity of the entered/chosen mirror first)
• urpmi is no longer installed by default
• The “-n” option to install-pkgs tells it not to do any network-using functions, such as setting up an apt repository
• You’re prompted for root’s password in install-pkgs
• You have the opportunity to setup the first user (always as an admin) in install-pkgs
• You no longer have to mount proc in the chroot manually, install-pkgs does it for you
• You no longer have to type out the timezone you’re in, but you get to pick it from a list
• Got rid of all the cdialog-based dialogs; it’s all straight text now with no buttons (except for net-setup)
• Nicer status messages (and some color!)
• Setup grub.conf according to how things are mounted (ie. instead of always assuming (hd0,0) is /boot, we can make the configuration more accurate, such as using (hd1,2) if /boot is /dev/hdb3 or using (hd0,1)/boot if there is no separate /boot partition and /dev/hda2 is /)
• Do a batch install of grub so there’s no manual installation of grub at all anymore
• Based on what RAID devices are setup prior to the install, install-pkgs now writes /etc/mdadm.conf properly (this is necessary due to an issue where we can’t have mdassemble support MDASSEMBLE_AUTO due to a compilation issue with dietlibc (see bugzilla bug #35)
• Offer to install any available updated packages once the install is complete
• Dump the user into the chroot to do any post-install tasks; once the user exits the chroot the system will umount everything and reboot on it’s own

Ok, that’s most of the more major-ish (and some not-so-major-ish) changes to the installer. There is an issue with writing the grub.conf file on a system using RAID for /boot (and /, if there is no separate boot); the boot device will get written as (hd0,-1) and causes grub to freak out, so you’ll have to do the grub install stuff manually if you’re using such a system for the time being. I could fix that now, but inevitably it’ll make me change something else and the ISO will be delayed another week.

As well, a new runit is on there with the new init system as well. This might look a little odd for a bit until I can convert the remaining few initscripts over to the new format… things don’t align quite so well just yet. But that’s mostly cosmetic; everything else should work (oh, and shutdown looks a little silly too due to a patching issue of the sv tool, but I’ve yet to figure out where the line breaks are coming from).

Now, some of this might seem pretty elementary compared to some other installers, but remember where this installer came from (Gentoo) and also keep in mind it’s written 100% in bash (not perl or python like the other guys). Oh, and the Annvix install CDs make a damn fine live CD out of the box to boot. =)

I’d love to see some testing of this. I’m sure there are things I didn’t test, or combinations of things I didn’t test, that might make install-pkgs freak out (for instance, I don’t know if /proc/mdstats reports things differently if you’re using raid5 or raid1, etc., which would impact the writing of the mdadm.conf file). Any bugs that you find, please file them on bugzilla.