Ticket #243 (closed enhancement: fixed)

Opened 12 years ago

Last modified 10 years ago

openafs support should take advantage of dkms

Reported by: broder Owned by: lizdenys
Priority: blocker Milestone: Natty Beta
Component: -- Keywords:
Cc: lizdenys Fixed in version:
Upstream bug:

Description

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?

Change History

comment:1 Changed 12 years ago by jdreed

  • Milestone set to Fall Release

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.

comment:2 Changed 12 years ago by jdreed

  • Milestone changed from Fall Release to IAP 2010

comment:3 follow-up: ↓ 4 Changed 11 years ago by 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.

comment:4 in reply to: ↑ 3 Changed 11 years ago by 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.

comment:5 Changed 11 years ago by jdreed

  • Priority changed from normal to high
  • Milestone changed from IAP 2011 to Natty Alpha

This really needs to happen for Natty.

comment:6 Changed 11 years ago by andersk

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

comment:7 Changed 11 years ago by 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.)

comment:8 Changed 11 years ago by jdreed

  • Priority changed from high to blocker

comment:9 Changed 10 years ago by lizdenys

  • Cc lizdenys added
  • Status changed from new to accepted
  • Owner set to 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.

comment:10 Changed 10 years ago by 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).

comment:11 Changed 10 years ago by 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.

comment:12 Changed 10 years ago by 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.

comment:13 Changed 10 years ago by lizdenys

  • Status changed from accepted to development

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

comment:14 Changed 10 years ago by 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.

comment:15 Changed 10 years ago by geofft

  • Status changed from development to proposed

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.

comment:16 Changed 10 years ago by 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.

comment:17 Changed 10 years ago by 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.

comment:18 Changed 10 years ago by 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)

comment:19 Changed 10 years ago by jdreed

  • Status changed from proposed to closed
  • Resolution set to fixed

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.

comment:20 follow-up: ↓ 21 Changed 10 years ago by 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

comment:21 in reply to: ↑ 20 Changed 10 years ago by 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?

Note: See TracTickets for help on using tickets.