Just wanted to post a thread about my experience, since there is nothing on the eudev homepage about exactly how to move from udev to eudev, and very little anywhere else online (that I could find, which made me very nervous about potentially breaking my system).

First, please do not introduce any udev vs systemd noise. That is not what this thread is about.

I moved from the older/deprecated udev-171-r10 that I had been clinging to while all of the noise about systemd vs udev was going on, so I'm really not sure how applicable this would be to anyone wanting to move from a newer udev.

Anyway, after asking a lot of questions on the gentoo-user list (see this thread), it all boiled down to four simple commands:

Code:

emerge -Ca udev

emerge -1a eudev

etc-update (accepted all changes)

emerge @preserved-rebuild (to rebuild lvm2)

Done...

It was really about as uneventful as something could be, considering all of the horror stories and hype surrounding this whole event.

And a special thanks/shout out to Anthony G. Basile (and anyone else involved) for working to keep eudev updated and available to those of us who prefer it to systemd.

Last edited by libertytrek on Sat Aug 10, 2013 5:51 pm; edited 1 time in total

I would suggest that perhaps a safer way to do this update would be to update lvm2 before unmerging udev. If eudev doesn't work because of some dependency on lvm2, your system might not boot. The time between uninstalling udev and having a fully working eudev is a time when your system is very vulnerable.

I'm just going through the same process because I have decided that I need to avoid systemd, and I have a number of systems that need updating.

Well, eudev is a fork of the semi-current udev code so you can use http://wiki.gentoo.org/wiki/Udev/upgrade for it too for most part.
However I'd think twice whether to pick udev-208, or eudev-1.3 which is based on old udev code (206'ish?) and doesn't have anything useful udev doesn't have at this time.

I don't see any need to mask systemd.. but then, I'm always very careful when updating, and never blindly update world...

But you still delete files blindly by INSTALL_MASK. Bad idea.
/lib/systemd (or /usr/lib/systemd) can have binaries like lvm2-activation-generator which sys-fs/lvm2 deps on, also for non-systemd systems. That was just one example, there are likely to be multiple and with increasing amount.

But you still delete files blindly by INSTALL_MASK. Bad idea.
/lib/systemd (or /usr/lib/systemd) can have binaries like lvm2-activation-generator which sys-fs/lvm2 deps on, also for non-systemd systems. That was just one example, there are likely to be multiple and with increasing amount.

Ugh this makes me so annoyed: iirc you were one of the people telling us we can just use INSTALL_MASK and that therefore it's fine for systemd files to be part of every package.

Now you're spreading FUD about how it's going to break the systems of people who don't even have systemd, and in fact have it masked. Or is that what really bothers you?

I mean you're always coming out with nonsense about how eudev is "old" and what's your latest variant on this? code from udev-206 instead of 208. I mean c'mon: that's just pathetic.

FFS if lvm needs something, then it should not require the systemd package in order to get it. Fix it in Gentoo, if nothing else. Or stop pretending to care about users, and just admit that you have another agenda.

But you still delete files blindly by INSTALL_MASK. Bad idea.
/lib/systemd (or /usr/lib/systemd) can have binaries like lvm2-activation-generator which sys-fs/lvm2 deps on, also for non-systemd systems. That was just one example, there are likely to be multiple and with increasing amount.

Ugh this makes me so annoyed: iirc you were one of the people telling us we can just use INSTALL_MASK and that therefore it's fine for systemd files to be part of every package.

Now you're spreading FUD about how it's going to break the systems of people who don't even have systemd, and in fact have it masked. Or is that what really bothers you?

I mean you're always coming out with nonsense about how eudev is "old" and what's your latest variant on this? code from udev-206 instead of 208. I mean c'mon: that's just pathetic.

FFS if lvm needs something, then it should not require the systemd package in order to get it. Fix it in Gentoo, if nothing else. Or stop pretending to care about users, and just admit that you have another agenda.

I don't remember ever recommending anyone to use INSTALL_MASK so widely, it's completely different to mask out subdirectories like /lib/systemd/system than complete /lib/systemd. And I don't see anything pathetic
in pointing out installing eudev instead of udev is a downgrade, that has almost no benefits from users point of view at all, it's definately not an plain 'this or that' choice. Multiple grave bugs have been fixed in 208, grave bugs
that would have blocked 206 or 207 stabilization. The same reason those two versions got thrown out of the Portage so fast, to let people know they are not viable alternatives. Grave bugs like wrong network interface
naming, failing to read .rules with missing empty line in end of them, and so forth.

My only agenda is to let people know about the facts and help them make informed decisions. And what the... does lvm2-activation-generator binary which is part of sys-fs/lvm2 have to do with the systemd package? None, whatsoever.

Please get your facts straight before throwing in unfounded accusations.

This directory is a part of udev installation, not systemd, and it came with stage3 (as well as udev is). Nevertheless, you can remove this directory even if you use udev.
Probably, on next update it will be re-created by dbus or some other package that will try to access this directory

But you still delete files blindly by INSTALL_MASK. Bad idea.
/lib/systemd (or /usr/lib/systemd) can have binaries like lvm2-activation-generator which sys-fs/lvm2 deps on, also for non-systemd systems. That was just one example, there are likely to be multiple and with increasing amount.

Ugh this makes me so annoyed: iirc you were one of the people telling us we can just use INSTALL_MASK and that therefore it's fine for systemd files to be part of every package.

Now you're spreading FUD about how it's going to break the systems of people who don't even have systemd, and in fact have it masked. Or is that what really bothers you?

I mean you're always coming out with nonsense about how eudev is "old" and what's your latest variant on this? code from udev-206 instead of 208. I mean c'mon: that's just pathetic.

FFS if lvm needs something, then it should not require the systemd package in order to get it. Fix it in Gentoo, if nothing else. Or stop pretending to care about users, and just admit that you have another agenda.

I was confused by that statement as well. I have no systemd installed anywhere (and probably wouldn't unless my very life depended on it). I'm in the process of converting to eudev...just did so on the machine I'm on right now. My MythTV backend machine uses lvm2. It has a /usr/lib/systemd directory (which I wasn't aware of until reading this thread), however there is no lvm2-activation-generator in there...and no trace of lvm2 here:

If there were really any such lvm2 dependency, why would I not see it there??

You know, I've been way to busy with work and until recently haven't really been following the whole systemd debacle. I find the whole mess horrific...and avoiding this travesty difficult enough without stuff like this confusing matters.

My only agenda is to let people know about the facts and help them make informed decisions. And what the... does lvm2-activation-generator binary which is part of sys-fs/lvm2 have to do with the systemd package? None, whatsoever.

Please get your facts straight before throwing in unfounded accusations.

One second, why on earth lvm2 installs lvm2-activation-generator into /lib/systemd if it needs this binary even without systemd ?

My only agenda is to let people know about the facts and help them make informed decisions. And what the... does lvm2-activation-generator binary which is part of sys-fs/lvm2 have to do with the systemd package? None, whatsoever.

Please get your facts straight before throwing in unfounded accusations.

One second, why on earth lvm2 installs lvm2-activation-generator into /lib/systemd if it needs this binary even without systemd ?

As far as I can see it doesn't. It certainly hasn't here and lvm2 doesn't even have a systemd use flag, so I'm guessing it never does. Does *any* version of lvm2 do this or are we all getting side-tracked with FUD here?

This conversion went without a hitch on the workstation I'm on right now. In that case I was uninstalling udev-204 and installing eudev-1.1 (the version that was stable at the time). Nothing needed to be recompiled via @preserved-rebuild. Since then, it's been updated to eudev-1.3 without a hitch.

However I just had the switch go very badly on my mythfrontend system. Maybe someone here will have an idea as to why:

In this case, the machine had previously been updated to udev-208, so I was uninstalling udev-208 and installing eudev-1.3, which is now stable. In this case there was also nothing to rebuild.

However, when I rebooted it wasn't able to start eth0. I usually do most stuff on that machine via ssh, so I was stuck working at my TV with a wireless keyboard. Out of desperation I uninstalled eudev and reinstalled udev, and it still couldn't start eth0. Since I had a very recent clonezilla backup of my / partition, I got fed up and just restored. Now I'm back to normal. Not pretty at all. By the way: I have all my Ethernet adapters compiled directly into my kernels.

While writing this I just realized that that frontend machine doesn't have any 70-persistent-net.rules file (and apparently never has), while this machine (and my others) do. I'm guessing that may be related, but why would reverting back to udev not correct it?

...for the love of all that is holy...reading that made me want to cry. I see that that specifically relates to drivers compiled directly into the kernel, which is what I have. However I only have one device. Can someone explain how the above bug affects me in something less than a million words? For one thing, how is it that even with no 70-persistent-net.rules and udev at version 208, I've been reliably getting a name of eth0...that bug doesn't seem to imply that that would work. I don't actually even understand if 70-persistent-net.rules even works any more..seriously confused.

I can see now that I seriously dropped the ball when it came to udev updates and network inyterfaces in general. I mistakenly thought that the issues applied strictly to situations with multiple interfaces.

What still has me confused, and I may start a new thread on this, is the fact that I have machines that are successfully using the "unpredictable" name eth0 even though the don't meet any of the criteria listed in the udev upgrade wiki. I just can't make sense out of that.