[arch-dev-public] [HEADSUP] Minimum kernel version bump
Hi guys, The next udev release will change its kernel requirements. This will not affect people running our standard kernel, but self-compiled kernels might be, and the -lts kernel is affected. The major changes are: * 2.6.34 is the minimum kernel requirement (our current -lts is .32). * devtmpfs support must be switched on; /dev can no longer be on a tmpfs (this should only affect self-compiled kernels). For more details see <http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob_plain;f=README>. I think it does not make any sense for people to hold back udev and upgrade other packages, so once this is out I'll remove support for non-devtmpfs kernels in initscripts too. It might possibly make sense to re-evaluate our minimum kernel version supported in glibc, but I'll leave that to more knowledgeable people. Closer to the release I'll make a news item about this so everyone is aware. Cheers, Tom
Am Thu, 29 Dec 2011 11:54:52 +0100 schrieb Tom Gundersen <teg@jklm.no>:
Hi guys,
The next udev release will change its kernel requirements. This will not affect people running our standard kernel, but self-compiled kernels might be, and the -lts kernel is affected.
The major changes are:
* 2.6.34 is the minimum kernel requirement (our current -lts is .32).
Will there be a udev-compat pkg allowing to keep .32 lts? 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. -Andy
On Thu, Dec 29, 2011 at 6:09 PM, Andreas Radke <andyrtr@archlinux.org> 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. 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.".
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? Cheers, Tom
On Thu, Dec 29, 2011 at 12:42 PM, Tom Gundersen <teg@jklm.no> wrote:
On Thu, Dec 29, 2011 at 6:09 PM, Andreas Radke <andyrtr@archlinux.org> 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 Thu, Dec 29, 2011 at 7:48 PM, Dan McGee <dpmcgee@gmail.com> 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. -t
On do, 2011-12-29 at 20:16 +0100, Tom Gundersen wrote:
On Thu, Dec 29, 2011 at 7:48 PM, Dan McGee <dpmcgee@gmail.com> 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 Fri, Dec 30, 2011 at 11:19 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
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.
You are right. We should expect this to cause us problems sooner or later.
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.
Since then, several "legacy" things have been dropped from udev (support for the ide subsystem comes to mind), and until recently there was some ambiguity in the README stating that .32 was also supported. This has now been removed. I have not received any bug reports regarding our -lts. This sort of makes sense as what is likely to break is support for peripherals or udisks and friends. If -lts is used on a server without using any fancy udev features (such as /dev/disk-by-*, cdroms, printers, ...), there is no reason anyone should notice. So things are likely to limp along just fine. However, I thought it would make sense to point out that something is not quite right. Especially as the people who use -lts are likely doing that because they want something well tested, but they are getting the opposite. On a more productive note: I'll be looking into exactly what is missing in .32, and how big problems we should expect. If people want to improve the udev-compat rule files, get in touch with me and I can point you in the right direction as I have some ideas. -t
Hi guys, A quick update: On Thu, Dec 29, 2011 at 11:54 AM, Tom Gundersen <teg@jklm.no> wrote:
The next udev release will change its kernel requirements.
[...]
* 2.6.34 is the minimum kernel requirement (our current -lts is .32).
As far as I can tell this is not really relevant to us, and we should not expect any great problems from sticking with .32. I'll fix some minor issues I found (lacking static device nodes) when I push the next udev-compat release. When that is done, the only outstanding issue is the udev rules. The upstream rules are kept up-to-date with the latest kernel release and rules are removed when they are no longer needed. We might want to review the changes to the rules since udev-149, to check if there are any rules that have been changed/removed that we want to add back in. Preferably any additions we make should go upstream in "rules/misc/30-kernel-compat.rules". I'll still write a news item regarding the removal of devtmpfs support, but it seems that there is no reason to worry about .32 kernels. Cheers, Tom
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 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). ***** Comments welcome. Tom
On Mon, Jan 2, 2012 at 9:07 AM, Tom Gundersen <teg@jklm.no> 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).
*****
participants (4)
-
Andreas Radke
-
Dan McGee
-
Jan de Groot
-
Tom Gundersen