Shot in the dark: those failures are in kernel modules (that naturally you never needed to specifically tell udev to use) and you did not enable the kmod use flag. You need to set that flag and udev should resume its behavior of modprobing things._________________First things first, but not necessarily in that order.

If you look, you'll see that you're also running the suggested udev-196-r1, which is probably why you're working.

By the way, I'm not actually using systemd - I tried it a year ago, and didn't have the time to get it all working properly. I'd still like to fiddle some time, when I get a round tuit.

I just tried changing my package.use as suggested for udev, added a few more keyword packages, and find that I have a blocker between module-init-tools and kmod. In order to move forward I'd have to remove module-init-tools first. At this point, it looks like it would kill my system if I got it wrong, and I'd have to boot a cd, chroot in, etc.

I don't have time for this right now._________________.sigs waste space and bandwidth

I saw a post on superuser where the 3.6.10-gentoo-sources requires eudev... anyone try it yet?

Running 3.6.10 with stock udev right now, posting this.

OTOH a problem recently surfaced, where my /dev/dvd, /dev/cdrom, etc symlinks are no longer getting created. I don't know when that happened - it just showed up yesterday when my wife tried to play a dvd. I looked, and it has happened on all 4 up-to-date systems in the house. (I use genkernel, boot with initramfs, and manage my own kernel configs.)

It is the modus operandi of Mr Suominen to do things like this where he patched udev which broke the creation of /dev/cdrom, then got r9 immediately stabilized and promptly removed the last working version, r8, leaving us, the users, with no symbolic links that most programs use to access the cdrom drive. Then to make things worse, there is no clear understanding how these links are supposed to be created. Are the users supposed to create rules manually?

Since Mr. Suominen so utterly broke this feature without any documentation or quick fix on how these links should be created with r9, you can either create them manually or recover udev-171-r8 from the cvs archive, host it in your local portage overlay and mask all versions above r8 until this problem is fixed.

I think it's important that I chime in and say that I've been using eudev for awhile now (since before it was in the tree), and it has been working nicely, and I've had no problems whatsoever. I have a machine with separate /usr and separate /var and NO initramfs, and my system boots fine, and everything functions properly._________________"To design the perfect anti-Unix, make all file formats binary and opaque, and require heavyweight tools to read and edit them." - The Art of Unix Programming

I think it's important that I chime in and say that I've been using eudev for awhile now (since before it was in the tree), and it has been working nicely, and I've had no problems whatsoever. I have a machine with separate /usr and separate /var and NO initramfs, and my system boots fine, and everything functions properly.

Do you use LVM? For some reason LVM fails with eudev for me. My initramfs is exactly enough decrypt my LVM and mount root, not /usr or /var and I would like to keep it that way._________________First things first, but not necessarily in that order.

After some goggling, I have found there to be very little in the way of information about what eudev actually means, besides a new name so I figured it deserves a new thread.
Here are my two questions:

Most pressing, will it allow for separate /usr and /var without an initramfs?
A more long term question, is Gentoo intending to replace udev with eudev as the "standard" option?

A separate /var was never an issue. A separate /usr is though. I am told by hcaulfield57 that he is using eudev with a separate /usr without any problems. There are still the lingering issue of rules depending upon things in /usr, which could cause a problem. A proper fix will occur through a mix of moving those rules to /usr and doing additional rule processing after the /usr mount.

As for Gentoo's future plans, I posted an official announcement that explains that. In short, it is up to the current sys-fs/udev maintainers.

I saw a post on superuser where the 3.6.10-gentoo-sources requires eudev... anyone try it yet?

Running 3.6.10 with stock udev right now, posting this.

OTOH a problem recently surfaced, where my /dev/dvd, /dev/cdrom, etc symlinks are no longer getting created. I don't know when that happened - it just showed up yesterday when my wife tried to play a dvd. I looked, and it has happened on all 4 up-to-date systems in the house. (I use genkernel, boot with initramfs, and manage my own kernel configs.)

It is the modus operandi of Mr Suominen to do things like this where he patched udev which broke the creation of /dev/cdrom, then got r9 immediately stabilized and promptly removed the last working version, r8, leaving us, the users, with no symbolic links that most programs use to access the cdrom drive. Then to make things worse, there is no clear understanding how these links are supposed to be created. Are the users supposed to create rules manually?

Since Mr. Suominen so utterly broke this feature without any documentation or quick fix on how these links should be created with r9, you can either create them manually or recover udev-171-r8 from the cvs archive, host it in your local portage overlay and mask all versions above r8 until this problem is fixed.

And yes, I of course admit that this is a direct result of me not seeing this change affecting this feature of udev. -r9 solves one problem, while introducing another, like I mentioned in the bug. In the end, staying with 171 is a dead end, and next to nobody is maintaining it.

So while I don't like the tone of your post, I'm willing to accept any patches you have to solve this issue so that it doesn't reintroduce the regression with -r8 and later 3.x kernels.

(And I don't mean to sound in any way rude, these are just the facts we are in...)

I am already stretched thin, but I will try to look at it before Christmas.

0n0w1c wrote:

Does anyone know if eudev will eventually support switching from udev-171?

It is already possible to switch from udev-171 to eudev on most systems using udev-171. The main issues are the absence of the rules generator and a soname change. Work is being done to restore the rules generator. The soname change will break anything not compiled against the newer ABI. A workaround involves first installing sys-fs/eudev-0 and then the current eudev package. The plan is to add the old library to the eudev package to render sys-fs/eudev-0 obsolete.

The Doctor wrote:

hcaulfield57 wrote:

I think it's important that I chime in and say that I've been using eudev for awhile now (since before it was in the tree), and it has been working nicely, and I've had no problems whatsoever. I have a machine with separate /usr and separate /var and NO initramfs, and my system boots fine, and everything functions properly.

Do you use LVM? For some reason LVM fails with eudev for me. My initramfs is exactly enough decrypt my LVM and mount root, not /usr or /var and I would like to keep it that way.

LVM is currently broken with sys-fs/udev-196 and most likely sys-fs/eudev as well. LVM explicitly requires <virtual/udev-196 because of this. I am afraid that I do not know when this will be fixed. ssuominen is likely in a better position to talk about this than I am.

LVM is currently broken with sys-fs/udev-196 and most likely sys-fs/eudev as well. LVM explicitly requires <virtual/udev-196 because of this. I am afraid that I do not know when this will be fixed. ssuominen is likely in a better position to talk about this than I am.

I'm far less bothered by this than by other issues with udev-196. As for the LVM, it's possible to move to lvm2-2.02.95-r4+ and get rid of the "<virtual/udev-196" issue.

What I saw as the real problem is that apparently udev-196 moves from module-init-tools to kmod, which are mutual blockers. (Actually the kmod block appears to be gone in module-init-tools-3.13+, but the module-init-tools block is present in all versions of kmod.) At the very least, module-init-tools includes such venerables as depmod and modprobe. I'm doing a quick "ebuild ... install" of kmod-12 to see if it includes those same executables... It doesn't - it just includes lib-type stuff.

It looks to me as if moving from module-init-tools to kmod is going to break traditional userspace in a really big way. Things like modprobe and depmod have been with us for about as long as we've had modules. Perhaps it can be done differently, but a heck of a lot of userspace has come to expect the old way. Not the least of which is that from a month or two back, every time I rebuild the openafs-kernel module, I have to run "depmod -a" manually before I can load it. I don't know what changed, only that I've had to adapt. I'm sure it can be managed with kmod, but I have no idea how. I'm also pretty sure that a significant number of init scripts use the modprobe command.

My net... udev-196 is a really major change, perhaps not for itself, but because it forces migrating from module-init-tools to kmod. By the way, my first attempt had a default "USE=-kmod" and no modules auto-loaded - a non-functional boot._________________.sigs waste space and bandwidth

LVM is currently broken with sys-fs/udev-196 and most likely sys-fs/eudev as well. LVM explicitly requires <virtual/udev-196 because of this. I am afraid that I do not know when this will be fixed. ssuominen is likely in a better position to talk about this than I am.

I'm far less bothered by this than by other issues with udev-196. As for the LVM, it's possible to move to lvm2-2.02.95-r4+ and get rid of the "<virtual/udev-196" issue.

What I saw as the real problem is that apparently udev-196 moves from module-init-tools to kmod, which are mutual blockers. (Actually the kmod block appears to be gone in module-init-tools-3.13+, but the module-init-tools block is present in all versions of kmod.) At the very least, module-init-tools includes such venerables as depmod and modprobe. I'm doing a quick "ebuild ... install" of kmod-12 to see if it includes those same executables... It doesn't - it just includes lib-type stuff.

It looks to me as if moving from module-init-tools to kmod is going to break traditional userspace in a really big way. Things like modprobe and depmod have been with us for about as long as we've had modules. Perhaps it can be done differently, but a heck of a lot of userspace has come to expect the old way. Not the least of which is that from a month or two back, every time I rebuild the openafs-kernel module, I have to run "depmod -a" manually before I can load it. I don't know what changed, only that I've had to adapt. I'm sure it can be managed with kmod, but I have no idea how. I'm also pretty sure that a significant number of init scripts use the modprobe command.

My net... udev-196 is a really major change, perhaps not for itself, but because it forces migrating from module-init-tools to kmod. By the way, my first attempt had a default "USE=-kmod" and no modules auto-loaded - a non-functional boot.

The systemd developers believe that kmod should be the only way that module loading should be supported. eudev fixes that by permitting you to disable libkmod without disabling module loading support.

What I saw as the real problem is that apparently udev-196 moves from module-init-tools to kmod, which are mutual blockers. (Actually the kmod block appears to be gone in module-init-tools-3.13+, but the module-init-tools block is present in all versions of kmod.) At the very least, module-init-tools includes such venerables as depmod and modprobe. I'm doing a quick "ebuild ... install" of kmod-12 to see if it includes those same executables... It doesn't - it just includes lib-type stuff.

It looks to me as if moving from module-init-tools to kmod is going to break traditional userspace in a really big way. Things like modprobe and depmod have been with us for about as long as we've had modules. Perhaps it can be done differently, but a heck of a lot of userspace has come to expect the old way. Not the least of which is that from a month or two back, every time I rebuild the openafs-kernel module, I have to run "depmod -a" manually before I can load it. I don't know what changed, only that I've had to adapt. I'm sure it can be managed with kmod, but I have no idea how. I'm also pretty sure that a significant number of init scripts use the modprobe command.

kmod-12 does include those staple module tools. They are created as symlinks to the kmod binary if you emerge with USE+=tools (the default). kmod checks $0 and behaves appropriately.

kmod-12 does include those staple module tools. They are created as symlinks to the kmod binary if you emerge with USE+=tools (the default). kmod checks $0 and behaves appropriately.

Thanks - I missed that one, because I didn't really install, I only built it in /var/tmp/portage. The symlinks don't show there because they're done during qmerge.

Next question... Does anyone know if kmod is a general replacement for module-init-tools? In other words, can I migrate to kmod now while I'm using udev-171-r9, acquire at least a little comfort with that, then update to udev-196? All of these are rather disruptive changes, and I'd rather take this bit by bit. (For me lvm2 is the least disruptive since I'm not actually using it - it's just getting dragged along by other tools)_________________.sigs waste space and bandwidth

Next question... Does anyone know if kmod is a general replacement for module-init-tools?

I've used it for awhile, it seems to be a drop-in replacement for me. I've had no problems. This was on older installs though, I'm currently on module-init-tools with my new install, due to eudev being much more flexible than upstream systemd-udev._________________"To design the perfect anti-Unix, make all file formats binary and opaque, and require heavyweight tools to read and edit them." - The Art of Unix Programming

I really have mixed feelings about systemd. From an init point of view I like what it purports to do - the idea of deferring stuff until it's necessary, and letting the system boot rapidly.

I have 2 basic problems with it:
1 - From my perception, it appears to be a monolithic, opaque Windows-like thing. It'll boot your system, just "trust me", and if it fails you're screwed. Others have told me that it is in fact well documented, and on occasion I've tried to read the documentation. Perhaps I just haven't put enough time into it, but I have a bad first impression. I remember the bad old days of xf86config... As bad as that was, it was possible to "read a little and get what you needed." My initial impression with systemd, and in fact anything pushed by opendesktop.org is that the initial learning slope is horrible. Until you learn a LOT you're stuck at the "trust me" stage.

2 - Also from my perception, systemd doesn't follow "the Unix way", it's a big tool glomming lots of not-closely-related function, like logging. Perhaps this is just a matter of packaging, and if they chose to break things up a bit better I'd be happier.

For the moment I don't want to forbid systemd, hence I don't want to move to eudev. Wasn't Gentoo working on "initng" a while back, or it's own fast-boot init system? Whatever happened?_________________.sigs waste space and bandwidth

Let's not turn this into a thread about systemd. I think it's likely that systemd will never become the default on Gentoo, if it did it would probably lead to an inevitable forking._________________"To design the perfect anti-Unix, make all file formats binary and opaque, and require heavyweight tools to read and edit them." - The Art of Unix Programming