New kernels and old distributions

Posted Aug 11, 2006 9:43 UTC (Fri) by kreutzm (guest, #4700) [Link]

If I am a distributor, fine, I can do the QA, roll all things and get going (but see below). But I used to be a system administrator, taking care of several archs (in the 2.2/2.4 days). So when a new computer gets bought, some components might not work (newer drivers required). So I try out a more recent kernel. Emphasis on *try out*. Back in those days, this was no problem. Build the kernel, reboot, test, reboot back if necessary, redo. Now with udev loudly complaining (e.g. if I try to go from 2.6.8 in Debian Sarge to a recent 2.6) this is a hell more complicated, especially the "going back" part.

Ans remember the *try out* part. Lets say, you maintain a cluster of machines where you don't have the throughput you like. So you prepare a bleeding edge kernel, install it on a few nodes, take them offline and reboot. Next you ask a user to test drive this kernel. Once the testing is done (or your boss requires all nodes again) you will have to go back to the "old" kernel for production use. Of course, if the tests were fine, than you could upgrade all nodes, but here you'll have to wait for the maintenance window to come!

Another problem is that sometimes external kernel patches are required (e.g. grsecurity), so the latest udev might be "too new" which makes fun looking for the right version.

I don't mind upgrading udev, as long as old kernels continue to work. And as this is required (also for other reasons not listed here) I refuse to use udev, how nice it may be. I suppose, at one time I will have to reconsider, hopefully these problems have been solved by then.

I just wonder about the upgrade path from Debian Sarge to Debian Etch for people using 2.6.8 from Sarge. I hope the udev system has enough magic in it by now to make this a smooth upgrade (reading bug logs it appeared that this has been a bumpy road in Testing).