Mailing List Archive

On Mon, Aug 10, 2020 at 08:49:20AM -0400, Rich Freeman wrote:
> On Mon, Aug 10, 2020 at 8:16 AM Thomas Deutschmann <whissi@gentoo.org> wrote:
> >
> > On 2020-08-10 14:07, Micha? Górny wrote:
> > > ...or a revert of a change made for change's sake.
> >
> > That's a bold statement for an unambiguous 7-0 decision as seen in
> > https://bugs.gentoo.org/575718.
>
> As one who voted yes, my rationale is already in the bug comments, and
> I voted yes because it seemed to be the preference of most non-systemd
> users on the mailing list. I can't say whether this is still the case
> but I'm guessing it is. I don't think it is really a well-founded
> preference but I don't really see a point in fighting it when people
> can use whichever they prefer.

My rationale for voting yes was based on the idea that it would
be easy to switch back, and even if we did, it would be easy for
someone to switch to eudev if they want it.

> If the eudev bus factor drops from 1 to 0 and people get tired of
> dealing with it, I suspect switching back will become more popular.
> If that never happens that is fine too. If people have unusual
> configs not addressed by eudev, or just plain old good taste, they
> can always use udev or systemd.
>
> If eudev were causing serious problems or holding back other projects
> for some reason I'd feel differently. Otherwise I tend to agree with
> the sense that if you're going to make a change there should be a
> reason. The reason for the previous change was that a strong majority
> had a strong preference. Based on the tone of discussion I'm not sure
> that has changed - there isn't as much vehemence in the discussion,
> but I suspect that is mostly because most don't think this is likely
> to happen so they don't bother to reply.

There's another interpretation. Most users or developers don't care.

No one has offered to switch from eudev to udev and look at
regressions. People are asking me to show what features exist in udev
that aren't in eudev. I stuck with udev. I don't use eudev so I don't
know.

As I have said earlier on the thread, we should look at udev and seee if
it breaks things in relation to eudev. That would take some folks
migrating their systems and reporting issues.

William

On Mon, Aug 10, 2020 at 12:00:44AM -0400, Joshua Kinard wrote:
> On 8/8/2020 14:51, William Hubbs wrote:
> > All,
> >
> > I would like to propose that we switch the default udev provider on new
> > systems from eudev to udev.
> >
> > This is not a lastrites, and it will not affect current systems since
> > they have to migrate manually. Also, this change can be overridden at
> > the profile level if some profile needs eudev (the last time I checked,
> > this applies to non-glibc configurations).
> >
> > What do people think?
> >
> > Thanks,
> >
> > William
>
> Is eudev broken in some way? If so, has a bug been filed? If not, why not?
>
> If eudev is not broken, then why your proposed fix?

bitrot and bus factor.

> It works fine for new installs, having just done one myself. Seems like we
> aught to keep it that way. I count six open bugs against eudev right now,
> and none of them look to be critical, so I vote "no" on your proposal unless
> there is some verifiable reason why eudev is no longer suitable to be the
> default udev provider.

The thing is, udev was never unsuitable. AS I said the original change
was not because of the lack of suitability, but because of fear of what
the udev devs might do. That fear never came true.

Not that it matters much, but I'll go there since you did, I count 26
open issues against eudev and some of them have been open since 2012.

William

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, 8 Aug 2020 13:51:41 -0500
William Hubbs <williamh@gentoo.org> wrote:

> All,
>
> I would like to propose that we switch the default udev provider on
> new systems from eudev to udev.
>
> This is not a lastrites, and it will not affect current systems since
> they have to migrate manually. Also, this change can be overridden at
> the profile level if some profile needs eudev (the last time I
> checked, this applies to non-glibc configurations).
>
> What do people think?

No opinion on which to choose, I use the default one at the time I do
an install and have been happy with both.

My main concern is that since the change won't be "live" until a
switched virtual reaches stable, eudev will still be much better tested
in our environment at this point, and people might uncover corner cases
when it's too late. Maybe a compromise could be to provide and
primarily advertise udev stages before making the switch ?

Alexis.
-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQSpOxaxaZikKNVNlsYOJUi7xgflrgUCXzFsKAAKCRAOJUi7xgfl
rkDGAP9no3aFUEIPFr3mPHp9lUmIk7ZUl+njCpQo0+GsgoFVuQD+OG2zf3SVSOPs
hrYNa/PYEHKujS/Rfk2m180it41yDwM=
=/0De
-----END PGP SIGNATURE-----

On 2020.08.10 16:22, William Hubbs wrote:
> On Mon, Aug 10, 2020 at 12:00:44AM -0400, Joshua Kinard wrote:
> > On 8/8/2020 14:51, William Hubbs wrote:
> > > All,
> > >
> > > I would like to propose that we switch the default udev provider
> on new
> > > systems from eudev to udev.
> > >
> > > This is not a lastrites, and it will not affect current systems
> since
> > > they have to migrate manually. Also, this change can be overridden
> at
> > > the profile level if some profile needs eudev (the last time I
> checked,
> > > this applies to non-glibc configurations).
> > >
> > > What do people think?
> > >
> > > Thanks,
> > >
> > > William
> >
> > Is eudev broken in some way? If so, has a bug been filed? If not,
> why not?
> >
> > If eudev is not broken, then why your proposed fix?
>
> bitrot and bus factor.
>
> > It works fine for new installs, having just done one myself. Seems
> like we
> > aught to keep it that way. I count six open bugs against eudev
> right now,
> > and none of them look to be critical, so I vote "no" on your
> proposal unless
> > there is some verifiable reason why eudev is no longer suitable to
> be the
> > default udev provider.
>
[snip]
> ...because of fear of
> what
> the udev devs might do. That fear never came true.
>
[snip]
>
> William
>

William,

Never is a very long time.
That promise has not been made good ... yet.

--
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

On Mon, Aug 10, 2020 at 05:47:52PM +0200, Alexis Ballier wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Sat, 8 Aug 2020 13:51:41 -0500
> William Hubbs <williamh@gentoo.org> wrote:
>
> > All,
> >
> > I would like to propose that we switch the default udev provider on
> > new systems from eudev to udev.
> >
> > This is not a lastrites, and it will not affect current systems since
> > they have to migrate manually. Also, this change can be overridden at
> > the profile level if some profile needs eudev (the last time I
> > checked, this applies to non-glibc configurations).
> >
> > What do people think?
>
> No opinion on which to choose, I use the default one at the time I do
> an install and have been happy with both.
>
> My main concern is that since the change won't be "live" until a
> switched virtual reaches stable, eudev will still be much better tested
> in our environment at this point, and people might uncover corner cases
> when it's too late. Maybe a compromise could be to provide and
> primarily advertise udev stages before making the switch ?

Creating udev stages would require a separate profile which would be
removed once we did the default switch, so I'm not sure if we want to go
that route. Does anyone remember if we did this for the original eudev
switch? If we did, I am open to doing it again, but I honestly don't recall.

All of the providers are stable currently, so my thought is a tracker +
newsitem with a delay before switching the default. I'm thinking about a
30 day test window where we ask people to migrate their systems and
if they find issues open bugs that block the tracker.

Thoughts?

William

Hi,

To summarize

- There's no known bugs in eudev that are not in udev
- There's no bug that would be fixed by switch from eudev to udev
- There's no new feature that would change eudev to udev bring
- Currently musl and glibc profiles uses common eudev, after change we
whould have musl profile users use something that glibc users are not using
- You don't like the original decision to switch to eudev so you want
now to use uno reverse card.
- eudev have single maintainer, but so far it did not had negative
impact on Gentoo

I see no reason to switch to sys-fs/udev by default, up until there's
actually a technical reason behind it. The eudev is a thing because
systemd upstream made it clear that they have no intention into keeping
udev operational unless it runs under systemd, which is quite important
here.

-- Piotr.

On 8/10/2020 11:22, William Hubbs wrote:
> On Mon, Aug 10, 2020 at 12:00:44AM -0400, Joshua Kinard wrote:
>> On 8/8/2020 14:51, William Hubbs wrote:
>>> All,
>>>
>>> I would like to propose that we switch the default udev provider on new
>>> systems from eudev to udev.
>>>
>>> This is not a lastrites, and it will not affect current systems since
>>> they have to migrate manually. Also, this change can be overridden at
>>> the profile level if some profile needs eudev (the last time I checked,
>>> this applies to non-glibc configurations).
>>>
>>> What do people think?
>>>
>>> Thanks,
>>>
>>> William
>>
>> Is eudev broken in some way? If so, has a bug been filed? If not, why not?
>>
>> If eudev is not broken, then why your proposed fix?
>
> bitrot and bus factor.

Examples? I don't necessarily stay abreast of what new gizmos upstream udev
may or may not be adding that eudev may or may not be missing. Is there
something critical that you have observed going into upstream udev that
eudev is missing that would be super-awesome or which otherwise improves the
lives of aspiring Gentoo users everywhere? Or is it related to unpatched
security issues, perhaps? Is there a list of unmitigated CVE's that
upstream udev has patched that the eudev team has not?

Have you tried reaching out to the eudev developer(s) to see if they're
responsive and to maybe raise your concerns about aforementioned "bitrot"?


>> It works fine for new installs, having just done one myself. Seems like we
>> aught to keep it that way. I count six open bugs against eudev right now,
>> and none of them look to be critical, so I vote "no" on your proposal unless
>> there is some verifiable reason why eudev is no longer suitable to be the
>> default udev provider.
>
> The thing is, udev was never unsuitable. AS I said the original change
> was not because of the lack of suitability, but because of fear of what
> the udev devs might do. That fear never came true.

You meant to say "has yet to come true". Show me something from the
upstream udev developers where they permanently close the door to making
udev a symbiotic element to systemd and then I'll accept your use of past
tense. Elsewise, as long as that door remains open, then future tense is
the correct tense.

>
> Not that it matters much, but I'll go there since you did, I count 26
> open issues against eudev and some of them have been open since 2012.

My search was based on the string "sys-fs/eudev", which is the standard
nomenclature for naming bugs. If there are other bugs open for eudev that
are missing that, then they need their titles updated.

--
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

On Mon, Aug 10, 2020 at 9:55 PM Joshua Kinard <kumba@gentoo.org> wrote:
>
> On 8/10/2020 11:22, William Hubbs wrote:
> > On Mon, Aug 10, 2020 at 12:00:44AM -0400, Joshua Kinard wrote:
> >>
> >> If eudev is not broken, then why your proposed fix?
> >
> > bitrot and bus factor.
>
> Examples?

The sole maintainer of eudev is going to suddenly disappear before
getting a chance to tell anybody about the horrible security issue
they discovered earlier that day.

> You meant to say "has yet to come true".
>....
> Elsewise, as long as that door remains open, then future tense is
> the correct tense.

Note that the disappearance of the sole maintainer of eudev has yet to
happen, but we absolutely need to be taking steps today because
everybody knows it will happen. After all, it COULD happen, and so as
long as that door remains open the future tense is the correct tense.
:)

I find it amusing that everybody is still trembling in fear that
Lennart is going to take their shell scripts away from them in the
middle of the night. But it isn't like anybody needs to touch that
cruft if they don't want to just because they're working on Gentoo, so
whatever rocks your boat.

Really though I'd just stick with "ain't broke don't fix it" as there
really is no reason to get into paranoid FUD.

--
Rich

On 8/10/2020 22:08, Rich Freeman wrote:
> On Mon, Aug 10, 2020 at 9:55 PM Joshua Kinard <kumba@gentoo.org> wrote:
>>
>> On 8/10/2020 11:22, William Hubbs wrote:
>>> On Mon, Aug 10, 2020 at 12:00:44AM -0400, Joshua Kinard wrote:
>>>>
>>>> If eudev is not broken, then why your proposed fix?
>>>
>>> bitrot and bus factor.
>>
>> Examples?
>
> The sole maintainer of eudev is going to suddenly disappear before
> getting a chance to tell anybody about the horrible security issue
> they discovered earlier that day.
>
>> You meant to say "has yet to come true".
>> ....
>> Elsewise, as long as that door remains open, then future tense is
>> the correct tense.
>
> Note that the disappearance of the sole maintainer of eudev has yet to
> happen, but we absolutely need to be taking steps today because
> everybody knows it will happen. After all, it COULD happen, and so as
> long as that door remains open the future tense is the correct tense.
> :)

I don't disagree completely with your logic, but I *do* disagree that
changing the default udev provider to sys-fs/udev is the best option, or the
only option.


> I find it amusing that everybody is still trembling in fear that
> Lennart is going to take their shell scripts away from them in the
> middle of the night. But it isn't like anybody needs to touch that
> cruft if they don't want to just because they're working on Gentoo, so
> whatever rocks your boat.

I don't tremble in fear. I am past that stage at this point, and have just
accepted the fact that at some point, the Linux I used to know and love will
be something I can't work with anymore, and I'll just need to pack my
proverbial bags and move on to greener pastures. The day when Linux and
systemd become inseparable will happen. But it won't be like going to sleep
the night before and waking up in an alien world. The change will be slow
and gradual, just like it has been for the past eight-plus years. The
question is more, what is my tolerance? At what point do I give up and move
on? Haven't found that answer yet, so here I still am, arguing.


> Really though I'd just stick with "ain't broke don't fix it" as there
> really is no reason to get into paranoid FUD.

"Ain't broke don't fix it" doesn't apply here. My read of recent messages
on this thread suggest to me the change is going to happen, regardless what
a number of us think about it. See last few sentences of the prior
paragraph above.

--
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Hi William,

William Hubbs <williamh@gentoo.org> writes:

> No one has offered to switch from eudev to udev and look at
> regressions. People are asking me to show what features exist in udev
> that aren't in eudev. I stuck with udev. I don't use eudev so I don't
> know.

I don't think imposing a personal preference to the Gentoo default a good
idea. One person who get stuck with udev does not bring everyone to
stick with udev.

Benda

On Tue, 2020-08-11 at 10:59 +0800, Benda Xu wrote:
> Hi William,
>
> William Hubbs <williamh@gentoo.org> writes:
>
> > No one has offered to switch from eudev to udev and look at
> > regressions. People are asking me to show what features exist in udev
> > that aren't in eudev. I stuck with udev. I don't use eudev so I don't
> > know.
>
> I don't think imposing a personal preference to the Gentoo default a good
> idea. One person who get stuck with udev does not bring everyone to
> stick with udev.
>

So why is the current default based on a personal preference?

--
Best regards,
Micha? Górny

On Mon, 2020-08-10 at 21:55 -0400, Joshua Kinard wrote:
> On 8/10/2020 11:22, William Hubbs wrote:
> > On Mon, Aug 10, 2020 at 12:00:44AM -0400, Joshua Kinard wrote:
> > > On 8/8/2020 14:51, William Hubbs wrote:
> > > > All,
> > > >
> > > > I would like to propose that we switch the default udev provider on new
> > > > systems from eudev to udev.
> > > >
> > > > This is not a lastrites, and it will not affect current systems since
> > > > they have to migrate manually. Also, this change can be overridden at
> > > > the profile level if some profile needs eudev (the last time I checked,
> > > > this applies to non-glibc configurations).
> > > >
> > > > What do people think?
> > > >
> > > > Thanks,
> > > >
> > > > William
> > >
> > > Is eudev broken in some way? If so, has a bug been filed? If not, why not?
> > >
> > > If eudev is not broken, then why your proposed fix?
> >
> > bitrot and bus factor.
>
> Examples?

I suppose nobody remembers the time (the previous year) where eudev
broke reverse dependencies because of wrong version number, and it took
around 3 months to get a fix (read: changing the version number) into
~arch.

--
Best regards,
Micha? Górny

Ühel kenal päeval, T, 11.08.2020 kell 07:44, kirjutas Micha? Górny:
> > Examples?
>
> I suppose nobody remembers the time (the previous year) where eudev
> broke reverse dependencies because of wrong version number, and it
> took
> around 3 months to get a fix (read: changing the version number) into
> ~arch.

Having forgotten about that (even when being directly involved in it),
it doesn't look all that bad in this example on hindsight.

Upstream issue tracker got a notification of it (being unusable for
mutter) in https://github.com/gentoo/eudev/issues/173 on 2019-05-12.
It was fixed upstream eudev on 2019-05-19, and the fix was released
into eudev-3.2.8, released on 2019-05-20.

But Gentoo virtual/libudev-232 still claimed >=eudev-1.3 is fine for
it, while mutter had to depend on >=virtual/libudev-228.
So eudev-3.2.8 already available in main tree was fine for mutter, but
there was no virtual/libudev-228, which would ensure >=eudev-3.2.8 and
that eudev version wasn't stable. So a quick fix would have been to add
a virtual/libudev-228 too in ~arch, which would have given a way to
ensure 228 by eudev-3.2.8, but this seems to have been overlooked,
thinking that a new eudev release is needed. This was compounded by no
(rather) quick replies from eudev maintainers to advise what to do with
the virtual. Eventually eudev-3.2.9 ended up being what is required, as
it provides claimed compatibility with libudev-243, which is new enough
for virtual/libudev-232.
So after initial Gentoo problem report[1] on 2019-09-11, and the
virtual/libudev bug report[2] on 2019-10-12, it all got solved by
stabilization request[3] of eudev-3.2.9 (and virtual/libudev restoring
eudev as provider) on 2019-10-28 with main arches dealing with it the
same day. ~arch was fixed on 2019-10-26, 1.5 months after initial bug
report, which per the above actually turns out actually not been an
~arch problem, but ~arch mutter mixed with stable eudev. Affected
mutter version was only stabilized in 2019-12-08.

So virtual/libudev dropping eudev as provider for this forced stable
tree to be fixed to be technically correct.
I think the main takeaway point is that on virtual/libudev version
bumps, the eudev claimed versions need to be checked as well, and the
matching >= dep for eudev figured out from the start. What each eudev
version claims as the libudev version can be seen in the UDEV_VERSION
variable set at top of configure.ac.

Personally I believe the first choice for virtual/udev should be
sys-fs/udev instead of sys-fs/eudev for our users, as it's more
maintained upstream, but don't have any personal stake in it as my udev
provider is systemd.

Various changes in udev upstream that wouldn't be in eudev (yet) would
be dealing with rule changes and bug fixes, which aren't relevant to
those people that aren't affected by these bugs, but very relevant if
you are affected by them.

I don't think it would be impossible to have musl-supporting out of the
box udev out of systemd tarball, if there was someone actually working
with upstream systemd on it in a constructive manner, effectively being
the musl support maintainer as part of upstream community.


Mart


References:
1. https://bugs.gentoo.org/694014
2. https://bugs.gentoo.org/697550
3. https://bugs.gentoo.org/698698

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

> As I have said earlier on the thread, we should look at udev and seee if
> it breaks things in relation to eudev. That would take some folks
> migrating their systems and reporting issues.

And I've already provided you one use case where udev doesn't work well
but eudev does.  I've also mentioned some historic issues I believe
should already be fixed but which did bit me in systemd-udev which was
never a problem in eudev.

But then again, with past experience I'm now one of those that refuse to
install systemd-udev and give it a twirl on production systems to see if
it's still an issue whereby I end up rebooting servers on a weekly basis.

Kind Regards,
Jaco

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEyyCUcKjG7P5BDam8CC3Esa/37p4FAl8yWHEACgkQCC3Esa/3
7p6w1wf/clHZuUn3KgCheQQvEyBSBf3IEmXgN+ejtxGNn+cyK4p6A7j3dU6n9ain
aPcL4zGOkixHpEwhz2bQAIljEtHI2wYhBYBv7+c9mUEmbSp7xhwZUvZd1a69YUk1
cEclzHGlKQwcRFqyrGIOLk6/iuwr8REavd1EwcLsrXeuCI7xukFRdHeOideGCztI
4ziK6QZaN/BZ1ZPV1yzdheBq2E0tAiMRG2gKiuNopBEETc+PpegUPsk6T4dnmEZV
EGG3LlzpufgPUF+qymzyRiT94i7azebfO17hOzJ4cZJXi7Lz9dzUTrxJvpYknbzp
XruDKuoRBSPp5OQ2ZeO/0Q0L8WILZg==
=Q6Bl
-----END PGP SIGNATURE-----

On 8/11/20 11:36 AM, Jaco Kroon wrote:
> And I've already provided you one use case where udev doesn't work well
> but eudev does.  I've also mentioned some historic issues I believe
> should already be fixed but which did bit me in systemd-udev which was
> never a problem in eudev.
>
Your systems seem to diverge a lot from what I'd consider as 'default'.
You must already make many changes to them.

Before this thread I didn't even know/remember I was using eudev. It
works and there doesn't seem to be any global issues related to it.
However after reading this thread I'm a bit considered about the
maintenance state of it.

Switched to udev. Simple as 'emerge -1 sys-fs/udev'. It works, didn't
notice any difference.

If musl is a problem, to my knowledge musl has its own stage images, so
why can't those stages use eudev while other ones defaulting to udev?

-- juippis

On 11/08/2020 15.38, Joonas Niilola wrote:
>
> On 8/11/20 11:36 AM, Jaco Kroon wrote:
>> And I've already provided you one use case where udev doesn't work well
>> but eudev does.  I've also mentioned some historic issues I believe
>> should already be fixed but which did bit me in systemd-udev which was
>> never a problem in eudev.
>>
> Your systems seem to diverge a lot from what I'd consider as 'default'.
> You must already make many changes to them.
>
> Before this thread I didn't even know/remember I was using eudev. It
> works and there doesn't seem to be any global issues related to it.
> However after reading this thread I'm a bit considered about the
> maintenance state of it.
>
> Switched to udev. Simple as 'emerge -1 sys-fs/udev'. It works, didn't
> notice any difference.
>
> If musl is a problem, to my knowledge musl has its own stage images, so
> why can't those stages use eudev while other ones defaulting to udev?

For the sake of science, I've also moved one of my systems to
sys-fs/udev and noticed a single incompatibility. There are few ways how
to disable the systemd/udev predictable NIC names, one of them is to
boot with net.ifnames=0, another is to mask rule file that trigger the
rename, as described on wiki[1]

Long story short, on eudev it's 80-net-name-slot.rules, on udev it's
80-net-setup-link.rules

The result was that my system booted without working network, as connman
started to poke around Ethernet interfaces (this is ok, I had
blacklisted eth*, not enp*), which then resulted in switching routing to
Ethernet that failed to get IP from DHCP, even that WiFi had a fully
working Internet access, so more like connman bug. (And yes, I am aware
that net.ifnames=0 will work on both)

This however shows two things: eudev is (no longer) drop-in replacement,
as some interfaces changed in upstream udev, which leads to second
thing, we need to have migration path, because even if(!) Gentoo change
default (I am not a fan of this idea really), then it might lead to
people doing fresh installation or reinstallation, migrating their
configs resulting in not working systems/working in other way that
previous one.

[1] https://wiki.gentoo.org/wiki/Udev#Keep_classic_.27eth0.27_naming

-- Piotr.

On Sat, Aug 8, 2020 at 8:51 PM William Hubbs <williamh@gentoo.org> wrote:

> All,
>
> I would like to propose that we switch the default udev provider on new
> systems from eudev to udev.
>
> This is not a lastrites, and it will not affect current systems since
> they have to migrate manually. Also, this change can be overridden at
> the profile level if some profile needs eudev (the last time I checked,
> this applies to non-glibc configurations).
>
> What do people think?
>
> Thanks,
>
> William
>
>
I had the opposite problem, udev failed to work with newer
udev-init-scripts so all my systems were migrated to eudev. Looking at the
bug report (https://bugs.gentoo.org/681586), some of the others had the
same experience.

It was a drop-in replacement for me, personally I don't care if I have udev
or eudev installed (if it works).

Tomas