| View previous topic :: View next topic |
| Author |
Message |
Gatsby
Tux's lil' helper
Joined: 18 Jan 2010
Posts: 116
Location: 127.0.0.1
|
 Posted: Tue Feb 25, 2014 7:49 pm Post subject: udev is doomed |
 |
|
Today I read this after typing eselect news read:
| Quote: |
2014-02-25-udev-upgrade
Title Upgrade to >=sys-fs/udev-210
Author Samuli Suominen <ssuominen@gentoo.org>
Posted 2014-02-25
Revision 1
The options CONFIG_FHANDLE and CONFIG_NET are now required in the kernel.
You will be warned of them if they are missing while you upgrade to
>=sys-fs/udev-210 by the package manager.
See the package's README at /usr/share/doc/udev-210/ for more optional
kernel options.
The most reliable way of disabling the new network interface scheme is still
the kernel parameter "net.ifnames=0" since overriding the
80-net-name-slot.rules in /etc/udev/rules.d/ no longer works since upstream
renamed the file to /lib/udev/rules.d/80-net-setup-link.rules
The actual configuration is at /lib/systemd/network/99-default.link, which
you can override in /etc/systemd/network/
So, to clarify, you can override the new .rules file or the .link file in /etc
but using the kernel parameter is the most consistent way.
Since both the systemd-udevd executable and the network configuration is stored
at /lib/systemd, using a too wide INSTALL_MASK would be a mistake. |
As I don't want systemd and it's garbage to pollute my Gentoo systems and therefore have set INSTALL_MASK="/usr/lib/systemd" some time ago, I decided today to mask >sys-fs/udev-208.
I am worried that udev is just the beginning and other issues of Poetterjunk will soon follow. 
Greetings,
Gatsby
_________________
Γνωθι σεαυτον. |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54216
Location: 56N 3W
|
| Posted: Tue Feb 25, 2014 10:18 pm Post subject: |
|
|
Gatsby,
Meanwhile there is eudev which is a udev fork.
There is mdev too.
If you are old and cynical (like me) a static /dev 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 |
|
|
kurly
Apprentice
Joined: 02 Apr 2012
Posts: 260
|
| Posted: Wed Feb 26, 2014 2:26 am Post subject: |
|
|
| I do hope that eudev will resist this unnecessary change. It seems almost as if it was done solely to annoy people who have actively chosen to avoid systemd. I already have sys-fs/udev masked on my machines, but I will mask virtual/udev if it becomes necessary. The INSTALL_MASK will not be removed on my system, and any package that fails, I'd argue a bug should be filed. (Of course I strongly suspect that any such bugs will be closed WONTFIX or UPSTREAM, but I still think it's a bug.) |
|
| Back to top |
|
|
The Doctor
Moderator
Joined: 27 Jul 2010
Posts: 2678
|
| Posted: Wed Feb 26, 2014 2:59 am Post subject: |
|
|
| kurly wrote: | | It seems almost as if it was done solely to annoy people who have actively chosen to avoid systemd. |
I think it is fair to drop the 'seems to me.'
| Lennart Poettering wrote: | 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 source. It seems Red Hat is very casual about promising to maintain support for something (like stand alone udev) and then actively attempting to drop support for it very soon after. Honestly, I don't trust them anymore. As the saying goes, fool me once same on you. Fool me twice, shame on me.
Since I try very hard not to simply post dissing comments, I will suggest you investigate mdev if you want to break away from udev entirely. It works fine for all the hotpluging I use, minus a few permissions. Lets face it. That is what scripts are for.
_________________
First things first, but not necessarily in that order.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Wed Feb 26, 2014 5:34 am Post subject: Re: udev is doomed |
|
|
| Gatsby wrote: | | INSTALL_MASK="/usr/lib/systemd" |
That's fine, since udev doesn't install to /usr |
|
| Back to top |
|
|
Aiken
Apprentice
Joined: 22 Jan 2003
Posts: 239
Location: Toowoomba/Australia
|
| Posted: Wed Feb 26, 2014 6:17 am Post subject: |
|
|
| The Doctor wrote: |
With source. It seems Red Hat is very casual about promising to maintain support for something (like stand alone udev) and then actively attempting to drop support for it very soon after. Honestly, I don't trust them anymore. As the saying goes, fool me once same on you. Fool me twice, shame on me. |
This is starting to get tempting. Reading the news had me thinking of how the udev 204 upgrade was handled. With 204 it would not work unless certain kernel options were selected but would install anyway. I won't say anything kinder than that was stupid. Udev should have refused to install. Reading the latest news left me thinking 'oh not again, more unbootable computers for people'.
I have a static /dev handy in case something goes wrong. Even with a static /dev which contains everything the computer needs to boot, if udev has trouble starting it will abort the boot process. Say what? In this scenario should not have to go to the effort of boot with init=/bin/bash, remove the udev init script then reboot just to get a running computer. That has never left me thinking much of udev. At least for me udev's unpredicatble network names are more trouble than they are worth. Reading the post you linked to adds to the why stay with udev?
_________________
Beware the grue. |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Wed Feb 26, 2014 6:38 am Post subject: |
|
|
| Aiken wrote: | | This is starting to get tempting. Reading the news had me thinking of how the udev 204 upgrade was handled. With 204 it would not work unless certain kernel options were selected but would install anyway. I won't say anything kinder than that was stupid. Udev should have refused to install. Reading the latest news left me thinking 'oh not again, more unbootable computers for people'. |
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. |
|
| Back to top |
|
|
Aiken
Apprentice
Joined: 22 Jan 2003
Posts: 239
Location: Toowoomba/Australia
|
| Posted: Wed Feb 26, 2014 6:58 am Post subject: |
|
|
| ssuominen wrote: |
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. |
It is not hard to read the news then forget about it. When doing a large update with the amount of text that scrolls past it is easy to miss a particular item. I got caught by that udev update a couple of months later so had completely forgotten about it and any text related to udev had long scrolled off the screen.
I think it would be better playing it on the safe side then hosing a running system. Don't see why it would kill off the concept of the idea of a build machine. Have a way to differentiate between a build system and a normal live system. On the build machine build the update regardless. On the live system refuse the update until appropriate.
I have 2 build machines, some that are binary only, some that are binary but will build locally if no install candidate and some that are source only. Would be very happy with something to specify build machine and let it build all updates and have the non build machines refuse updates that will kill them.
edit: Due to a lack of trust regards udev have followed what others have done and masked > 208
_________________
Beware the grue. |
|
| Back to top |
|
|
AgBr
Apprentice
Joined: 06 Nov 2010
Posts: 195
|
| Posted: Wed Feb 26, 2014 8:08 am Post subject: |
|
|
Glad I have seens this thread in time. It would render about 140 machines unusable. These machines get binary updates from a build-server. I would have most likely overseen the warning. I have just masked >sys-fs/udev-208 until I fully understand how to take action on this.
I have read the quoted warning several times but I still do not get it. What will I have to do exactly to keep the old net interface naming scheme? |
|
| Back to top |
|
|
Gatsby
Tux's lil' helper
Joined: 18 Jan 2010
Posts: 116
Location: 127.0.0.1
|
| Posted: Wed Feb 26, 2014 8:47 am Post subject: |
|
|
Hi Neddy, 
| NeddySeagoon wrote: | Gatsby,
Meanwhile there is eudev which is a udev fork.
There is mdev too.
If you are old and cynical (like me) a static /dev still works. |
Thank you for your kind reply. I'm looking forward to try out mdev but most probably I'll end up with
switching to a static /dev since I don't need such gimmicks like automounting media et al..
Have a nice day.
Greetings,
Gatsby
_________________
Γνωθι σεαυτον. |
|
| Back to top |
|
|
Gatsby
Tux's lil' helper
Joined: 18 Jan 2010
Posts: 116
Location: 127.0.0.1
|
| Posted: Wed Feb 26, 2014 9:07 am Post subject: Re: udev is doomed |
|
|
| ssuominen wrote: | | Gatsby wrote: | | INSTALL_MASK="/usr/lib/systemd" |
That's fine, since udev doesn't install to /usr |
What a cynical comment. Honestly, I did not expect an other kind of reply from your side. 
O.k. /usr/lib/systemd moved to /lib/systemd. So I'll add that to my INSTALL_MASK.
It makes me sad to see how willingly Gentoo devs like you jump on the RedHat/Poettering train.
I have been a content Gentoo GNU/Linux user since 2006, but if I have to keep the freedom of choice,
that Gentoo once offered, I will drop it completely and roll my own using LFS or some kind of BSD,
just like Anon-E-moose proposed at several times.
Gatsby
_________________
Γνωθι σεαυτον. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Wed Feb 26, 2014 9:13 am Post subject: |
|
|
| The Doctor wrote: | | It seems Red Hat is very casual about promising to maintain support for something (like stand alone udev) and then actively attempting to drop support for it very soon after. |
It all depends on which friday of the week it is ...
| Lennart Poettering wrote: | | We don't support udev in an separate tarball anymore. We do support udev built from the systemd tree used independently of systemd. We need that for our own initrds, so we will support that for a long time. |
... and subsequently on Google+ ...
| Lennart Poettering wrote: | | Because [Canonical] have not adopted systemd they will have to continue to develop and support infrastructure (such as ConsoleKit, independent udev) that is officially orphaned by its developers and maintainers. They are stuck with a half-obsolete stack that receives no new development |
| The Doctor wrote: | | [...] I will suggest you investigate mdev if you want to break away from udev entirely. It works fine for all the hotpluging I use, minus a few permissions. Lets face it. That is what scripts are for. |
I've been using mdev in conjuction with slashbeast's mdev-like-a-boss for some time and have no issues what-so-ever. However, I'm now in a situation where I expect it to break given the following:
| Fabio Erculiani <lxnay [at] gentoo> wrote: | | If future lvm versions are going to use udev more extensively (for eg: storing more critical metadata in it), the net result will be that mdev won't work anymore. This is why I wrote that lvm is working "by miracle for now". mdev is not future proof wrt lvm support. |
best ... khay |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6097
Location: Dallas area
|
| Posted: Wed Feb 26, 2014 10:24 am Post subject: |
|
|
Gee, why am I not terribly surprised. 
Since lvm is yet another RH "product" I can't say that I'm surprised with it being tightly tied to the other stuff.
I expect in the near future it won't be usable without systemd being installed.
I don't use lvm and I'm still using udev 171-r6 and it works well enough.
I have had to mask, I don't remember, but not more than 3-4 packages because of it.
I do know that sometimes I look at the source directly and there is no need for the dependencies
that some of the gentoo devs like to attach to the ebuilds.
Source for LVM2.2.02.103 compiles just fine even with udev 171 (it looks for >143).
So I can only assume the ebuild needing above 200 (actually 208 since that's
the lowest version) is for political reasons to keep people on the upgrade path,
with the ultimate goal of moving everyone to systemd.
I suppose it could be incompetence, on the devs part, instead though.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Wed Feb 26, 2014 3:38 pm Post subject: |
|
|
| 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
Last edited by SamuliSuominen on Wed Feb 26, 2014 3:55 pm; edited 1 time in total |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Wed Feb 26, 2014 3:43 pm Post subject: |
|
|
| Anon-E-moose wrote: | Source for LVM2.2.02.103 compiles just fine even with udev 171 (it looks for >143).
So I can only assume the ebuild needing above 200 (actually 208 since that's
the lowest version) is for political reasons to keep people on the upgrade path,
with the ultimate goal of moving everyone to systemd.
I suppose it could be incompetence, on the devs part, instead though. |
Since >=sys-fs/udev-200 is a full replacement for ~sys-fs/udev-171, there isn't really any point to what you are suggesting. But honestly, the real reason for dropping in >=vritual/udev-200 dependency is the fact that
it's the lowest version of udev the developers have tested it against. Blindly relying on pkg-config version check numbers if upstream configure.ac's wouldn't be a distribution at all, that'd be LFS where nothing
is guaranteed to work together before you test it *yourself* with no developers in-between.
Last edited by SamuliSuominen on Wed Feb 26, 2014 3:54 pm; edited 1 time in total |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Wed Feb 26, 2014 3:47 pm Post subject: Re: udev is doomed |
|
|
| Gatsby wrote: | | ssuominen wrote: | | Gatsby wrote: | | INSTALL_MASK="/usr/lib/systemd" |
That's fine, since udev doesn't install to /usr |
What a cynical comment. Honestly, I did not expect an other kind of reply from your side.
O.k. /usr/lib/systemd moved to /lib/systemd. So I'll add that to my INSTALL_MASK.
|
Nothing cynical about it, merely pointing out that you can keep on INSTALL_MASK'ing the /usr/lib/systemd you yourself mentioned, not anyone else.
You can also INSTALL_MASK directories like /lib/systemd/system, for now, but there is no guarantee whatsoever it's a wise decision in the long
run.
But, seriously, using INSTALL_MASK is same as rm -f'ing files from your / blindly. It's not a very smart, or safe Portage variable to use at all. It's use has lately been promoted unnecessarily
much in the forums and MLs, where as it used to be a way to avoid problematic files, like, for *real* reasons. Cosmetics doesn't count.
And for sure, use of it is never supported, and you are always on your own -- just like with eg. using package.provided
Last edited by SamuliSuominen on Wed Feb 26, 2014 3:52 pm; edited 3 times in total |
|
| Back to top |
|
|
The Architect
n00b
Joined: 26 Feb 2014
Posts: 1
|
| Posted: Wed Feb 26, 2014 3:48 pm Post subject: |
|
|
| AgBr wrote: | Glad I have seens this thread in time. It would render about 140 machines unusable. These machines get binary updates from a build-server. I would have most likely overseen the warning. I have just masked >sys-fs/udev-208 until I fully understand how to take action on this.
I have read the quoted warning several times but I still do not get it. What will I have to do exactly to keep the old net interface naming scheme? |
Exactly this. I had to run through hoops last time, and the instructions made no sense as far as keeping the old scheme, and the link to the website entry was just as little help. |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Wed Feb 26, 2014 4:01 pm Post subject: |
|
|
| AgBr wrote: | Glad I have seens this thread in time. It would render about 140 machines unusable. These machines get binary updates from a build-server. I would have most likely overseen the warning. I have just masked >sys-fs/udev-208 until I fully understand how to take action on this.
I have read the quoted warning several times but I still do not get it. What will I have to do exactly to keep the old net interface naming scheme? |
If you had read it, you'd know there are 3 different ways of disabling the new scheme:
- like in prev. udev version, net.ifnames=0 continues to work as a kernel parameter
- like in prev. udev version, overriding a .rules file will work, you only need to notice the mentioned filename change
- and third option was introduced, overriding the .link file the post also refers to
Pick one? Or is something still not clear? Other than the kernel parameter, rest is normal use of udev, overriding a file from /lib in a matching directory at /etc will work for anything, you could do that even for eg. 60-keyboard.rules and configure your keyboard completely without udev.
The empty directories for overriding these files are also created by the ebuild, so there isn't much room for guessing. |
|
| Back to top |
|
|
AgBr
Apprentice
Joined: 06 Nov 2010
Posts: 195
|
| Posted: Wed Feb 26, 2014 4:30 pm Post subject: |
|
|
| ssuominen wrote: |
If you had read it, you'd know there are 3 different ways of disabling the new scheme:
- like in prev. udev version, net.ifnames=0 continues to work as a kernel parameter
- like in prev. udev version, overriding a .rules file will work, you only need to notice the mentioned filename change
- and third option was introduced, overriding the .link file the post also refers to
Pick one? Or is something still not clear? |
Thank you for clarifying it. For me it was not clear that the latter two are alternatives. One more question. Can I preserve the empty 80-net-name-slot.rules besides the 80-net-setup-link.rules? This would preserve me from getting clammy hands while updating as I could make sure the file is really in place prior to updating udev. Updating things that could possibly kick 140 boxes off the net is no fun for me. For the same reason I don't like the idea of messing around with grub.conf. |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Wed Feb 26, 2014 4:33 pm Post subject: |
|
|
| AgBr wrote: | | ssuominen wrote: |
If you had read it, you'd know there are 3 different ways of disabling the new scheme:
- like in prev. udev version, net.ifnames=0 continues to work as a kernel parameter
- like in prev. udev version, overriding a .rules file will work, you only need to notice the mentioned filename change
- and third option was introduced, overriding the .link file the post also refers to
Pick one? Or is something still not clear? |
Thank you for clarifying it. For me it was not clear that the latter two are alternatives. One more question. Can I preserve the empty 80-net-name-slot.rules besides the 80-net-setup-link.rules? This would preserve me from getting clammy hands while updating as I could make sure the file is really in place prior to updating udev. Updating things that could possibly kick 140 boxes off the net is no fun for me. For the same reason I don't like the idea of messing around with grub.conf. |
So, having empty 80-net-name-slot.rules there might be redudant, but it doesn't hurt anything if your intention is to disable the renaming anyway, so feel free to keep both files, old and new |
|
| Back to top |
|
|
elmar283
Guru
Joined: 06 Dec 2004
Posts: 316
Location: Haarlem, Netherlands
|
| Posted: Wed Feb 26, 2014 5:08 pm Post subject: |
|
|
Just to having it clear: I updated to sys-fs/udev-208 without having systemd installed and without the CONFIG_FHANDLE and CONFIG_NET kernel options. I'm still using openrc. I do already have the new network naming form earlier 20* versions.
Will there be a problem booting now? |
|
| Back to top |
|
|
AgBr
Apprentice
Joined: 06 Nov 2010
Posts: 195
|
| Posted: Wed Feb 26, 2014 5:13 pm Post subject: |
|
|
| elmar283 wrote: | | I updated to sys-fs/udev-208 without having systemd installed and without the CONFIG_FHANDLE and CONFIG_NET kernel options. |
Are you sure that these aren't set as default. I have checked with my kernel config already and they are set. I do not remember that I did it. |
|
| Back to top |
|
|
elmar283
Guru
Joined: 06 Dec 2004
Posts: 316
Location: Haarlem, Netherlands
|
| Posted: Wed Feb 26, 2014 5:16 pm Post subject: |
|
|
| Code: | elmarotter@ZaphodBeeblebrox ~ $ cat /usr/src/linux/.config |grep FHANDLE
# CONFIG_FHANDLE is not set |
| Code: |
elmarotter@ZaphodBeeblebrox ~ $ cat /usr/src/linux/.config |grep CONFIG_NET
CONFIG_NET_NS=y
# CONFIG_NET5501 is not set
CONFIG_NET=y
|
So CONFIG_NET is set, but NET_FHANDLE not.
EDIT: I'm not worried by the kernel config handling. I can change that, I'm worried about the systemd requirement.
I have openrc, if udev-208 needs systemd it should never have been able to merge. So I would like to know wheter or not my machine will still boot now? |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Wed Feb 26, 2014 5:37 pm Post subject: |
|
|
| elmar283 wrote: | Just to having it clear: I updated to sys-fs/udev-208 without having systemd installed and without the CONFIG_FHANDLE and CONFIG_NET kernel options. I'm still using openrc. I do already have the new network naming form earlier 20* versions.
Will there be a problem booting now? |
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 (for determining if /dev is mounted as devtmpfs or not, to determine if udev is being used or not, IIRC)
You really should rebuild your kernel to include these options. They are documented as hard dependencies in the README and have been verified to be used through reading udev's code. |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Wed Feb 26, 2014 5:43 pm Post subject: |
|
|
| ssuominen wrote: | | AgBr wrote: | | ssuominen wrote: |
If you had read it, you'd know there are 3 different ways of disabling the new scheme:
- like in prev. udev version, net.ifnames=0 continues to work as a kernel parameter
- like in prev. udev version, overriding a .rules file will work, you only need to notice the mentioned filename change
- and third option was introduced, overriding the .link file the post also refers to
Pick one? Or is something still not clear? |
Thank you for clarifying it. For me it was not clear that the latter two are alternatives. One more question. Can I preserve the empty 80-net-name-slot.rules besides the 80-net-setup-link.rules? This would preserve me from getting clammy hands while updating as I could make sure the file is really in place prior to updating udev. Updating things that could possibly kick 140 boxes off the net is no fun for me. For the same reason I don't like the idea of messing around with grub.conf. |
So, having empty 80-net-name-slot.rules there might be redudant, but it doesn't hurt anything if your intention is to disable the renaming anyway, so feel free to keep both files, old and new |
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.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog
Last edited by Fitzcarraldo on Wed Feb 26, 2014 5:44 pm; edited 1 time in total |
|
| Back to top |
|
|
|
|
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
|
|
Gentoo Chat
