[20:50:18] <Nikoli> ssuominen, hi, why /etc/init.d/udev:kv_min="${kv_min:-2.6.34}" when udev-197-r3.ebuild:KV_min=2.6.39? [20:50:59] <ssuominen> Nikoli: That's a bug. The old udev ebuilds used to sed that line to be correct, iirc Wed Jan 23 21:28:43 2013 >>> sys-fs/udev-197-r3 Wed Jan 23 21:53:23 2013 >>> sys-fs/udev-init-scripts-21
This is fixed in udev-init-scripts-22.
Why KV_min should be 2.6.39, since that: > grep -B1 2.6.31 /usr/portage/sys-fs/udev/ChangeLog > 21 Jan 2013; Samuli Suominen <ssuominen@gentoo.org> udev-171-r10.ebuild: > Stabilize for everyone because of one patch; restore support for 2.6.31. ? Udev is working well for me on kernel 2.6.32.
2.6.39 is the lowest we know to be working for all arch's (except ia64 which needs 3.3 (or 2.6.32.60 or higher from that series) like devtmpfs support and accept4() support 2.6.32 might work for some arch's, but we don't really support anything older than kernels from the 3.x series (since we don't test olders) you propably want sys-fs/eudev for older kernel support
Thanks for your reply. Understood that, but what about udev-init-scripts? Why kv_min in udev init script should be 2.6.39? We have to use udev-init-scripts with both sys-fs/udev and sys-fs/eudev. If I'll use sys-fs/eudev for 2.6.32, I'll still can't use it because of kv_min="2.6.39", will I?
uh, good point, CCing eudev@
seems we need to write the lowest version to a file in live filesystem from udev's OR eudev's ebuild so we can then reuse it in udev-init-scripts... reopening
Why not to put init.d script to the eudev tree and remove dependency from udev-init-scripts?
(In reply to comment #7) > Why not to put init.d script to the eudev tree and remove dependency from > udev-init-scripts? The init scripts depend a lot more on openrc than they do on *udev, which is why they're in a separate package for sys-fs/udev too. At the moment, since eudev itself is still beta and ~arch, it's quite safe to simply ignore the warning at startup (I might add an elog message about this to the eudev ebuilds, actually). Also, since there may be further dependency check differences (various kernel features or whatnot), I think it will make some sense to have udev-init-scripts source a file in, say, $(udevdir) to read the kernel requirement checks. (this will also help with sys-fs/udev on its own as then udev-init-scripts may not necessarily need to be bumped when a new udev is installed)
There is also another option. The only reason KV_* is set and checked in the init scripts is that udev doesn't check the kernel version when it starts. We warn about the kernel version when you emerge udev, so in theory I could remove this extra check. If we really want this, we should come up with apatch for udev (and eudev) to make them fail when running on a kernel older than they support. That would solve the issue for eudev and udev using the init scripts without creating a file in the live filesystem to source, which I am against, because I don't like creating a lot of gentoo specific files. Thoughts?
An interesting idea, although this would require a fair bit of code. From what I've seen, there is currently nothing in the udev to check for required capabilities, except for those specific things that it needs (such as inotify registration etc). For instance, the code just works with whatever /dev happens to be -- if it's not a devtmpfs udev will still use it (although I expect it will probably fail to do various things as it assumes /dev is devtmpfs, right?). Same thing goes with a lack of accept4 support (in sys-fs/udev that is) -- it runs, stuffs error, syslog/dmesg fills. I expect that it was done this way for a reason, mainly, that udev will run and attempt to do its thing no matter what the environment, so that all sorts of environments could technically be used even though only a certain configuration is officially supported. So, that would seem to put this back into the scope of a gentoo/openrc issue.
Here is the information I got from Kay on this issue. They do not support running udev on older kernels than 2.6.39, but they do not want to deliberately block users from doing this if they want to patch things to make them work. Given that information, I would vote to remove the kernel version check from the init scripts. Does anyone disagree?
> Given that information, I would vote to remove the kernel version check > from the init scripts. I personally fully supports this.
This is fixed in commit 81ca5fe and will be included in udev-init-scripts-23. Thanks for the report.
(In reply to comment #13) > This is fixed in commit 81ca5fe and will be included in > udev-init-scripts-23. Thanks for the report. thanks williamh
*** Bug 456726 has been marked as a duplicate of this bug. ***