Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Udev--171-r10 to be removed from Portage
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Tue Mar 19, 2013 6:30 am    Post subject: Reply with quote

krinn wrote:
ssuominen wrote:
No, currently eudev doesn't solve anything. It's something you might use if you want to contribute to make it useful, but nothing to be recommended for any user since there is currently no gain.

I'm too a user with mask udev >171 so i will get hit too by this lost of udev-171 from the tree.
My question is then : i don't see any gain but problems (that network scheme is problem, as it bug user and solve nothing) to use udev > 171, and you said there's no gain from evdev, but is there are lost ? Because no gain + trouble vs no gain + no lost will answer my next step.


What eudev hasn't done yet is drop the broken support for renaming into existing namespace reserved by the kernel, like udev has done. This is one feature getting replaced by better feature,
the old rule_generatator with the predictable scheme. I'm not going to debate here about it, again, I'll rather make people make up their own mind and point them to the kernel documentation
and discussion between udev and kernel developers:

http://lkml.indiana.edu/hypermail/linux/kernel/1010.1/00427.html
http://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

I don't know how they could be any more clear with
Quote:
Note: Don't call this function.
from the second link.
Back to top
View user's profile Send private message
BitJam
Advocate
Advocate


Joined: 12 Aug 2003
Posts: 2508
Location: Silver City, NM

PostPosted: Tue Mar 19, 2013 7:24 am    Post subject: Reply with quote

@ssuominen, it seems like you consider that making a system unbootable is not a "user visible problem". Your response to such problems is to pretend they don't exist.

I'd be much more satisfied if you had posted the migration how-to that MoonWalker asked for instead of links about the bright and rosy future that udev will usher in. IMO it is at best disingenuous to proclaim a naming convention that has been working on millions of systems for many years is broken while the "fix" you are pushing can actually break systems like MoonWalker's server.

I don't dispute that in the future the new system will probably be better. What we are talking about here are the real-world problems that these so-called long-term fixes are causing. Perhaps it is a communication problem. The easy migration guide MoonWalker asked for could go a long way towards fixing this.

Regardless of the cause, udev upgrades have resulted in a lot of system breakage. This tends to make the recipients rather grumpy. I realize this is coming for upstream but ISTM you are in a position to be part of the solution instead of part of the problem. We need practical advice and clear instructions not a lecture on why the upgrades that break our systems are actually good for us or proclamations that the breakage doesn't exist.

We could really use your help here.
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: Tue Mar 19, 2013 9:42 am    Post subject: Reply with quote

The Doctor wrote:
As I understand it, what eudev has that udev does not is support for older kernels and is built over an older release. The things like separate /usr support have been patched back into udev so the practical difference is not that great. It certainly isn't upstream supporting separate /usr and such. They specifically drooped that support. I think it would be rather its rather rich to blame the devs for upstream trying to force systemd on the world. Whether we like it or not, udev has become a critical component of most desktop environments.


I used the same udev 171-r6 with 3.4.10 which I was running for years, and it also works well with 3.8.1.
I've updated the hwids, but I don't use upower, or any gvfs based silliness, preferring to manually mount things when I need them.
What udev offers is basically a way to populate /dev without having the end user to manually do it.

One day in the not too far future, the systemd people will likely state that udev won't be supported without using systemd itself.
There's already rumblings about that on some of the kernel and other mailing lists.
This is a valid reason for keeping eudev around, even if it's not the latest ala "the official udev".

Just some thoughts.

Edit to add: I don't want what I've said to be taken the wrong way.
I appreciate what the devs, both kernel and gentoo have been and are doing,
especially since they don't get paid. I'm just not too sure about the motives of
the udev/systemd people and I would like the end users to keep having a
viable alternative just in case. Some alternative that doesn't break an existing system
or cause undue hardship in trying to figure out why said system has quit working.
_________________
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
Gusar
Advocate
Advocate


Joined: 09 Apr 2005
Posts: 2665
Location: Slovenia

PostPosted: Tue Mar 19, 2013 11:57 am    Post subject: Reply with quote

BitJam wrote:
I'd be much more satisfied if you had posted the migration how-to that MoonWalker asked for

There is a news item you get alerted to when you do an emerge --sync.

BitJam wrote:
proclaiming a naming convention that has been working on millions of systems for many years is broken

It *is* broken, and it hasn't worked. Do you think the udev devs created this new scheme because they like messing with users? No, they did it because they were getting tons of bug reports the likes of "I'm getting devices named rename_eth2" and such. I myself encountered this once. The renaming feature was incredibly racy and fragile. That's why it had to go. You can still rename your devices with simple names instead of the new udev ones, they just can't be in the kernel namespace. So instead of eth0 and eth1, you need to have net0 and net1 for example. Or you disable any renaming entirely, but then the first ethernet driver that loads at boot will get eth0, and there's no guarantee it'll be the same driver every boot.

BitJam wrote:
We could really use your help here.

You are getting help. The news item, for one. And ssuominen is here at the forums, trying to educate people despite the flak he's receiving. He could've just thought to himself "screw everyone" and not even read the forums.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21489

PostPosted: Wed Mar 20, 2013 2:14 am    Post subject: Reply with quote

Gusar wrote:
It *is* broken, and it hasn't worked. Do you think the udev devs created this new scheme because they like messing with users?
Yes. Kernel auto-discovered names work well for many people, and changing the default in new versions such that it begins mangling names even on systems which do not require it is a terrible idea. If device naming races were such a big problem, there are better fixes. The first that comes to mind is that they could have submitted the "predictable names" code as a kernel feature that, when enabled, causes the devices to start with the predictable name from the beginning. Individuals who compile the kernel could then make an informed decision to enable the new feature if they needed it.
Gusar wrote:
No, they did it because they were getting tons of bug reports the likes of "I'm getting devices named rename_eth2" and such. I myself encountered this once. The renaming feature was incredibly racy and fragile. That's why it had to go. You can still rename your devices with simple names instead of the new udev ones, they just can't be in the kernel namespace. So instead of eth0 and eth1, you need to have net0 and net1 for example. Or you disable any renaming entirely, but then the first ethernet driver that loads at boot will get eth0, and there's no guarantee it'll be the same driver every boot.
Your defense here perfectly highlights how confused the situation has become. The udev maintainers caused two sets of problems concurrently. While the loss of support for renaming interfaces into the standard names is unfortunate, that is far less serious than the obsession with renaming every device unless the user goes out of his way to force udev to let the system be. Yet, by introducing both sets of breaks at around the same time, we end up with numerous threads where users complain "udev broke my device names" because it engaged in unnecessary renaming. Responders answer with the same defense you offered, which although true and well stated, is not relevant to the complaint of the user whose system was broken. As I read BitJam's post, he is criticizing the unnecessary renaming behavior, not the restriction on what names you can assign.
Back to top
View user's profile Send private message
MoonWalker
Guru
Guru


Joined: 04 Jul 2002
Posts: 510

PostPosted: Wed Mar 20, 2013 10:00 am    Post subject: Reply with quote

Gusar wrote:
BitJam wrote:
I'd be much more satisfied if you had posted the migration how-to that MoonWalker asked for

There is a news item you get alerted to when you do an emerge --sync.


While that is better than nothing it's a long way from being an "How-to", and very much an example of something created by a developer for a developer, like the bug referred to is just plain confusing, even if you give it some time and thought it is possible to "figure it out" by picking pieces here and there but it's a pretty good chance you lost it before getting there. Then finally going ahead it doesn't directly infuse confidence in what you are doing when portage make this suggestion:
Code:
[ebuild     U  ] sys-fs/udev-198-r2 [171-r10] USE="acl%* kmod%* openrc%* -doc% -static-libs%"
[ebuild  N     ] virtual/udev-197-r1  USE="kmod -gudev -hwdb -introspection -keymap (-selinux) -static-libs"


Do I really need both of these?

I don't want to be negative and just criticise but I think that could have been done much better and the first step to correct that is to admit it instead of defend the change with "tech-talk". I also understand that there probably isn't a "one fits all" solution but if the (gentoo) people behind this had made the effort to set up at least the basics for a migration/how-to guide it could probably be improved over time by user feedback and most likely saved both them and others a lot of time and frustration.
_________________
/Joakim

Living on earth is expensive, but it includes a free trip around the sun
every year.
Back to top
View user's profile Send private message
Gusar
Advocate
Advocate


Joined: 09 Apr 2005
Posts: 2665
Location: Slovenia

PostPosted: Wed Mar 20, 2013 10:36 am    Post subject: Reply with quote

Hu wrote:
unless the user goes out of his way to force udev to let the system be

Configuring one's system is "going out of one's way" now?

Hu wrote:
we end up with numerous threads where users complain "udev broke my device names" because it engaged in unnecessary renaming.

Only because these people did not read the news item. Udev did not break machines, users themselves did. Changes happen. All distro maintainers can do is alert people to them, the rest is up to the user. But, like I wrote already in another thread, every change upsets gentoo users nowadays.

MoonWalker wrote:
Do I really need both of these?

Yes, you do. If you look closely, the second one is a virtual. You already have plenty of those installed. Virtuals are used when there's more than one package providing the same functionality.

What happened to Gentoo being bleeding edge, comprising of highly competent users, adopting new technologies before other distros did? When did explaining new tech become "defense"?
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 Mar 20, 2013 1:08 pm    Post subject: Reply with quote

Gusar wrote:
When did explaining new tech become "defense"?


Quote:
You are getting help. The news item, for one. And ____ is here at the forums, trying to educate people despite the flak he's receiving. He could've just thought to himself "screw everyone" and not even read the forums.

This is being defensive, it explains nothing.


Quote:
What happened to Gentoo being bleeding edge, comprising of highly competent users, adopting new technologies before other distros did?


What happened to users answering others legitimate questions instead of playing defense?
_________________
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 Mar 20, 2013 1:10 pm    Post subject: Reply with quote

Anon-E-moose wrote:
What happened to users answering others legitimate questions instead of playing defense?


Sounds good. What was the question(s) again?
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 Mar 20, 2013 1:23 pm    Post subject: Reply with quote

ssuominen wrote:
Anon-E-moose wrote:
What happened to users answering others legitimate questions instead of playing defense?


Sounds good. What was the question(s) again?


Why not leave udev-171* in portage until it well and truly breaks something or no longer works?

Right now it's masked, with removal due in 3 months or so.
It is the last viable gentoo ebuild prior to the udev/systemd merge, AFAIK.
Not everyone is in the systemd camp or runs it or plans on running it.
And yes one can copy it to local, as I have done, but the question isn't can I make a local copy.

Edit to add: I understand that it's probably not being actively maintained, but that doesn't mean it's broke.
_________________
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 Mar 20, 2013 1:32 pm    Post subject: Reply with quote

Anon-E-moose wrote:
ssuominen wrote:
Anon-E-moose wrote:
What happened to users answering others legitimate questions instead of playing defense?


Sounds good. What was the question(s) again?


Why not leave udev-171* in portage until it well and truly breaks something or no longer works?

Right now it's masked, with removal due in 3 months or so.
It is the last viable gentoo ebuild prior to the udev/systemd merge, AFAIK.
Not everyone is in the systemd camp or runs it or plans on running it.
And yes one can copy it to local, as I have done, but the question isn't can I make a local copy.

Edit to add: I understand that it's probably not being actively maintained, but that doesn't mean it's broke.


udev-171 is no longer adequate for libosinfo, hwids, udisks, upower, kdelibs, and more
udev-171 is not compatible with 3.x series of kernels, broken path-by-id symlinks or broken rule_generator (like /dev/cdrom)
if you search gentoo's bugzilla you will find some 20-30 bugs we closed as "fixed in 197"
udev-197 or 198 is a full replacement for 171, you don't lose any functionality
systemd has nothing to do with this, I certainly don't use systemd despite packaging udev out from it's tarball, and I'm happy building it out from there

3 months is already a extended time over the default 30 days

so why do you want to keep 171 around again? certainly nothing in portage requires it, and if something you have in your overlay does, well, that's where the old udev belongs then too
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 Mar 20, 2013 1:57 pm    Post subject: Reply with quote

ssuominen wrote:
Anon-E-moose wrote:

Why not leave udev-171* in portage until it well and truly breaks something or no longer works?

Right now it's masked, with removal due in 3 months or so.
It is the last viable gentoo ebuild prior to the udev/systemd merge, AFAIK.
Not everyone is in the systemd camp or runs it or plans on running it.
And yes one can copy it to local, as I have done, but the question isn't can I make a local copy.

Edit to add: I understand that it's probably not being actively maintained, but that doesn't mean it's broke.


udev-171 is no longer adequate for libosinfo, hwids, udisks, upower, kdelibs, and more
udev-171 is not compatible with 3.x series of kernels, broken path-by-id symlinks or broken rule_generator (like /dev/cdrom)
if you search gentoo's bugzilla you will find some 20-30 bugs we closed as "fixed in 197"
udev-197 or 198 is a full replacement for 171, you don't lose any functionality
systemd has nothing to do with this, I certainly don't use systemd despite packaging udev out from it's tarball, and I'm happy building it out from there

3 months is already a extended time over the default 30 days

so why do you want to keep 171 around again? certainly nothing in portage requires it, and if something you have in your overlay does, well, that's where the old udev belongs then too


I have masked hwids above a certain one simply because it put a dependency on virtual/udev-197*
I haven't taken that dependency out to see if it no longer works with the old udev.

Indeed I don't use udisks, upower, gnome/kde stuff, so I can't speak for those who do use those things and whether they work or not.

I'm happily running udev 171 with the the 3.8.1 kernel, and haven't noticed any problems with cdrom or other broken symlinks.
I think I would notice that on my system as several devices are plugged/unplugged from the esata port regularly.

I understand that udev >197* keeps things similar functionality wise,
but obviously not the same or there wouldn't be these constant threads started about breakage.

As far as systemd, it's already being discussed to disable udev being built as a separate package and instead only as part of systemd.
If that happens what will the alternatives be?
I'm not just looking at right now, but 6 months or a year from now,
I still remember the fiasco that we call "hal" and would just as soon not do the texas two step over something similar.

Anyway, you will do as you want to do. Thanks for your time and civil answers.
_________________
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
Anon-E-moose
Watchman
Watchman


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

PostPosted: Wed Mar 20, 2013 2:11 pm    Post subject: Reply with quote

Just an FYI

I do have copies of all ebuilds going back a couple of years
if anyone has need of an old one that has since been removed from the portage tree.

I sync daily then just back them up to a backup disk.
_________________
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
Gusar
Advocate
Advocate


Joined: 09 Apr 2005
Posts: 2665
Location: Slovenia

PostPosted: Wed Mar 20, 2013 2:45 pm    Post subject: Reply with quote

Anon-E-moose wrote:
This is being defensive, it explains nothing.

It explains there is a news item the user should read. That should be enough. We're supposed to be competent people here, who do not need hand-holding.
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 Mar 20, 2013 3:06 pm    Post subject: Reply with quote

Anon-E-moose wrote:
ssuominen wrote:
Anon-E-moose wrote:

Why not leave udev-171* in portage until it well and truly breaks something or no longer works?

Right now it's masked, with removal due in 3 months or so.
It is the last viable gentoo ebuild prior to the udev/systemd merge, AFAIK.
Not everyone is in the systemd camp or runs it or plans on running it.
And yes one can copy it to local, as I have done, but the question isn't can I make a local copy.

Edit to add: I understand that it's probably not being actively maintained, but that doesn't mean it's broke.


udev-171 is no longer adequate for libosinfo, hwids, udisks, upower, kdelibs, and more
udev-171 is not compatible with 3.x series of kernels, broken path-by-id symlinks or broken rule_generator (like /dev/cdrom)
if you search gentoo's bugzilla you will find some 20-30 bugs we closed as "fixed in 197"
udev-197 or 198 is a full replacement for 171, you don't lose any functionality
systemd has nothing to do with this, I certainly don't use systemd despite packaging udev out from it's tarball, and I'm happy building it out from there

3 months is already a extended time over the default 30 days

so why do you want to keep 171 around again? certainly nothing in portage requires it, and if something you have in your overlay does, well, that's where the old udev belongs then too


I have masked hwids above a certain one simply because it put a dependency on virtual/udev-197*
I haven't taken that dependency out to see if it no longer works with the old udev.

Indeed I don't use udisks, upower, gnome/kde stuff, so I can't speak for those who do use those things and whether they work or not.

I'm happily running udev 171 with the the 3.8.1 kernel, and haven't noticed any problems with cdrom or other broken symlinks.
I think I would notice that on my system as several devices are plugged/unplugged from the esata port regularly.

I understand that udev >197* keeps things similar functionality wise,
but obviously not the same or there wouldn't be these constant threads started about breakage.

As far as systemd, it's already being discussed to disable udev being built as a separate package and instead only as part of systemd.
If that happens what will the alternatives be?
I'm not just looking at right now, but 6 months or a year from now,
I still remember the fiasco that we call "hal" and would just as soon not do the texas two step over something similar.

Anyway, you will do as you want to do. Thanks for your time and civil answers.


I realize HAL wasn't perfect but it did what it advertized to do and luckily nothing too production important never dependent on it without the possibility of disabling it. This was of course worse
for binary-only distributions where their packages was only built one way, the HAL way.
Then I remember Gentoo migrating from HAL to udev/gudev/UDisks1/UPower which went smoothly, every package that dependent on HAL was either fixed itself, or better alternative
was imported to Portage.
Now we are in transition from UDisks1 to UDisks2 which will require >=virtual/udev-197[hwdb] (builtin hwdb stuff from hwids/udev).
Have encountered no hard problems so far with it, usual API migration and packaging issues like with HAL to UPower/UDisks1/gudev/udev.
Both UDisks1 and UDisks2 in Portage are parallel installable, like with HAL, and can even be ran together without conflict.
Those apps that support UDisks2 use it, others will fallback to UDisks1, like it was with HAL.
It just always seemed to me like people were making it a bigger problem than it really was (from users point of view)

If systemd is made mandatory in udev, that's something we will have to think about then, at any rate, this isn't the correct time for forking it yet. Patches should still go to upstream and
those rejected can be maintained in a small patchset, currently we carry only one, temporarily restoring support for older kernels.

Surely 171 still works for some setups, but those setups have no reason not to upgrade to >=197 either. Like 171 was considered longterm in it's time, will 199 be the next longterm, using 197-r8 as stepping stone. I mean, how conservative Gentoo should be, isn't waiting from 171 to 197 enough jump as is?
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 Mar 20, 2013 3:19 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Just an FYI

I do have copies of all ebuilds going back a couple of years
if anyone has need of an old one that has since been removed from the portage tree.

I sync daily then just back them up to a backup disk.


http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-fs/udev/?hideattic=0

Heh, look at how simple udev once was:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-fs/udev/udev-0.2.ebuild?hideattic=0&revision=1.1&view=markup

:-)
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 Mar 20, 2013 3:44 pm    Post subject: Reply with quote

I used to pull old ebuilds from hideattic when I would need them, then one day it disappeared (quite a while back)
since then I just keep a local copy tarred and zipped. I was offering it to those who might not be able to
find what they were looking for in hideattic. NBD.

My point was never to say that people shouldn't upgrade and for those who need to/are forced to by other packages
then by all means do so. I just see no harm in leaving the last 171 package around (with a possible warning/disclaimer)
that it might or might not work at some future time.

As far as being conservative, there are many things that I do keep up to date on, so I understand the latest/greatest
but there are some things that are working fine just the way they are and I leave them until I have some pressing need
to change (a package I can't live without, etc).

Anyway, I've probably said more than I should, and I'll leave the whole udev mess alone and watch from the sidelines.

Thanks again for your replies.
_________________
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
araxon
Tux's lil' helper
Tux's lil' helper


Joined: 25 May 2011
Posts: 83

PostPosted: Wed Mar 20, 2013 7:09 pm    Post subject: Reply with quote

I would like to add myself to the list of people happily using udev-171. I did mask hwids forcing me to upgrade it, and I plan to mask any other package requiring the upgrade in the future. I simply cannot afford my servers around the globe to "randomly" rename their network interfaces. I don't see why the udev-171 has to be removed completely from the portage. It certainly has some userbase, that uses it despite it's age and various bugs. Those "bugs" works great for me and I don't want them to be removed in my current installs - some of them lives more than 6 years without reinstall, and I don't need any new hardware to be plugged into them, ever. If they die, I will replace them with new servers, where I will happily have current udev. It is the fact that it breaks my old boxes, that bothers me about >171.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21489

PostPosted: Thu Mar 21, 2013 2:02 am    Post subject: Reply with quote

Gusar wrote:
Hu wrote:
unless the user goes out of his way to force udev to let the system be

Configuring one's system is "going out of one's way" now?
When the old version works as the user wants, the new version introduces unwanted behavior as a default, and a standard configuration file check before reboot does not catch it, yes. I would be less touchy about this if I was not among the users who have a headless server that will require special care to update. If the network does not come back up, fixing it will be unpleasant. If the network interfaces get renamed when it comes up, that will be just as bad as the network not coming up at all.

Gusar wrote:
Hu wrote:
we end up with numerous threads where users complain "udev broke my device names" because it engaged in unnecessary renaming.

Only because these people did not read the news item. Udev did not break machines, users themselves did. Changes happen. All distro maintainers can do is alert people to them, the rest is up to the user. But, like I wrote already in another thread, every change upsets gentoo users nowadays.
Only the changes that break the system needlessly upset me. I assume the news item you refer to is Upgrading udev from 171 (or older) to 197, which mentions predictable names only insofar as that it touts the new scheme as a replacement for the previously supported racy renames. If you count in the text near the end that users need to "read every message printed by the emerge of udev" as incorporating the warning by reference, then yes, you could argue that the news item warns you your devices will take on unexpected names.

Without intending to bring ssuiminen into an argument:
ssuominen wrote:
udev-171 is no longer adequate for libosinfo, hwids, udisks, upower, kdelibs, and more
udev-171 is not compatible with 3.x series of kernels, broken path-by-id symlinks or broken rule_generator (like /dev/cdrom)
This is news to me. I noticed that sys-apps/hwids gained a DEPEND on newer sys-fs/udev, but I had not noticed any problems with any of /dev/disk/by-id/, /dev/disk/by-label/, /dev/disk/by-path/, /dev/disk/by-uuid/ when using a 3.8.x kernel with ~sys-fs/udev-171.
ssuominen wrote:
if you search gentoo's bugzilla you will find some 20-30 bugs we closed as "fixed in 197"
I tried this search in hopes of providing citations to support you, but there are so many bugs filed about udev that starting at the end and working backward I gave up around bug #444100 without spotting any that seem pertinent. My query was: title contains udev and bug created within the last year.
Back to top
View user's profile Send private message
araxon
Tux's lil' helper
Tux's lil' helper


Joined: 25 May 2011
Posts: 83

PostPosted: Thu Mar 21, 2013 11:42 am    Post subject: Reply with quote

I did a quick research about Debian, and it seems that they live their happy lives with kernel-3.x, without udev-197. The most recent udev used in Debian is like 177 or something. If a super-stable distribution like Debian allows such combination, then it cannot be as bug-ridden, as it would appear. Or even if it is totally buggy, they still decided, that it is way better than version 197. Just saying...
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Thu Mar 21, 2013 12:11 pm    Post subject: Reply with quote

araxon wrote:
I did a quick research about Debian, and it seems that they live their happy lives with kernel-3.x, without udev-197. The most recent udev used in Debian is like 177 or something. If a super-stable distribution like Debian allows such combination, then it cannot be as bug-ridden, as it would appear. Or even if it is totally buggy, they still decided, that it is way better than version 197. Just saying...


You are making false assumptions that Debian has a working udev, and they don't have one available in the repositories currently. Since they use 175, it might work slightly better what
our 171 did, but still:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=udev
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655924 (this is one of the problems I mentioned earlier in this thread about broken rule_generator)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687378 (and the second problem I mentioned earlier, the broken path-by links)

They simply haven't packaged new udev yet. Surely the migration to the systemd source tree has caused part of the delays, and surely they can't be all happy about
building it out from systemd tree either, but what I heard last was that they are going to package it just like we do, and they are going even futher with it, like packaging
systemd-logind out from systemd's tarball to replace ConsoleKit but still use it on non-systemd systems. Futher their release model with freezes causes more
delays.

Like for example, http://mail.gnome.org/archives/desktop-devel-list/2013-March/msg00092.html

Quote:

* At least Debian and Ubuntu will soon use logind without necessarily
the systemd init parts, as they support other init systems [1]. For
those, /sys/fs/cgroup/systemd/ exists as logind uses these cgroups
as well. So for the majority of cases that we have today,
sd_booted() actually happens to work and succeeds if logind is
available, but not systemd init.


It's a fact we have better working udev in stable in terms of compability with current kernels than Debian.
Back to top
View user's profile Send private message
MoonWalker
Guru
Guru


Joined: 04 Jul 2002
Posts: 510

PostPosted: Thu Mar 21, 2013 2:52 pm    Post subject: Reply with quote

Gusar wrote:


MoonWalker wrote:
Do I really need both of these?

Yes, you do. If you look closely, the second one is a virtual. You already have plenty of those installed. Virtuals are used when there's more than one package providing the same functionality.


You are right, thanks, I didn't pay attention there ;-)

Gusar wrote:

What happened to Gentoo being bleeding edge, comprising of highly competent users, adopting new technologies before other distros did? When did explaining new tech become "defense"?


I didn't really mean it in that way, on the contrary, I love to have the new tech explained but it also needs a practical implementation that can be understood also by folks that don't spend all days with Gentoo or in this fora. I will leave it by that though as I'm not interested in word fencing but to safely get my server up to date.
_________________
/Joakim

Living on earth is expensive, but it includes a free trip around the sun
every year.
Back to top
View user's profile Send private message
Punchcutter
Guru
Guru


Joined: 11 Feb 2007
Posts: 354

PostPosted: Sun Mar 24, 2013 6:54 pm    Post subject: Reply with quote

MoonWalker wrote:
Gusar wrote:

What happened to Gentoo being bleeding edge, comprising of highly competent users, adopting new technologies before other distros did? When did explaining new tech become "defense"?


I didn't really mean it in that way, on the contrary, I love to have the new tech explained but it also needs a practical implementation that can be understood also by folks that don't spend all days with Gentoo or in this fora. I will leave it by that though as I'm not interested in word fencing but to safely get my server up to date.

I would like to back this up. Gusar's attitude is one that is traditional in the Linux world - "If you're not as deep into your system as we are, we treat you with (some level of) contempt." Sure, there was the news item, but it is too short and insufficient (at least the part about predictable i/f naming) for even the likes of many of us techies (and I can't resist a little dig - I seem to recall when I first read it, it included an apology about `sorry if this came too late for some of you', which seems to have been expunged now?).

Like Moonwalker and I'm sure many others, I am technically competent and capable of learning the new stuff and adapting, however I have a real job and life that does not revolve around my Gentoo, as much as I do enjoy the latter. I can make time to read a migration guide and follow instructions, and learn what's happening, but I don't have time to follow the full history of a software component like udev, including all the political intrigue that swirls around it, so that I know all the issues of it deeply and can make an informed decision of my own. IOW, I don't live and breathe this stuff. I only have desktop systems, with single (at a time) network connections, and I just want to keep these working. If a migration guide that doesn't cover all possible configurations, but only the simplest, can be provided, then this is still extremely useful to many of us.

For better or worse, Gentoo is a mainstream distro used by lots of people who are not kernel developers, and if it's going to remain successful at that scale, it needs to take care of us beta-geeks who use it. Not hand-holding, as such, just a big enough toe-hold to get us through. Thanks.
Back to top
View user's profile Send private message
MoonWalker
Guru
Guru


Joined: 04 Jul 2002
Posts: 510

PostPosted: Thu Mar 28, 2013 5:19 pm    Post subject: Reply with quote

@Punchcutter: Well said!

As I read through that news item with its references it crossed my mind - What's wrong with plain English! So I decided to give this a try, before lagging behind too far which is never a good idea with Gentoo. However, instead of jeopardize my live server I transferred an image of the disc to some equivalent local hardware, and here is my experience, plain and simple. Note, this is for a relatively simple box with just 1 nic card and uses the new predictable net name stuff. Also, I use an openvz-sources kernel and the box has several virtual net interfaces. I can say already now though that it doesn't appear to make any difference to udev for the host node, except that it says:
Code:
ERROR: setup
   CONFIG_SYSFS_DEPRECATED:                 should not be set. But is.
   CONFIG_SYSFS_DEPRECATED_V2:            should not be set. But is.

However, that was expected as it's 'hardcoded' in openvz-sources (for reason I haven't been able to get an answer to) but all seem to work well anyhow as long as minimal kernel version is met.

So this is what I then did, removed udev-postmount
Code:
# rc-update del udev-postmount default


Checked CONFIG_DEVTMPFS
Code:
# grep 'CONFIG_DEVTMPFS' /usr/src/linux/.config
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y


Checked for /dev
Code:
# grep '/dev' /etc/fstab
/dev/sda1               /boot           ext3            noauto,noatime          1 1
/dev/sda3               /               ext3            noatime                 1 2
/dev/sda2               none            swap            sw                      0 0
/dev/sda5               /vz             ext3    noatime                 1 2
/dev/sda6               /tmp            ext2    noatime                 1 2
/dev/sr0        /mnt/cdrom      iso9660         noauto,ro               0 0
# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
none                    /dev/shm        tmpfs           defaults                0 0


All OK as here only a bare /dev item counts, not /dev/shm

Next that scary net stuff, the "link of life" or not. At this point I decided to do the
Code:
# emerge -uDaNv system

to see what actually would happen.

udev-init-scripts complained:
ln: failed to create symbolic link '//etc/runlevels/sysinit/udev':File exists
ln: failed to create symbolic link '//etc/runlevels/sysinit/udev-mount':File exists

Although I don't think that's anything to worry about.

Then to the Predictable-Network-Interface-Names, it sounds logical and if it work to hell with old eth0

I wasn't sure about this but ran the udevadm command
Code:
# udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null

and got a name of 'enp1s5' and then did the following:

Code:
1. in /etc/conf.d/net replace all instances of "eth0" with "enp1s5"
2. replaced all instances of "eth0" with "enp1s5" in my /etc/shorewall/{configuration files}
3. remove old net init and add new
3a. # cd /etc/init.d
3b. # rm net.eth0
3c. # ln -s net.lo net.enp1s5
4.  Do the rc-update stuff
4a. rc-update del net.eth0 default
4b. rc-update add net.enp1s5
5.  Remove old rule files (or move them elsewhere until sure)
5a. #rm /etc/udev/rules.d/70-persistent-*.rules
6. reboot


And guess what - it worked! Also from inside virtual containers net is available both in and out to the outside world. I haven't tested this on my live (remote) server yet though as I have to plan so I can access it in (office) time in case the net link for some reasons doesn't come up. Still also need to test and figure how to do this inside of the virtual containers, where I fear it won't be so strait forward.

I also tried using another name than 'enp1s5' that udevadm gave me, but that didn't seem to work although I got the impressions from what I read it should have.

Feedback welcomed and glad to hear if the above possibly will help somebody.

EDIT: Reboot of remote live server went fine as well. Also realized that if you want to use another name than what 'udevadm' returns you have to use the '70-persistent-net.rules' file, it just cannot be eth0, eth1 etc. enp1s5 isn't so sexy maybe but heck it works and will never change.
_________________
/Joakim

Living on earth is expensive, but it includes a free trip around the sun
every year.


Last edited by MoonWalker on Fri Mar 29, 2013 12:39 pm; edited 1 time in total
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Fri Mar 29, 2013 9:47 am    Post subject: Reply with quote

Quote:
enp1s5


udev (19x*) gets this interface name from where again? I remember
seeing it in the "predictable network interface names" document,
but I do not see what it maps to.

If users are going to replace "eth0" with "net0", then wifi
devices should become "wifi0", so it is clear at a glance
which kind of network interface a device name refers to.
Or is this a copyrighted name, "wifi"? Maybe "wnet0"
would avoid future problems.

(Using udev-171-r10 and studying the mknod manpage(s).
I have no idea how reliable MAKEDEV is these days.
It seems to have a lot of possibly obsolete script dreck
with it that makes perhaps unwarranted assumptions
about how a user wants the /dev directory set up.)
_________________
TIA
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
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