Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
udev is doomed
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6  Next  
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Wed Feb 26, 2014 5:44 pm    Post subject: Reply with quote

elmar283 wrote:
EDIT: I'm not worried by the kernel config handling. I can change that, I'm worried about the systemd requirement.


What systemd requirement? There is no such requirement. The udev daemon executable and the network configuration is installed in /lib/systemd, but that's just a directory name, don't worry about it.
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Wed Feb 26, 2014 5:47 pm    Post subject: Reply with quote

Fitzcarraldo wrote:

I have read the News item several times, but still don't understand the second and third options.

If I understand correctly, you are saying that a file /etc/udev/rules.d/80-net-name-slot.rules containing just a comment will no longer work and there are now the following two options if one does not use the kernel parameter method:

- Create a file /etc/udev/rules.d/80-net-setup-link.rules containing just a comment,

or, alternatively,

- create a file /etc/systemd/network/99-default.link containing just a comment.

Is my understanding correct? If not, will you please specify the precise file names, including full paths, and the file contents, to avoid any doubt. Thanks in advance.


Correct. You have the directories and files correct.

Code:

$ strings /bin/udevadm | grep systemd/network
/etc/systemd/network
/run/systemd/network
/usr/lib/systemd/network
/lib/systemd/network


As you can see, multiple directories are searched for the .link file and the first 'wins'
Back to top
View user's profile Send private message
elmar283
Guru
Guru


Joined: 06 Dec 2004
Posts: 316
Location: Haarlem, Netherlands

PostPosted: Wed Feb 26, 2014 5:47 pm    Post subject: Reply with quote

Quote:
I can't be entirely specific but CONFIG_NET is used by systemd-udevd itself (the udev daemon executable) and CONFIG_FHANDLE is used by libudev.so.1

Ok, I have fhandle in my kernel now. Still I don't know wether udev-208 works without systemd.
The news item is not very clear about that just says:
Quote:
The actual configuration is at /lib/systemd/network/99-default.link, which
you can override in /etc/systemd/network/

And of course I don't have the path "/etc/systemd/network".


Last edited by elmar283 on Wed Feb 26, 2014 5:55 pm; edited 1 time in total
Back to top
View user's profile Send private message
elmar283
Guru
Guru


Joined: 06 Dec 2004
Posts: 316
Location: Haarlem, Netherlands

PostPosted: Wed Feb 26, 2014 5:54 pm    Post subject: Reply with quote

Quote:
What systemd requirement? There is no such requirement. The udev daemon executable and the network configuration is installed in /lib/systemd, but that's just a directory name, don't worry about it.


On my gentoo box there is no such directory that is called /lib/systemd. There is a /usr/lib/systemd.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Wed Feb 26, 2014 6:03 pm    Post subject: Reply with quote

elmar283 wrote:
The news item is not very clear about that just says:


That seems to be an ongoing problem, either you get no notification and thus have to start threads here
or you get confusing and not very well thought out news articles and have to start threads here for clarification.

The proper thing to do would be something similar to what happens in the real world.
Hand it to a documentation person and see what they say about it.
Barring that (if they're not available) then start a thread yourself, or ask one
or two of the people (via pm) on threads like this if the prototype news is clear or not.
It's not rocket science.

A large part of the problem with news articles like this is the person, usually a dev,
understands what he's trying to say, but doesn't take into account that others
don't have their level of understanding of what they're trying to communicate.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Wed Feb 26, 2014 6:11 pm    Post subject: Reply with quote

elmar283 wrote:
Quote:
What systemd requirement? There is no such requirement. The udev daemon executable and the network configuration is installed in /lib/systemd, but that's just a directory name, don't worry about it.


On my gentoo box there is no such directory that is called /lib/systemd. There is a /usr/lib/systemd.


Then you don't have >=sys-fs/udev-210 installed yet, or a bad INSTALL_MASK preventing it.

Code:

ssuominen@null ~ $ qlist -C sys-fs/udev |grep /lib/systemd
/lib/systemd/network/99-default.link
/lib/systemd/systemd-udevd
ssuominen@null ~ $ qlist -CIv sys-fs/udev
sys-fs/udev-210


The directory /usr/lib/systemd is irrelevant for sys-fs/udev. It's for sys-apps/systemd instead since it's installed mostly to /usr.
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Wed Feb 26, 2014 6:13 pm    Post subject: Reply with quote

elmar283 wrote:
Quote:
I can't be entirely specific but CONFIG_NET is used by systemd-udevd itself (the udev daemon executable) and CONFIG_FHANDLE is used by libudev.so.1

Ok, I have fhandle in my kernel now. Still I don't know wether udev-208 works without systemd.
The news item is not very clear about that just says:
Quote:
The actual configuration is at /lib/systemd/network/99-default.link, which
you can override in /etc/systemd/network/

And of course I don't have the path "/etc/systemd/network".


I don't understand where you got the idea that sys-fs/udev would be requiring systemd. That's not true at all. Also, the news item is for upgrading into >=sys-fs/udev-210, so while you are still at
=sys-fs/udev-208 or older, the news thread is irrelevant for you.
Back to top
View user's profile Send private message
luismw
Tux's lil' helper
Tux's lil' helper


Joined: 04 Jan 2010
Posts: 91

PostPosted: Wed Feb 26, 2014 6:26 pm    Post subject: Reply with quote

I know I may be playing the devil's advocate here but please, don't shoot the messenger.

The news items has been posted with plenty of time to prepare (at least for stable tree users), it suggests not one but two ways to keep "classic" interface names, and it even warns against using a too general INSTALL_MASK, when it shouldn't have to, strictly speaking. Also, no matter how I read it, it can't seem to find a place where the news item talks about systemd as a mandatory dependency.

I have no love at all for systemd and I plan to stop using udev as soon as it requires systemd, an eventuality which by the look of things I'm afraid is almost certain to happen, and rather soon, (I mean, if upstream had little regard for keeping things easy for upstart, does anyone really expect them to keep udev working for openrc in the medium/long term?) however, I find this news item clear, concise and useful, specially for people not running systemd.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Wed Feb 26, 2014 6:45 pm    Post subject: Reply with quote

luismw wrote:
I know I may be playing the devil's advocate here but please, don't shoot the messenger.
...
however, I find this news item clear, concise and useful, specially for people not running systemd.


I understood what he was saying, but I was a programmer for a long time.
I do beg to differ, it wasn't that clear, concise, yes, useful, maybe.
If it had been clear, then this thread with attendant questions would not have happened.

I was also aware that systemd wasn't required, but since he threw in mention of it,
without clarification, that caused some of the confusion. Me, I just looked at the ebuild.
Devs aren't known for being very good documentation people.
But you have to understand the audience that you are writing for even with news blurbs OR be prepared to answer lots of questions.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Wed Feb 26, 2014 6:58 pm    Post subject: Reply with quote

luismw wrote:
I know I may be playing the devil's advocate here but please, don't shoot the messenger.

The news items has been posted with plenty of time to prepare (at least for stable tree users), it suggests not one but two ways to keep "classic" interface names, and it even warns against using a too general INSTALL_MASK, when it shouldn't have to, strictly speaking. Also, no matter how I read it, it can't seem to find a place where the news item talks about systemd as a mandatory dependency.

I have no love at all for systemd and I plan to stop using udev as soon as it requires systemd, an eventuality which by the look of things I'm afraid is almost certain to happen, and rather soon, (I mean, if upstream had little regard for keeping things easy for upstart, does anyone really expect them to keep udev working for openrc in the medium/long term?) however, I find this news item clear, concise and useful, specially for people not running systemd.


Err, it's the otherway around, it's the service manager (systemd) which needs device manager (udev) -- which is why sys-apps/systemd has it's own internal copy of udev.
So you don't have to worry about sys-fs/udev, there is no need for device manager to start requiring a specific service manager -- udev dooesn't care what starts it.

I expect sys-fs/udev to be in Portage (and the default) for long as sys-apps/openrc is in Portage (and the default), as in, it's not going anywhere. I'll stop maintaining sys-fs/udev if sys-apps/systemd becomes the default, but that hasn't been even a topic yet, and propably never will be due to it's non-portability.
Back to top
View user's profile Send private message
dweezil-n0xad
Apprentice
Apprentice


Joined: 30 Oct 2006
Posts: 156
Location: Ostend, Belgium

PostPosted: Wed Feb 26, 2014 8:03 pm    Post subject: Reply with quote

With the update to udev-210, I rebuilt my kernel with CONFIG_FHANDLE and CONFIG_NET.
I need an initramfs to boot, my boot partition is on a hdd and my rootfs is on a ssd and the /dev/sd* names change regularly with my usb-disks. With an initramfs I can specify the rootfs as UUID.

Normally I create an initramfs with dracut but with udev-210 I get a "Cannot find [systemd-]udevd binary!" error. I made an initramfs with genkernel and that worked, all went well after reboot.
_________________
i7-4790K | 16GB DDR3 | GTX 970 | 500GB SSD
ASUS N56VV | i7-3630QM | 12GB DDR3 | GT 750M | 256GB SSD
Back to top
View user's profile Send private message
luismw
Tux's lil' helper
Tux's lil' helper


Joined: 04 Jan 2010
Posts: 91

PostPosted: Wed Feb 26, 2014 8:57 pm    Post subject: Reply with quote

ssuominen wrote:

Err, it's the otherway around, it's the service manager (systemd) which needs device manager (udev) -- which is why sys-apps/systemd has it's own internal copy of udev.
So you don't have to worry about sys-fs/udev, there is no need for device manager to start requiring a specific service manager -- udev dooesn't care what starts it.


Yes, I know it's the other way around, right now. However, it is my impression that systemd devs now see themselves as the owners of the only relevant init system for the only relevant UNIX descendant, and since they also maintain udev, the temptation not to keep it decoupled from the service manager may be too hard to resist.

Straight from the horse's mouth: "Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely." With upstart disappearing in the near future, I'm afraid that day is arriving rather soon.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 8933

PostPosted: Wed Feb 26, 2014 9:01 pm    Post subject: Reply with quote

Where have you been the last few years? udev is no more or less doomed today than it was when it got merged into the systemd tarball. You are merely duplicating the whirl we had when that happened. However, udev so far still works fine by itself.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54096
Location: 56N 3W

PostPosted: Wed Feb 26, 2014 9:05 pm    Post subject: Reply with quote

ssuominen wrote:
... which is why sys-apps/systemd has it's own internal copy of udev.

ssuominen wrote:
I'll stop maintaining sys-fs/udev if sys-apps/systemd becomes the default ...


Well, with everyone on systemd and systemd using its internal udev, there would be nothing to maintain and nobody to maintain it for would there ... apart from the non systemd users.

The cynic in me reads that as unless someone steps up to maintain udev should Gentoo switch to systemd as a default, udev will be dead on Gentoo.
That about confirms that udev is a dead end and that users wishing to avoid systemd should evaluate udev replacements.

Ah well, just as well a device manager free system still works.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Aiken
Apprentice
Apprentice


Joined: 22 Jan 2003
Posts: 239
Location: Toowoomba/Australia

PostPosted: Wed Feb 26, 2014 9:15 pm    Post subject: Reply with quote

ssuominen wrote:
Aiken wrote:
It is not hard to read the news then forget about it.


It's not hard to read a postinst message and then forget about it, but reading an official Portage news item that's meant for critical messaging can't be just shoved off by 'I forgot, and now I will blame others.'
As in, there is a world of difference between Package postinst messages and the Portage news items.

[1] http://wiki.gentoo.org/wiki/GLEP:42#Motivation


A postinst message is not going to be read when there have been enough messages that is off the screen and out of the scroll back buffer. That should not be hard to understand. Postinst message are not always going to be seen. News items can be read and forgotten about. Not hard to read something then forget about it 2 - 3 months later which is when the 204 upgrade bit me.

I still maintain it was stupid having a package install even when it will kill a working system. Also as I said before udev aborting the boot sequence when it has a problem on a computer that is capable of booting without udev running does not help. From problems the 204 upgrades caused people, the unpredictable network names and your udev should upgrade regardless attitude I do no trust udev upgrades.
_________________
Beware the grue.
Back to top
View user's profile Send private message
Gatsby
Tux's lil' helper
Tux's lil' helper


Joined: 18 Jan 2010
Posts: 116
Location: 127.0.0.1

PostPosted: Wed Feb 26, 2014 9:16 pm    Post subject: Reply with quote

genstorm wrote:
Where have you been the last few years? udev is no more or less doomed today than it was when it got merged into the systemd tarball. You are merely duplicating the whirl we had when that happened. However, udev so far still works fine by itself.


You are missing the point. With systemd infiltrating more and more linux distributions -including gentoo- things are today
far more worse and doomed then they used to be when udev was included into the systemd tarball.

Gatsby


np: Hand Of Doom - Black Sabbath
_________________
Γνωθι σεαυτον.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Wed Feb 26, 2014 9:19 pm    Post subject: Reply with quote

NeddySeagoon wrote:
The cynic in me reads that as unless someone steps up to maintain udev should Gentoo switch to systemd as a default, udev will be dead on Gentoo.
That about confirms that udev is a dead end and that users wishing to avoid systemd should evaluate udev replacements.


Pretty much, despite the labeling of those who saw this coming as conspiracists.

Quote:
Ah, just as well a device manager free system still works.


Yep.

Udev worked well in the past before the systemd people managed to take control of it.
I doubt very seriously that the previous maintainers thought that this would happen.
I'm hoping that the kernel people will just do the right thing and put a simplified udev into the kernel.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 8933

PostPosted: Wed Feb 26, 2014 9:24 pm    Post subject: Reply with quote

Gatsby wrote:
You are missing the point. With systemd infiltrating more and more linux distributions -including gentoo- things are today
far more worse and doomed then they used to be when udev was included into the systemd tarball.

...my point being that development was foreseeable back then already. And I suspect that a continued upstart effort wouldn't have changed much in that regard.
Back to top
View user's profile Send private message
Gatsby
Tux's lil' helper
Tux's lil' helper


Joined: 18 Jan 2010
Posts: 116
Location: 127.0.0.1

PostPosted: Wed Feb 26, 2014 9:37 pm    Post subject: Reply with quote

genstorm wrote:
Gatsby wrote:
You are missing the point. With systemd infiltrating more and more linux distributions -including gentoo- things are today
far more worse and doomed then they used to be when udev was included into the systemd tarball.

...my point being that development was foreseeable back then already. And I suspect that a continued upstart effort wouldn't have changed much in that regard.


No one foresaw the stubbornness of the systemd people pushing their case forward.
They were too long underestimated concerning their negative and malicious efforts
concerning the whole linux community. Now or never is the time to deal with them.

Gatsby
_________________
Γνωθι σεαυτον.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 8933

PostPosted: Wed Feb 26, 2014 9:39 pm    Post subject: Reply with quote

Gatsby wrote:
No one foresaw the stubbornness of the systemd people pushing their case forward.
They were too long underestimated concerning their negative and malicious efforts
concerning the whole linux community. Now or never is the time to deal with them.

As I said, same discussion we had back then.
Back to top
View user's profile Send private message
Gatsby
Tux's lil' helper
Tux's lil' helper


Joined: 18 Jan 2010
Posts: 116
Location: 127.0.0.1

PostPosted: Wed Feb 26, 2014 9:50 pm    Post subject: Reply with quote

genstorm wrote:
Gatsby wrote:
No one foresaw the stubbornness of the systemd people pushing their case forward.
They were too long underestimated concerning their negative and malicious efforts
concerning the whole linux community. Now or never is the time to deal with them.

As I said, same discussion we had back then.



May be, but today we know what happened in the meantime and what will probably happen soon. :roll:
So far it is a different situation.

Gatsby
_________________
Γνωθι σεαυτον.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 8933

PostPosted: Wed Feb 26, 2014 9:57 pm    Post subject: Reply with quote

Nothing changed today that we didn't know yesterday already. And when udev finally won't work standalone tomorrow, someone can still fork it. Or move to alternative dev management that has existed all the while. So far, however, udev still works perfectly fine.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Wed Feb 26, 2014 10:02 pm    Post subject: Reply with quote

Gatsby wrote:
No one foresaw the stubbornness of the systemd people pushing their case forward.


No, there were some of us who saw what was going to happen, despite the lies of a dev and sycophants.
What so upsets people is that some of us saw through the lies.

Right now it's very obvious to many that udev is about to be subsumed within systemd.
And just like logind there won't be something separate, there soon won't be a choice except to take the whole ball of wax.
If people want to accept that, I don't care, any more than I care that people want to use some flavor of windows or apple product.
But it's bloody obvious what is coming down the road.
I despise people who try and lie to me and tell me I'm too stupid to see what's coming when it's obvious.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 483
Location: Gainesville, FL, USA

PostPosted: Wed Feb 26, 2014 10:14 pm    Post subject: Reply with quote

ssuominen wrote:
You don't seem to understand what should, and what should't be fatal. What if I'm building my udev on a different machine and then deploy the created binary package to another machine, which in fact has a kernel with all the latest and greatest requrements enabled? Then what does it matter what options you have enabled in the build host? None, whatsoever.
So what you are suggesting would completely kill off the consept of creating binary packages on a another machine (build host) which Portage has supported for years.
If you don't read news items, or warnings of missing kernel features from the Portage, that's really completely your own fault, called poor administration.

Hear hear! Being able to build on a binhost is a great thing and we should take care that we can continue to do that reliably in the future. It's a wonderful technique that I'm using more and more since it maximizes the usability of my production machines.

Binary packages still include all the installation-time testing. Emerging them still writes message to the log. The install-time tests would be a really opportune place to check for kernel options. I agree that it is quite unwise to ignore the elog messages. I always prefer building new systems by ssh'ing into them for this reason: I can have a long scrollback buffer in my terminal window. There are all kinds of useful things lurking in those messages--a thing I've learned through unhappy experience.

(Another technique for capturing those messages is in screen. You can use that quite well if even you are working at a framebuffer.)

I don't know if an ebuild can be made to fail in the installation-test phase; if ebuilds can, it might be helpful here. Certainly, though, a news item for this kind of thing would be very welcome.

Lest you find my answer too agreeable, let me point out that I'm a happy eudev user. I avoid a lot of drama that way.
Back to top
View user's profile Send private message
kurly
Apprentice
Apprentice


Joined: 02 Apr 2012
Posts: 260

PostPosted: Thu Feb 27, 2014 1:35 am    Post subject: Reply with quote

genstorm wrote:
Nothing changed today that we didn't know yesterday already. And when udev finally won't work standalone tomorrow, someone can still fork it. Or move to alternative dev management that has existed all the while. So far, however, udev still works perfectly fine.
There already is such a fork, eudev. At least one developer participating in this thread is openly hostile to that fork. Works great for me, and I get to avoid much of the drama. It's like udev minus certain unnecessary changes.
Back to top
View user's profile Send private message
Display posts from previous:   
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 2 of 6

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum