Annvix Development Blog

Charting Annvix Development

Entries Comments



Upgrade update

Category: Development - No comments - Posted on December 17, 2007 at 10:29 pm
Author: Vincent Danen

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

Category: Development - No comments - Posted on December 15, 2007 at 2:36 pm
Author: Vincent Danen

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.


2.1-CURRENT beta 1 now available

Category: Announcements - No comments - Posted on December 9, 2007 at 7:53 pm
Author: Vincent Danen

The first beta release of 2.1-CURRENT is now available. This is the first release of the install image that will be the forthcoming 3.0-RELEASE.

It would be fantastic to get some good testing on this one. This is the first install image with the new 2.6.22 kernel, and the new kernel that will cover all “flavours”. In other words, there is no longer a -BOOT, -up, and -smp kernel. The -BOOT kernel has been removed; the installer uses the standard kernel. As well, the -up kernel has been removed in favour of simply using an SMP-aware kernel.

The installer itself hasn’t changed much other than providing support for the new IDE drivers in the kernel, and setting up the default email address for all security alerts to go to. Other than that, the installer is largely identical to that for 2.0-RELEASE and I don’t anticipate making any changes to it unless bugs are encountered (hence the call for testing). Please report all bugs to bugzilla.

It would be appreciated, due to the changes in IDE controller support, if the install CDs could be tried out on various hardware. Even if you don’t plan to do an install, if you can afford to take a system down for five minutes just to make sure it correctly detects your hard drives and then reboot back to your normal OS, it would be highly appreciated.


Online remote upgrade

Category: Testimonials - No comments - Posted on December 2, 2007 at 7:25 am
Author: Ying-Hung Chen

For those of you looking at why I use Annvix, let
me elaborate how important EOL and online upgrade for me. And to me,
annvix does the job for me.

Over my 10 years of experiences with the servers, and I am going to talk
about the Linux as OS Three things are probably the worst
nightmare and most important to me as the administrator.

1. EOL of the distribution, which means mandatory upgrade if I want to
keep the software up to date (for security reasons)

2. Ease of the upgrade process.

3. Is online upgrade possible (or must be offline)

Item 2 and 3 are usually go hand to hand though. For first item, EOL of
most of the ‘free’ distributions are about 1 - 1.5 years. Which means,
when you finally get a version working (that’s about 3-6 months after
distribution is released), you only have less than 1 year left. That
means you’ll start preparing a upgrade when the EOL comes if you really
want to keep the security patch up to date and be able to sleep well at
night. This really force me to do upgrade almost every 1 - 1.5 years,
and it really too much work…..
so, since the upgrade is necessary to make sure the system is ‘free’
from hackers, how easy the upgrade process becomes important. For most
of the ‘Bigger’ distributions, due to its ‘HUGE’ and complex nature,
upgrade usually breaks badly and I normally just install a fresh copy of
new version (usually on the new harddisk) and just port the data
manually afterwards. The whole thing usually takes about 1 full day (if
I am lucky), and about a week to make sure everything works.

Finally, since I have several machines co-lo at else where. (Right now,
I live in Taiwan, and couple of my servers are still in the U.S.) To be
able to do remote online upgrade becomes very important. I can afford to
call the ISP to reboot the machine, but there is no way they will be
able to upgrade for me. Thanks to Annvix, which supports online upgrade,
and I have successfully upgrade from version 1.0 -> 1.1 -> 1.2 -> 2.0
and I am looking forward to the new release next year. Yes, we all know
eventually I’ll need to do fresh install just to cleanup everything, but
because of remote online upgrade, it really makes EOL of the server
software to 3-4 years (at least) which really ease my job.

If you run production servers 24/7, you’ll understand how cool this feature is!


Installer Updates

Category: Development - 1 comment - Posted on November 26, 2007 at 12:28 am
Author: Vincent Danen

Been a while since there’s been any posts here. My apologies, but most of the development work has been sporadic and what has been done has been less than exciting. Well, there are a few moderately exciting things. One is the new kernel (2.6.22.12) which is exciting in the fact that it took a lot of time to get things updated to handle it (especially the installer, which consumed most of my day today). Anyways, I’m thinking this week a 2.1-CURRENT beta ISO may hit the mirrors so people can get a taste of what’s new in the installer.

Ok ok… I’ll spoil the surprise. Support for the 2.6.22.12 kernel is what’s new. Beyond that, there isn’t a whole lot. I’ve elected to remain with the old-style IDE drivers rather than the new (and less than perfect, or so I’m told) PATA drivers. That, of course, doesn’t prevent you from playing with it on your own — it just means the installer won’t set it up for you. Beyond that, nothing really has changed in the installer other than removing any references to RSBAC (since we no longer provide it) and installing AppArmor by default.

So when will 2.1-RELEASE (or, more likely, 3.0-RELEASE) be available? Can’t really tell. If I could get 2-3 weeks of solid work time on it, I’d say by the end of the year. As it stands, and since that likely won’t happen, I’d be wagering sometime late January or February — again depending on how much time I can find to work on it. This week I do plan to setup a live machine running 2.1-CURRENT and start messing around with the services and whatnot to start poking for bugs, and I’d like to get some AppArmor profiles definitely written and setup per default for the next release.

Anyways, it’s been a few months since there was a post here and before someone starts thinking Annvix is dead, I figured I should (somehow) indicate that it’s still alive. Like a snail we move forward… just slowly.


New devel and library policy implementation complete

Category: Development - No comments - Posted on September 16, 2007 at 9:13 pm
Author: Vincent Danen

It’s taken a few months, but the library provides and development file naming policy has been fully implemented this afternoon. The details can be seen on the Spec Files page of the wiki. At any rate, this was a fairly big job and it turned out quite well, which should make it easier to manage the naming and building of packages now; at the very least keep them consistent. At the same time, some obligatory version upgrades were completed (of which I’m now beginning to recompile dependant packages).

As well, as of today, urpmi has officially been removed from Annvix. It wasn’t recommended for 2.0-RELEASE, and is no longer available in 2.1-CURRENT. As a result, apt-get is your friend. After a year or so of using apt, I’ve concluded that it’s much faster and behaves better than urpmi did. To be fair, I’ve not used urpmi on Annvix since implementing apt, and I know it’s received a lot of developer attention and improvement on the Mandriva side, but I much prefer apt (and it’s C-base) to urpmi (and it’s perl-base), even compared to yum and the others (python-based).

I’m quite a bit behind schedule for putting 2.1-RELEASE out; the initial idea was to have the 2.1 version be a bugfix build on 2.0, but a lot of changes have crept in and there’s more to come (updated kernel is one of the biggies). A lot has changed here, so I’m definitely considering renaming 2.1-CURRENT to 3.0-RELEASE when release time comes, as this is definitely not a .1 release.