openafs support should take advantage of dkms

[broder]

Now that there's dkms support for openafs in Jaunty, we should figure out how best to take advantage of it.

We probably don't want to install openafs-modules-dkms instead of our openafs-modules metapackages, because the time to build the kernel module sucks if it can be avoided.

Maybe adding openafs-modules-dkms as a recommendation of debathena-locker?

[jdreed]

Let's bump this up on the list, because I got screwed this morning by there being a a new jaunty kernel and no openafs modules for it (see the -c debathena logs from this morning).

I'd like some way for the installer not to give users a b0rked system -- whether that's by switching openafs to use dkms or by having the installer verify the existence of debathenificated openafs modules for the current kernel before proceeding.

[broder]

To copy some information I sent via e-mail a while back, here's my plan for implementing this:

• Make debathena-locker a real package, instead of an equivs package, that has a *hard dependency* on openafs-modules-dkms | openafs-modules-generic | openafs-modules-server | etc, as appropriate for the release. This should have no effect for people who already have one of our openafs metapackages installed.

• Get Ubuntu to backport openafs 1.4.11+dfsg-6 (the version currently in Lucid) to Hardy, Intrepid, Jaunty, and Karmic. This will introduce openafs-modules-dkms for all releases.

• Wait a long enough period that the new openafs packages should have been distributed to mirrors and so forth.

• Change debathena-locker's openafs dependency to *only* depend on openafs-modules-dkms where that package is available (i.e. everywhere but Etch and Lenny), dropping the dependencies on the other openafs

metapackages. This should force installation of openafs-modules-dkms.

• Change install-debathena.sh to only install our openafs-modules-flavor metapackage on Etch and Lenny

• Reconfigure the debathenificator to only debathenify openafs on Etch and Lenny.

To avoid a dependency on {hardy,intrepid,jaunty}-backports, we may want to also backport openafs ourselves and put it in debathena-system.

[andersk]

Since we no longer care about Jaunty, and care only marginally about Hardy and Karmic, how about abbreviating the plan as follows?

• Make debathena-locker a real package, instead of an equivs package, that has a *hard dependency* on openafs-modules-dkms | openafs-modules-generic | openafs-modules-server | etc, as appropriate for the release. This should have no effect for people who already have one of our openafs metapackages installed.
• Change debathena-locker's openafs dependency to *only* depend on openafs-modules-dkms where that package is available (i.e. everywhere but Etch, Lenny, Hardy, Karmic), dropping the dependencies on the other openafs metapackages. This should force installation of openafs-modules-dkms.
• Change install-debathena.sh to only install our openafs-modules-flavor metapackage on Etch, Lenny, Hardy, Karmic
• Reconfigure the debathenificator to only debathenify openafs on Etch, Lenny, Hardy, Karmic

We could separately backport openafs-modules-dkms to Lenny, Hardy, and/or Karmic if somebody feels like it, but there’s no reason to block on that.

[jdreed]

This really needs to happen for Natty.

[andersk]

Remove the Karmic special cases from that plan, since Karmic actually does have openafs-modules-dkms support.

[andersk]

This is probably a simpler alternative for step 1:

• On releases that have openafs-modules-dkms, turn openafs-modules-generic, openafs-modules-server, etc. into metapackages with high version or bumped epoch that only depend openafs-modules-dkms. This will force installation of openafs-modules-dkms.

In that case, step 2 is nice but optional.

(If in the future someone goes through with the Lenny and/or Hardy backports plan, we’ll have to do something more complicated for those releases, in order to support both users that have backports turned on and users that don’t. Whatever. Empirical evidence suggests it will never happen anyway, but we can open a separate ticket if you want.)

[lizdenys]

I changed the debathenify script for openafs to install metapackages with a bumped epoch that only depend on openafs-modules-dkms when available and only debathenify openafs on Etch, Lenny, Hardy similarly in r25108.

geofft changed install-debathena.sh to only install our openafs-modules-flavor on Etch, Lenny, Hardy in r25106.

Note: we didn't hard code any versions, we instead checked to see if openafs-modules-dkms was available.

We are building and testing now.

[geofft]

Testing got delayed. I can confirm that r25016 works via PXE when installing a (Lucid) cluster machine. I haven't (yet) tried non-cluster, nor tried looking at the upgrade path (r25108).

[geofft]

r25108 rebuilds the metapackages every time, so this errors if we've already built a metapackage and we build a new one. (This isn't the behavior of the actual kernel modules.) This should be fixed before this goes into production, or it'll error all the time.

Also, I'm pretty sure this script doesn't use set -e enough.

[geofft]

I was misreading the errors. Turns out that it does in fact do those checks, it's just that we've been uploading to a test repo which isn't configured in the build chroots, so as far as the build chroots can tell, the package hasn't already been built and uploaded. :) This should work fine in production, since we reuse the codepaths we're already using in production. (Which is why the breakage really confused me...)

Liz and I tested and this works on Hardy, Karmic, Lucid, Maverick, and Natty. I'll test Debian at some point this weekend.

[lizdenys]

Changed these modules so that they also depend on linux-headers-foo and linux-image-foo. Also uploaded to -development.

[geofft]

Jon's tested this on a couple of machines, and I've also tested on a cluster machine. I will be deploying this to the production checkout (in /mit/debathena/packages) of the debathenify-openafs script and pointing that at -proposed. This means we'll need to watch for new Ubuntu kernels for a few days.

I would much like to test this on 1) a Debian machine and 2) an Ubuntu machine using the non-default kernel before we push this out to production.

[geofft]

svn up'd /mit/debathena/packages/third/openafs, and pointed it at -proposed. Note that this implies we now need to watch for non-DKMS openafs-modules packages that need to be moved to production, i.e., watch for Debian or Ubuntu kernel updates.

Fortunately new kernel updates just came out yesterday (for everyone, by which I mean at least Fedora, Debian, and Ubuntu), so I don't think there will be a new kernel in the next three business days.

[jdreed]

This appears to have broken autodebathenfication on squeeze in that it's complaining about modules that already exist. I'm going to daremove them later this evening, but if someone wants to take a look between now and then, that would be good.

[geofft]

Committed r25169 to fix that -- the first build worked fine, but the second one got confused about packages being both in production and -proposed. The next autodebathenificator run worked fine.

[jdreed]

OK, w20-575-1 through 7 have taken the dkms package and seem happy (modulo -3, which for some reason hasn't taken any updates since Friday)

[jdreed]

Yay. Note the one final test will be when upstream comes out with a new kernel.

Since Ubuntu's DKMS doesn't check at boot for a valid module, it's possible for machines to come up without AFS. The various changes in the xsession should fix this, but we may want to consider a nightly cron job or patch to auto-update on cluster that ensures the module is built for all installed kernels. We should also document the process of invoking a build by hand.

[jdreed]

Hrm, Google suggests I may be on crack about the boot time check, but I swear I remember seeing an initscript in older RedHat?.

Manual installation looks like it's as trivial as:
dkms build -m openafs -v 1.4.12
dkms install -m openafs -v 1.4.12

[kaduk]

Replying to jdreed:

Hrm, Google suggests I may be on crack about the boot time check, but I swear I remember seeing an initscript in older RedHat?.

The zone cell servers, at least, have things that look like they're intended to build a module at boot if needed. (It can't have worked in years, though.) You may be thinking of other machines instantiated from the same codebase?