On Thu, Dec 29, 2011 at 12:42 PM, Tom Gundersen wrote:

On Thu, Dec 29, 2011 at 6:09 PM, Andreas Radke wrote:

...

Will there be a udev-compat pkg allowing to keep .32 lts?

The udev-compat package has contained a few extra rules files that allowed old kernels to keep working. It looks like this will no longer be enough as of the next release (there has been no update to the compat rules), though I don't know exactly what caused the required version bump.

In other words, things might continue to work, but we'll be on our own. Along with every other distro trying to package an advertised-as-stable kernel.

It might be worth noting that what we are doing (old kernels on new user-space) is not really supported/tested upstream and the README says "The upstream udev project's set of default rules may require a most recent kernel release to work properly.". "Upstream" seems to be more and more the whims of two developers that think they've come up with the best thing since sliced bread, no?

...

I'd like to update our LTS kernel to a more recent version but so far Grek hasn't announced any late kernel release to become long term supported. So there's no real option to update it for now. LTS-2.6.32 is still the best supported long term kernel upstream.

That's a bit annoying. Any idea when a new LTS kernel would be out? I don't really know what to suggest. What exactly is the use-case for our LTS kernel? Why the hell are we even having to worry about this stuff downstream? This is super frustrating that upstream kernel developers can't even push back on the udev and systemd folk for this crap.

The whole idea of an LTS kernel is fairly clear from the name- "long term support". If these projects are getting so damn lazy they can't even support an upstream kernel, it is pretty absurd in my opinion. </rant> I've realized I didn't say much productive, but I don't have time to fight this battle, nor do I even really use the LTS kernel. However, this whole darn thing just seems troublesome, and I'm a tad surprised we are the only ones unhappy about this, if that is even the case. Is there no push back occurring on these mailing lists? -Dan

On do, 2011-12-29 at 20:16 +0100, Tom Gundersen wrote:

On Thu, Dec 29, 2011 at 7:48 PM, Dan McGee wrote:

...

I've realized I didn't say much productive, but I don't have time to fight this battle, nor do I even really use the LTS kernel. However, this whole darn thing just seems troublesome, and I'm a tad surprised we are the only ones unhappy about this, if that is even the case. Is there no push back occurring on these mailing lists?

There seem to be no interest in making udev work with old kernels, as far as I can tell from the ML.

Which is quite logical. We're the only distribution that maintains the latest userspace with an LTS kernel. Your statement is: "We upgrade udev, we have to drop old kernels now". All the other distributions: "Hmm, this udev sucks, we can't use this with our kernel, let's keep it on hold, just like we do with pkg X". This is quite logical: why depend on a several years old kernel, but use the latest and greatest udev? Those things are tied together quite closely. As for the minimum version: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=e3c14a7ff3931... That commit was done 5 months ago and is in udev since release 173. Did we ever receive any bugreport about 2.6.32 not working? The readme file has stated 2.6.34 requirement for a long time now, and still does that. So maybe there's no problem at all and things still work fine with 2.6.32. As long as our LTS kernel has the options compiled in as required by udev, I don't think it will become a huge problem.

On Mon, Jan 2, 2012 at 9:07 AM, Tom Gundersen wrote:

I suggest the following news item:

*****

Users of unofficial kernels must enable devtmpfs support -------------------------------------------------------------------------

As of udev-176, we will no longer be able to boot kernels without s/we will/the Arch Linux userspace tools will/ devtmpfs support.

The official Arch kernels (`kernel26-lts` and `linux`) have both had devtmpfs support for a long time, so only people who compile their own kernels are potentially affected by this change.

More information about the kernel options required by udev is available in the udev [README](here: http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob_plain;f=README).

*****