# Moving from udev (171-r10) to eudev (1.2-r1)

## libertytrek

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:

```
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

----------

## NeddySeagoon

Moved from Portage & Programming to Documentation, Tips & Tricks.

As its one of those.

----------

## ddriver

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.

----------

## ddriver

I have a question in return, as you seem to have taken a lot of time to understand the systemd issue...

Having installed eudev in place of udev, is there anything else necessary in order to avoid systemd being used?

Do I need to add systemd to package.mask?

Do I need to add -systemd to the use flags in make.conf?

----------

## NeddySeagoon

ddriver,

Yes and yes.

The only thing that has a hard dependancy on systemd just now is Gnome 3.8.

----------

## libertytrek

 *ddriver wrote:*   

> I would suggest that perhaps a safer way to do this update would be to update lvm2 before unmerging udev.

 

You misunderstood...

lvm2 did not need updating... it simply needed to be *rebuilt*, *after* the switch.

----------

## ddriver

I see.

----------

## libertytrek

I didn't mask systemd...

But I did add the following to make.conf:

INSTALL_MASK="/usr/lib/systemd/"

This removes any systemd init files that any packages install...

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

----------

## sphakka

Thanks for this post!

As for me, I didn't have to rebuild anything.

Just a note of colour  :Wink: 

```

>>> Installing (1 of 1) sys-fs/eudev-1.1

 * Removing /usr/lib/systemd/

```

----------

## Tvin

I removed udev, but I can't emerge eudev. 

```
# emerge -1a eudev

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  N     ] sys-fs/udev-208  USE="acl firmware-loader gudev introspection kmod openrc static-libs -doc (-selinux)" ABI_X86="(64) -32 (-x32)" 

[ebuild  N     ] virtual/udev-206-r3  USE="gudev introspection kmod static-libs (-selinux)" ABI_X86="(64) -32 (-x32)" 

[ebuild  N     ] sys-fs/eudev-1.3  USE="gudev hwdb introspection keymap modutils openrc rule-generator -doc -kmod (-selinux) -static-libs {-test}" ABI_X86="(64) -32 (-x32)" 

[blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking sys-fs/eudev-1.3)

 * Error: The above package list contains packages which cannot be

 * installed at the same time on the same system.

  (sys-fs/eudev-1.3::gentoo, ebuild scheduled for merge) pulled in by

    eudev

  (sys-fs/udev-208::gentoo, ebuild scheduled for merge) pulled in by

    >=sys-fs/udev-206-r2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,gudev?,introspection?,kmod?,selinux?,static-libs?] (>=sys-fs/udev-206-r2[abi_x86_64(-),gudev,introspection,kmod,static-libs]) required by (virtual/udev-206-r3::gentoo, ebuild scheduled for merge)

```

----------

## SamuliSuominen

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.

----------

## SamuliSuominen

 *libertytrek wrote:*   

> I didn't mask systemd...
> 
> But I did add the following to make.conf:
> 
> INSTALL_MASK="/usr/lib/systemd/"
> ...

 

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.

----------

## steveL

 *ssuominen wrote:*   

> 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.

----------

## SamuliSuominen

 *steveL wrote:*   

>  *ssuominen wrote:*   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.
> ...

 

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.

----------

## steveL

 *ssuominen wrote:*   

> Please get your facts straight before throwing in unfounded accusations.

 

They're not unfounded. But go ahead with your agenda: after all, you will anyway.

----------

## _______0

I too have systemd folder without having installed systemd :/

/usr/lib/systemd/system/

If I am using eudev, is it safe to rm -rf that directory?

thanks

----------

## sphakka

How about this?

```

# emerge -uDNaq world

[ebuild     U  ] sys-fs/eudev-1.3 [1.1] USE="gudev hwdb keymap modutils openrc rule-generator -doc -introspection -kmod (-selinux) -static-libs {-test}" ABI_X86="(64%*) (-32) (-x32)" 1,641 kB

[ebuild     U  ]  sys-apps/hwids-20130915.1 [20130329] USE="udev" 1,535 kB

[nomerge       ]  sys-apps/util-linux-2.22.2  USE="cramfs crypt ncurses nls static-libs suid udev unicode -ddate -old-linux -perl (-selinux) -slang {-test}" 

[ebuild  N     ]   virtual/udev-208  USE="gudev kmod -introspection (-selinux) -static-libs" ABI_X86="(64) (-32) (-x32)" 0 kB

Total: 3 packages (2 upgrades, 1 new), Size of downloads: 3,175 kB

 * Error: circular dependencies:

(virtual/udev-208::gentoo, ebuild scheduled for merge) depends on

 (sys-fs/eudev-1.3::gentoo, ebuild scheduled for merge) (runtime)

  (sys-apps/hwids-20130915.1::gentoo, ebuild scheduled for merge) (runtime)

   (virtual/udev-208::gentoo, ebuild scheduled for merge) (buildtime)

It might be possible to break this cycle

by applying the following change:

- virtual/udev-208 (Change USE: -kmod)

```

Of course, the '-kmod' tip doesn't work as 'udev' is not installed. I also tried other USE flag combinations on ufed (-kmod -keymap) at no avail.

Any idea?   :Shocked: 

----------

## evoweiss

Same thing cropped up here. I'll keep an eye on this thread.

AlexLast edited by evoweiss on Sun Nov 24, 2013 10:05 pm; edited 1 time in total

----------

## sphakka

 *sphakka wrote:*   

> 
> 
> ```
> 
> ...
> ...

 

For the time being, I masked these:

```

>=sys-fs/eudev-1.3

>virtual/udev-200

>=sys-apps/hwids-20130915.1

```

Bug report here...

----------

## creaker

 *_______0 wrote:*   

> I too have systemd folder without having installed systemd :/
> 
> /usr/lib/systemd/system/
> 
> If I am using eudev, is it safe to rm -rf that directory?
> ...

 

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

----------

## tld

 *steveL wrote:*   

>  *ssuominen wrote:*   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.
> ...

 

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:

```
equery belongs /usr/lib/systemd

 * Searching for /usr/lib/systemd ... 

media-sound/alsa-utils-1.0.27.1-r1 (/usr/lib/systemd)

net-misc/openssh-5.9_p1-r4 (/usr/lib/systemd)

net-misc/rsync-3.0.9-r3 (/usr/lib/systemd)

net-nds/rpcbind-0.2.0-r1 (/usr/lib/systemd)

net-print/cups-1.6.2-r5 (/usr/lib/systemd)

net-print/cups-filters-1.0.34-r1 (/usr/lib/systemd)

sys-apps/dbus-1.6.12 (/usr/lib/systemd)

sys-auth/polkit-0.110 (/usr/lib/systemd)

sys-libs/gpm-1.20.7-r1 (/usr/lib/systemd)

www-servers/apache-2.2.25 (/usr/lib/systemd)

```

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.

Oh...and thanks to libertytrek for the original post!...very helpful!

Tom

----------

## dmpogo

 *ssuominen wrote:*   

> 
> 
> 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 ?

----------

## tld

 *dmpogo wrote:*   

>  *ssuominen wrote:*   
> 
> 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. 
> ...

 

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?

Tom

----------

## tld

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?

EDIT: OK...I'm sure this is related:

https://bugs.gentoo.org/show_bug.cgi?id=453494

...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.

Tom

----------

## tld

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.

Tom

----------

## steveL

 *tld wrote:*   

> 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?
> 
> EDIT: OK...I'm sure this is related:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=453494
> ...

 

I don't think it does, and if it does then you have to rename to a non-eth* or wlan* name. I went the route of:

```
echo '# dummy empty file to keep eth* and wlan*' > /etc/udev/rules.d/80-net-name-slot.rules
```

which you didn't mention; that should get udev to leave network names as the kernel assigned them, and like you I only have the one ethernet card. (I find the whole thing really messed up, considering that it's supposed to be for desktop end-users, and I've never seen one with more than one ethernet, and one wifi card, so I'm left wondering who this really helps.)

----------

## tld

 *steveL wrote:*   

> 
> 
> I don't think it does, and if it does then you have to rename to a non-eth* or wlan* name. I went the route of:
> 
> ```
> ...

 

Thanks for the reply!  I'll probably go that route myself, but as per my last reply here I'm still going nuts trying to understand what's been keeping my machines from using the new "predictable" names in the first place!...it has me absolutely stumped, and I'm leery of trying to "fix' this when, based on everything I've read, all my machines should have switched to the new names...so there's clearly something I'm not understanding here.  The wiki says that the new names will be used unless one of these is met:

/etc/udev/rules.d/80-net-name-slot.rules is an empty file with only comments inside of it 

/etc/udev/rules.d/80-net-name-slot.rules is a symlink to /dev/null 

the kernel commandline contains net.ifnames=0

NONE of the above are true for ANY of my machines.  The only difference I can see is that the one I had issues with when moving to eudev is the only one I have that didn't have 70-persistent-net.rules.  The others have 70-persistent-net.rules specifically set up to use "eth0" which is NOT supposed to work.  Just now out of curiosity I tried rebooting this machine without 70-persistent-net.rules.  To make me even more confused, 70-persistent-net.rules got automatically created, all set up to use eth0!  I think this is being caused by the fact that eudev apparently has installed /lib/udev/rules.d/75-persistent-net-generator.rules, which is not in the current version of udev...This all has me ready to f****** cry.  The more I dig the less sense any of it makes.

Yea, this whole thing is really messed up.  I wish someone could clear me up on this one...

Tom

----------

## steveL

 *tld wrote:*   

> I wish someone could clear me up on this one...

 

Try #gentoo-udev on IRC: chat.freenode.net for help with eudev.

----------

## tld

Thanks!  I may do that...especially if I have any issue with the 80-net-name-slot.rules approach.

Tom

----------

## dmpogo

I also did

/etc/udev/rules.d/80-net-name-slot.rules is a symlink to /dev/null 

immediately I heard about this persistent name adventure ( totally unneeded for my setup)

----------

## krinn

Fixed.

 *dmpogo wrote:*   

> immediately I heard about this persistent name adventure ( totally unneeded for anyone)

 

----------

## Checko55

Hi,

I followed your steps and everything compiled without issues. 

Unfortunately when I start KDE (kdm) no keyboard or mouse is present and I cannot login.

Could you please give me a hint what may be missing?

thx

----------

## steveL

Checko55: That's hard to know: it may be evdev, it may be x11 drivers. Your best bet is to ask in #gentoo-udev on IRC: chat.freenode.net; you can do that from a minimal livedisk(irssi), a livedvd for GUI, or a livedisk from any distro, if you don't have another install. I'd actually ask #gentoo first (or start another thread), as this sounds like a basic installation issue.

I have this in /etc/portage/make.conf:

```
VIDEO_CARDS="vesa nvidia"

INPUT_DEVICES="keyboard mouse evdev"
```

AFAIK you just need evdev, but if it doesn't work for w/e reason the old ones come in handy.

Also try logging in without X. When xdm starts, hit ctrl-alt-F1 to get to console, and then (as root) run /etc/init.d/xdm stop and rc-update del xdm default (so subsequent boot goes straight to console.)

If you can't use the keyboard at all, when you boot, edit the grub line and add init=/bin/bash. That will get you to a rescue shell (ignore warnings about terminal), but you'll need to remount root read-write in order to run rc-update del xdm default and then shutdown -r now. If shutdown doesn't reboot the machine, then remount it read-only before you use the reset switch.

----------

## Checko55

Hi,

thanks for your answer.

I have evdev activated in make.conf and system compiled without any problem. Actually tried to

switch back to "legacy" udev and it worked. 

Do I have to create any rules or something maybe? 

regards

----------

## Tractor Girl

@Checko55

This is probably irrelevant but, did you add udev-postmount to default runlevel?

----------

## Checko55

Hi, 

Yes it is started by default.

----------

## steveL

Checko: #gentoo-udev; sorry I'm not on eudev yet, will make switch after I get kernel and --toolchain updated. That's where the developers of the actual software are, as it's an in-house project. ryao is very capable and so's blueness. (not sure who else is involved right now.) They're also very helpful, from what I've seen. They'd probably appreciate being able to fix your issue, as others may hit the same thing.

Instructions here

I could login in again, get in touch with the channel and ask them to check in: but then you'd be missing out on the much wider world of the community on IRC: over 50,000 channels last time I checked with about 100,000 people. Yes there's many that are small, dead or even private, but there are an awful lot more where you can ask questions live, and get live support much better than any commercial setup. #gentoo always has over 900 people in (pure support), and #gentoo-chat about 150 (off-topic relaxation, still polite. Sometimes a lot firmer than other gentoo channels, but fun :-)

Just show you've tried things as you have, don't talk too much til you know your way round, and you'll be fine. I'm in #friendly-coders when I'm online: /join #channel and have fun! If you want to find channels about something use, eg:

```
/msg alis list gentoo-*

/msg alis list *apache*

/msg alis list * -topic *something*
```

 -- I defy you not to find something you're interested in (besides Gentoo!)

Regards

igli.

PS Don't go into a channel that logs publically; half the point of IRC is that it's a safe space to explore in, and the flipside of that is privacy, at least not to release logs unless necessary, eg for a problem that needs to be resolved with staff; don't worry, rare, though you do get some unfriendly people. If someone is treating you disrespectfully or offensively, just type:

```
/ignore fool

fool: *plunk*

```

 So they know you can't hear them any more (I wish real-life were so easy..:) /unignore fool, to hear them again, but leave it for at least a few days if you've had to ignore someone, for things to cool down a bit, and life to get in the way. ('fool' being the irc nick you wish no longer to hear from, as I am 'igli'.)

Have a read of the catalyst page which is what operators, and indeed all of us, are supposed to be doing. Good luck!

----------

## Checko55

Hi SteveL, 

thanks for your help and the instructions. Will definitely try that. 

Best regards 

Checko55

----------

## ExecutorElassus

incidentally, having just attempted this -- and due to util-linux-2.25 getting masked in between and thus requiring a downgrade -- I realized that it works just fine now just to run "emerge eudev," which handles installing eudev (first, to cover dependencines) as well as unmerging sys-fs/udev afterwards. YMMV, etc.

----------

## maxmat

Regarding the switch udev -> eudev: 

I would strongly advise to "emerge @preserved-rebuild" then to"emerge -euva world" after that (in fact I do that on system then on world). It's time, it's electricity and it's could be consider as ugly. But it is efficient.

After a complex update (complex from system point of view, not my own point of view) the rebuild of the whole system shows system's instabilities.

Regarding lvm2-activation-generator, the man of this tool says "generator for systemd units to activate LVM2 volumes on boot". This tool is not part of LVM2 but part of systemd.

Regarding systemd on Gentoo, with LVM used for root FS (aka /) and also a separated /usr (to keep fun in building the system): not the right place to speak about it ^^

PS: thanks a lot to libertytrek to have taken time to explain his solution. Now this solution is also ours : )

PPS: I use emerge -e world mainly for two things: 

- rebuild the whole system: this must be done without human help, then your system would be consistent from emerge point of view (which few but huge).

- after --depclean, before reboot: ok you finished updating world, you did a gentle revdep-rebuild and you followed by emerge -va --depclean. Nothing which looked important was removed, you verified. 

And now you reboot.

And now you have no computer working.

This happened to me, most certainly because I made an error of course, I'm not blaming Gentoo team ^^

So to avoid that kind of surprise (most of them, kernel/initramfs, grub and some others issues are nor managed by emerge) I launch a final emerge -evau world before rebooting after by update or --depclean, to check if nothing would be updated or added...

PPS: I love that system  :Wink: 

----------

## ArneBab

I just tried installing eudev and it bailed out with blockers:

```
[ebuild  NS    ] app-text/docbook-xml-dtd-4.5-r1 [4.1.2-r6, 4.2-r2, 4.3-r1, 4.4-r2]

[ebuild  N     ] sys-fs/eudev-1.10-r2  USE="gudev hwdb introspection keymap kmod modutils openrc rule-generator -doc (-selinux) -static-libs {-test}" ABI_X86="(64) (-32) (-x32)" 

[blocks B      ] sys-apps/gentoo-systemd-integration ("sys-apps/gentoo-systemd-integration" is blocking sys-fs/eudev-1.10-r2)

[blocks B      ] sys-apps/systemd ("sys-apps/systemd" is blocking sys-fs/eudev-1.10-r2)

 * Error: The above package list contains packages which cannot be

 * installed at the same time on the same system.

  (sys-fs/eudev-1.10-r2:0/0::gentoo, ebuild scheduled for merge) pulled in by

    eudev

  (sys-apps/systemd-212-r5:0/2::gentoo, installed) pulled in by

    >=sys-apps/systemd-207 required by (sys-apps/gentoo-systemd-integration-4:0/0::gentoo, installed)

    >=sys-apps/systemd-208:0/2[abi_x86_64(-),gudev,introspection] required by (virtual/libgudev-208:0/0::gentoo, installed)

    >=sys-apps/systemd-44-r1[pam] required by (sys-auth/pambase-20120417-r3:0/0::gentoo, installed)

    >=sys-apps/systemd-208:0/2[abi_x86_64(-)] required by (virtual/libudev-208:0/1::gentoo, installed)

    >=sys-apps/systemd-208:0 required by (virtual/udev-208-r2:0/0::gentoo, installed)

```

I had thought that portage would take care of these itself, but I don’t have the time to dig right now so I just wanted to report it.

----------

## steveL

 *ArneBab wrote:*   

> I had thought that portage would take care of these itself, but I don’t have the time to dig right now so I just wanted to report it.

 

You already have systemd installed, which is a whole other ball game from converting an openrc/udev system to an openrc/eudev one.

If you want to stay with systemd, then eudev is not for you, since systemd incorporates udev (and recent versions of the latter appear to hang for a bit, if not under systemd.) I doubt it would work at all with eudev.

If not then I'd switch back to openrc first; though make sure to get rid of all systemd-supplied udev rules if you do that. It likely involves a profile change.

----------

## ArneBab

 *steveL wrote:*   

>  *ArneBab wrote:*   I had thought that portage would take care of these itself, but I don’t have the time to dig right now so I just wanted to report it. 
> 
> You already have systemd installed, which is a whole other ball game from converting an openrc/udev system to an openrc/eudev one.
> 
> If you want to stay with systemd, then eudev is not for you, since systemd incorporates udev (and recent versions of the latter appear to hang for a bit, if not under systemd.) I doubt it would work at all with eudev.
> ...

 

I use profile default/linux/amd64/13.0/desktop/kde (no systemd there), and I do not want systemd. My system starts with openrc, but something seems to have pulled in systemd.

```
equery d systemd

… (removed those which only depend on systemd with systemd useflag)…

sys-apps/gentoo-systemd-integration-4 (>=sys-apps/systemd-207)

virtual/libgudev-208 (>=sys-apps/systemd-208:0[abi_x86_64(-),gudev,introspection])

virtual/libudev-208 (>=sys-apps/systemd-208:0[abi_x86_64(-)])

virtual/service-manager-0 (kernel_linux ? sys-apps/systemd)

virtual/udev-208-r2 (>=sys-apps/systemd-208:0)

```

```
equery d gentoo-systemd-integration

sys-apps/systemd-212-r5 (!vanilla ? sys-apps/gentoo-systemd-integration)

```

^ is that a circular dependency?

and what is virtual/service-manager - why do I need it?

----------

## steveL

 *ArneBab wrote:*   

> 
> 
> ```
> equery d systemd
> 
> ...

 

That (kernel_linux ? sys-apps/systemd) tripped me for a second til I checked the ebuild:

```
DESCRIPTION="Virtual for various service managers"

..

RDEPEND="

   prefix? ( >=sys-apps/baselayout-prefix-2.2 )

   !prefix? (

      || (

      sys-apps/openrc

      kernel_linux? ( || (

         sys-apps/systemd

         sys-process/runit

         virtual/daemontools

   ) ) ) )"

DEPEND=""
```

I think it's what you pointed out about sys-apps/gentoo-systemd-integration, which is being pulled in by systemd, but I have no idea why openrc is not satisfying that virtual itself, or was rather. Now systemd is on the machine, it's being selected. It's not in world, is it?

I'd just emerge -Cq it first, and if that doesn't work use -cq and go a lot more carefully. If as you said you have openrc, and it's starting your machine, there shouldn't be any problem removing systemd.

You may need to remove the virtual, though in the first instance I'd just emerge -cq systemd myself, and then see what the tree is saying. It should then take openrc for the virtual, though you will likely want to remove other stuff and do a depclean after upgrade too.

Oh and check those udev rules like I said, as I wouldn't trust it not to "backup essential files" somewhere or the other.

Hmm virtual/udev-208-r2 (>=sys-apps/systemd-208:0)  might be another issue, as you appear not to have the normal udev any more (if that's just what it's going to do, then no bother.)

Just be careful if systemd is in-place as udev.

----------

## eflothmeier

On this machine I have:

mmom ~ # emerge -pv eudev

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  NS    ] app-text/docbook-xml-dtd-4.5-r1:4.5 [4.1.2-r6:4.1.2, 4.2-r2:4.2, 4.3-r1:4.3, 4.4-r2:4.4] 97 kB

[ebuild  N     ] sys-fs/eudev-1.10-r2  USE="gudev hwdb introspection keymap kmod modutils openrc rule-generator -doc (-selinux) -static-libs {-test}" 1,736 kB

[uninstall     ] sys-fs/udev-216  USE="acl firmware-loader gudev introspection kmod -doc (-selinux) -static-libs" 

[blocks b      ] sys-fs/udev ("sys-fs/udev" is blocking sys-fs/eudev-1.10-r2)

Total: 2 packages (1 new, 1 in new slot, 1 uninstall), Size of downloads: 1,832 kB

Conflict: 1 block

 I looked at the docimentation and I figure that I don't have to do anything more that this emerge

because:

1)

mmom ~ # udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null

returns nothing

2)

mmom ~ # ls -la /sys/class/net

total 0

drwxr-xr-x  2 root root 0 Nov 24 20:16 .

drwxr-xr-x 48 root root 0 Nov 24 20:16 ..

lrwxrwxrwx  1 root root 0 Nov 24 20:02 enp2s8 -> ../../devices/pci0000:00/0000:00:1e.0/0000:02:08.0/net/enp2s8

lrwxrwxrwx  1 root root 0 Nov 24 13:02 lo -> ../../devices/virtual/net/lo

lrwxrwxrwx  1 root root 0 Nov 24 13:02 sit0 -> ../../devices/virtual/net/sit0

shows that sys-fs/udev-216 is sufficiently advanced to anticipate ipv6

(I already did this as per the Gentoo handbook what is listed here in the eudev instructions)

3)

when I run:

mmom ~ # grep -r 'eth0' /etc/* | grep -v '#'

/etc/conf.d/net:config_eth0="DHCP" 

/etc/udhcpd.conf:interface      eth0

But it has to be this anyway because I'm still in an ipv4 world 

Looks like the emerge will autmatically remove the block too

I'm posting this because messing with udev is dangerous

Erich

----------

## eflothmeier

Succsess.

I ran

emerge eudev

After reboot, the result was:

mmom ~ # ls -la /sys/class/net

total 0

drwxr-xr-x  2 root root 0 Nov 29 16:24 .

drwxr-xr-x 48 root root 0 Nov 29 16:24 ..

lrwxrwxrwx  1 root root 0 Nov 29 12:28 eth0 -> ../../devices/pci0000:00/0000:00:1e.0/0000:02:08.0/net/eth0

lrwxrwxrwx  1 root root 0 Nov 29 05:28 lo -> ../../devices/virtual/net/lo

lrwxrwxrwx  1 root root 0 Nov 29 05:28 sit0 -> ../../devices/virtual/net/sit0

So the interface had to be changed back to eth0

Nonetheless:

mmom ~ # udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null

ID_NET_NAME_MAC=enx0002a5e1a232

ID_OUI_FROM_DATABASE=Hewlett-Packard Company

ID_NET_NAME_PATH=enp2s8

So enp2s8 is still around. It simply doesn't present a problem.

I had trouble getting DHCP to work because my /etc/config.d/net file

had this:

config_eth0="DHCP"

I never took thought of this because other of my boxes have it this

way, and it presented no problem.

config_eth0="dhcp"

Is what got it working. What goes in quotes is now case sensitive.

    Some thoughts on systemd. I looks like blocks are eliminated and it

will install. It wont execute so long as the kernel configuration is set for

init:

 Symbol: GENTOO_LINUX_INIT_SYSTEMD [=n]                                                                     

   Type  : boolean                                                                                                                 

   Prompt: systemd                                                                                                                 

     Location:                                                                                                                     

       -> Gentoo Linux                                                                                                             

   (1)   -> Support for init systems, system and service managers                                                 

     Defined at distro/Kconfig:68                                                                                                  

     Depends on: GENTOO_LINUX [=y] && GENTOO_LINUX_UDEV [=y]                                                                   

Erich

----------

## WWWW

hello,

I finally switched to eudev thanks for making the process as easy as emerge -C udev and emerge eudev.

Now, I want eudev part of the install stages by default. Gentoo should be promoting its own solutions, openrc, eudev, etc.

Another question is whether it's possible to contribute to this project. Can I help with something? I don't know how to code but I can hunt for things, debug, test to some menial diff tasks etc. Is it possible to help with small things?

One more thing, the old ethX naming convention is eudev's default now? I just ask to confirm and not be worried about my net devices have their names flipped arbitrarily later on.

Some time ago there was a convoluted way of switching between ethX and enpXsX. I want to know if eudev stays with ethX from now on.

thanks.

----------

## Fitzcarraldo

 *WWWW wrote:*   

> One more thing, the old ethX naming convention is eudev's default now? I just ask to confirm and not be worried about my net devices have their names flipped arbitrarily later on.
> 
> Some time ago there was a convoluted way of switching between ethX and enpXsX. I want to know if eudev stays with ethX from now on.

 

No, it isn't eudev's default now. I found that sys-fs/eudev-2.1.1 behaves in the same way as sys-fs/udev-217. I found that, whether using sys-fs/udev-217 or sys-fs/eudev-2.1.1, I needed to add the kernel boot parameter "net.ifnames=0" in order to ensure the interface names "eth0" and "wlan0" are used instead of "enp4s0" and "wlp3s0" respectively, because even the configuration listed below on my laptop (as per Ref. 1) did not reliably stop the freedesktop.org so-called 'predicable network interface names':

```
# ls -la /etc/udev/rules.d/80-net-setup-link.rules 

lrwxrwxrwx 1 root root 9 Nov 30 15:25 /etc/udev/rules.d/80-net-setup-link.rules -> /dev/null

# ls -la /etc/systemd/network/99-default.link

-rw-r--r-- 1 root root 0 Oct 31 07:41 /etc/systemd/network/99-default.link
```

The problems and hassle I've suffered as a result of the various changes to udev over the last couple of years have left me disliking it (and freedesktop.org) with a vengeance.   :Rolling Eyes: 

Reference 1:

 *eselect news wrote:*   

> 2014-02-25-udev-upgrade
> 
>   Title                     Upgrade to >=sys-fs/udev-210
> 
>   Author                    Samuli Suominen <ssuominen@gentoo.org>
> ...

 

----------

## Anon-E-moose

 *Quote:*   

> but using the kernel parameter is the most consistent way.

 

Next up on the udev change list....   :Rolling Eyes: 

Personally, I masked eudev-2.* and above

One of my fears about eudev was that they were going to follow the upstream changes to udev too closely.

----------

## Tony0945

Masking it myself, to keep eth0 and also that they are changing the way firmware is handled.

----------

## steveL

 *WWWW wrote:*   

> Another question is whether it's possible to contribute to this project. Can I help with something? I don't know how to code but I can hunt for things, debug, test to some menial diff tasks etc. Is it possible to help with small things?

 

Yeah, always. You need to get used to using Gentoo and bugzilla (note: don't post unless you have to, and keep it technical.)

In the first instance I'd advise you to use IRC: chat.freenode.net and /join #gentoo-udev and lurk there.

You likely want it on your /autojoin list, but in case you've not used IRC, you'd normally use /join to check a channel out first. #gentoo for overall support, and #gentoo-chat for downtime/off-topic chatter.

See http://freenode.net/using_the_network.shtml

and http://freenode.net/faq.shtml#nicksetup

----------

## steveL

 *Anon-E-moose wrote:*   

> Personally, I masked eudev-2.* and above
> 
> One of my fears about eudev was that they were going to follow the upstream changes to udev too closely.

 

 *Tony0945 wrote:*   

> Masking it myself, to keep eth0 and also that they are changing the way firmware is handled.

 

Has either of you filed a bug to start a discussion with them about these issues?

Please do so, if not; after all you guys are experts, so set the example. ;-)

Bug report is probably better to have the discussion on record, whatever way is chosen, so people can be referred back to it later, instead of repeating the same old dialogue over and over w/e someone new finds the channel.

----------

## stephan-t

I'm moving from 216 udev, anyway enough only sys-fs/udev to remove and re-emarged the new eudev version? I only do that and fine work.

----------

## steveL

 *stephan-t wrote:*   

> I'm moving from 216 udev, anyway enough only sys-fs/udev to remove and re-emerge the new eudev version? I only do that and fine work.

 

Yeah that should be enough nowadays, unless systemd got pulled in for some reason. Just be sure to run dispatch-conf (or etc-update) before you reboot (anyone who switches) as ever.

Thanks for the positive feedback, it helps others feel more confident about switching.

----------

## Tony0945

 *Quote:*   

> Has either of you filed a bug to start a discussion with them about these issues?
> 
> 

 

I don't really think it's a bug. It's what they want to do now.

----------

## steveL

How do you know? Just saying, if you've had the convi, then tell us that. In either event, a bug discussion is still better for the reason I gave: it means the reasoning is on the record, and people can be referred straight to the discussion directly from channel just by mentioning "bug XXXX" in front of willikins. That saves time, every occasion it comes up, as it means no-one has to go over the same old ground yet again.

Should it need to be revisited, it can be; or others can refer to it when patching in an overlay, for example, in a bash comment in the ebuild.

----------

## depontius

The other day I realized that I never got off my duff and moved from udev to eudev.  This morning I did a quick "emerge -ptv eudev" to look for anything weird, and noticed something...

Can someone comment more on the "gudev" USE flag?  From what I can tell, it's tied up in "gobject" stuff, and therefore I distrust it the same way I distrust "introspection".  The latter seems in someways to be a back-door that's going to someday call for systemd to be installed, and I'm wondering if "gobject" really is of the same ilk, or if it's potentially valuable.

Right now I've purged all *kit stuff from this system.  I have USE="-introspection -dbus" in make.conf, then selectively enable it where absolutely necessary in package.use, because I've found that they can't be fully purged without giving up things I don't want to give up.  I've limited both.  I'm now inclined to add "gudev" to that avoidance list.  (currently "-gnome -kde -esd -eds -arts -zeroconf -systemd -pulseaudio -policykit -consolekit -dbus -udisks -upower -introspection -gtk3")

I ran a quick "USE="-gudev" emerge -ptuvDN world" and see that virtual/libgudev depends on this flag being set.  I then see that I have several packages dependent on it, usually conditionally with the udev flag, but gvfs unconditionally.  I'm a bit surprised, but it looks like my dependence on gvfs itself may be conditional.  I may be able to purge this, after all.

Anyone else have experience here?  I'm reluctant to USE="-udev" at the moment.

----------

## depontius

Further confusion...

I just did a little xfce rebuilding to reduce dependence on dbus and libgudev, but decided not to try getting rid of libgudev quite yet, so for the moment I've left the gudev flag set.

Then I did "emerge -atv eudev".  First, I was happy to see that portage will automagically remove udev for me.  ("b", not "B")  Next I saw that I was removing udev-216 and installing eudev-1.10-r2.  The title of this thread is something about moving from udev-171-r10 to eudev-1.2-r1.  So by default I'm moving from a newer udev than this thread is discussing to an older eudev.  Somewhere in this thread there is a pointer to a udev upgrade guide, where they mention making sure CONFIG_FW_LOADER_USER_HELPER is not set.  I'm running 3.18.1 - I don't have that flag any more, but I have:

```
user@localhost ~ $ grep CONFIG_FW_LOADER_USER_HELPER /usr/src/linux/.config

# CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set

user@localhost ~ $ grep _FW_ /usr/src/linux/.config

CONFIG_FW_LOADER=y

# CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
```

I believe in this respect I'm set, but am not 100% confident.  Is CONFIG_FW_LOADER a rename of CONFIG_FW_LOADER_USER_HELPER?

Should I be moving to a newer version of eudev instead of the default 1.10-r2?  I see earlier on this thread that eudev-2+ are masked.

----------

## saellaven

 *depontius wrote:*   

> Further confusion...
> 
> I just did a little xfce rebuilding to reduce dependence on dbus and libgudev, but decided not to try getting rid of libgudev quite yet, so for the moment I've left the gudev flag set.
> 
> Then I did "emerge -atv eudev".  First, I was happy to see that portage will automagically remove udev for me.  ("b", not "B")  Next I saw that I was removing udev-216 and installing eudev-1.10-r2.  The title of this thread is something about moving from udev-171-r10 to eudev-1.2-r1.  So by default I'm moving from a newer udev than this thread is discussing to an older eudev.  Somewhere in this thread there is a pointer to a udev upgrade guide, where they mention making sure CONFIG_FW_LOADER_USER_HELPER is not set.  I'm running 3.18.1 - I don't have that flag any more, but I have:
> ...

 

On my system

```

grep CONFIG_FW_LOADER /usr/src/linux/.config

CONFIG_FW_LOADER=y

# CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set

```

with

sys-kernel/vanilla-sources-3.18.1

sys-fs/eudev-2.1.1

Like you, I've purged all the *kit stuff and everything works fine/just like I remembered from before all that stuff got added... I've been meaning to dig out dbus, introspection, etc too (below is my current USE), but I haven't had time. Let us know how that all works out for you.

USE=-kde -systemd -pulseaudio -upower -gnome -gnome-keyring -gnome-online-accounts -consolekit -policykit

----------

## kurly

 *depontius wrote:*   

> Next I saw that I was removing udev-216 and installing eudev-1.10-r2.  The title of this thread is something about moving from udev-171-r10 to eudev-1.2-r1.  So by default I'm moving from a newer udev than this thread is discussing to an older eudev.

 

eudev-1.10-r2 is a newer version than eudev-1.2-r1.  Version points are not decimal points; trailing zeros are significant, and 10 is greater than 2.

----------

## depontius

 *kurly wrote:*   

>  *depontius wrote:*   Next I saw that I was removing udev-216 and installing eudev-1.10-r2.  The title of this thread is something about moving from udev-171-r10 to eudev-1.2-r1.  So by default I'm moving from a newer udev than this thread is discussing to an older eudev. 
> 
> eudev-1.10-r2 is a newer version than eudev-1.2-r1.  Version points are not decimal points; trailing zeros are significant, and 10 is greater than 2.

 

Oops.  Thanks on that one.  I just finished weekly updates, then did the move from udev to eudev on this system.  This response is typed after a reboot, so all went well.

----------

## augustin

Can you guys document what you can, here?

https://wiki.gentoo.org/wiki/Eudev

Thanks.

----------

## pjp

If anyone is wondering about newer versions...

I migrated from udev-216 to eudev-1.10-r2. Simple 'emerge eudev'.

I needed to create the link in /etc/init.d from net.lo to net.eth0 and add net.eth0 to the default runlevel (remove the unused interface from default or it will generate nuisance errors). I opted to leave the unused interface in /etc/init.d just in case (this way I don't need to remember what it was, non-intuitive name that it is).

Thanks for the info.

----------

## Myu

Hi pjp, 

Thanks for the info as well, I just made the switch easily from the very same version(s). Indeed the network interface name change back to the old convention with eudev.

----------

## jhon987

I've switched to eudev too, and I've got to hand it to the person who came up with the name: eudev (sounds like eeyew-dev)   :Laughing: 

----------

## virtguru

many thanks to all for their input in this thread , its a goldmine !   :Very Happy: 

----------

## Tony0945

 *Quote:*   

> I've switched to eudev too, and I've got to hand it to the person who came up with the name: eudev (sounds like eeyew-dev)

 

I think of it as the Greek prefix eu, meaning good.

----------

