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
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Sun Mar 02, 2014 12:41 pm    Post subject: Reply with quote

krinn wrote:
IUSE="buildhost" emerge udev
USE="-buildhost" emerge udev

A use-flag just to turn a warning into an error or vice versa? Looks like overkill to me - a warning should be sufficient.
Moreover, do no forget that you must set identical use-flags if you want to emerge a prebuilt binary package, so the name is more than misleading. BTW: If you do checks in pkg_preinst you can be sure that you are in the "final" system. Anyway, I strongly vote against fatal errors - no matter in which phase - because there may always be valid reasons why the users wants to install anyway.
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: Sun Mar 02, 2014 12:42 pm    Post subject: Reply with quote

NeddySeagoon wrote:
There is only so much Gentoo can do to protect users against themselves and none of the above is robust enough to be worth the effort.
Gentoo users need to know better.


I agree in that those who do things like build on one host and propagate the binaries should certainly know better.
They're typically not beginners at it.

And if they're propagating binaries, then the kernel options should already be similar
for the most part (yes, some hardware might cause differences but most options should be similar).
It not, shame, shame.
_________________
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: Sun Mar 02, 2014 12:43 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Gentoo users need to know better.

Sig-worthy! ;)
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7470

PostPosted: Sun Mar 02, 2014 12:51 pm    Post subject: Reply with quote

You guys gonna pickup me up on the USE ?
Make it in EMERGE_DEFAULT_OPTS or FEATURES... where it doesn't affect the binary package itself. The USE flag is not the solve, don't stay on the details, look at the solve itself.

You can even add the option to make it fatal or non fatal error per use choice. So you endup with BUILDHOST, LIVE&FATAL LIVE&NOFATAL or whatever options names you wish.
But this won't change the devs now knows they are building it on a live system or not and how to handle this.
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: Sun Mar 02, 2014 12:58 pm    Post subject: Reply with quote

My take on emerging the ebuild, is what I said earlier with an amendment.
If some kernel flag is required for the built program to run successfully (we're talking udev, systemd, etc type programs)
then it should stop the emerge process and throw up a warning.

Amendment: There should also be a way to tell it to build anyway,
which assumes the one doing the emerge has enough experience
to know what they're doing. This way, the newbie is protected, as
best one can and the pro can do as they wish.

Note: I am not referencing building on one system and deploying on another machine.
_________________
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
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Sun Mar 02, 2014 2:20 pm    Post subject: Reply with quote

ssuominen wrote:
You miss the point that udev is an userspace application, where as nvidia-drivers is a kernel module which during it's compile needs the kernel sources to be available, and configured in a certain way, where as userspace apps have no such requirement.
That's the whole difference between determining if CONFIG_CHECK="" should be set with ~ or, without it.


An userspace app that can determine if your boot breaks.
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Sun Mar 02, 2014 2:30 pm    Post subject: Reply with quote

TomWij wrote:
ssuominen wrote:
You miss the point that udev is an userspace application, where as nvidia-drivers is a kernel module which during it's compile needs the kernel sources to be available, and configured in a certain way, where as userspace apps have no such requirement.
That's the whole difference between determining if CONFIG_CHECK="" should be set with ~ or, without it.


An userspace app that can determine if your boot breaks.


Makes no difference whatsoever as already explained here.
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Sun Mar 02, 2014 2:37 pm    Post subject: Reply with quote

mv wrote:
krinn wrote:
IUSE="buildhost" emerge udev
USE="-buildhost" emerge udev

Anyway, I strongly vote against fatal errors - no matter in which phase - because there may always be valid reasons why the users wants to install anyway.


Can you give an example? Otherwise we could introduce an experimental I_KNOW_WHAT_I_AM_DOING_AND_WANT_TO_BREAK_MY_BOOT.

(Just to make sure you don't see this as all caps but rather as a variable; in case you miss the reference, google I_KNOW_WHAT_I_AM_DOING)

ssuominen wrote:
TomWij wrote:
ssuominen wrote:
You miss the point that udev is an userspace application, where as nvidia-drivers is a kernel module which during it's compile needs the kernel sources to be available, and configured in a certain way, where as userspace apps have no such requirement.
That's the whole difference between determining if CONFIG_CHECK="" should be set with ~ or, without it.


An userspace app that can determine if your boot breaks.


Makes no difference whatsoever as already explained here.


Right; as we have discussed, it needs changes to the eclass, we can look at that later.


Last edited by TomWij on Sun Mar 02, 2014 6:33 pm; edited 2 times in total
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Sun Mar 02, 2014 2:39 pm    Post subject: Reply with quote

Merged into above post.

Last edited by TomWij on Sun Mar 02, 2014 6:30 pm; edited 3 times in total
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Mar 02, 2014 2:40 pm    Post subject: Reply with quote

mv wrote:
If you do checks in pkg_preinst you can be sure that you are in the "final" system.

..and if you check ROOT/EROOT then you know whether it's the native one, or an install into a sysroot. Granted that may need to be tweaked on prefix/alternative archs, but that's the kind of thing they do all the time, and it's trivial.
Quote:
Anyway, I strongly vote against fatal errors - no matter in which phase - because there may always be valid reasons why the users wants to install anyway.

Agreed. Don't presume to know better than the sysadmin.

Warn if checks fail, so that they are aware of it, and if they're having a bad hair-day they'll soon find out when the thing doesn't boot, at which point a quick check of what was emerged recently and a look at the build-log/summary will soon let them know. That's kind of standard practice, which is stronger: they should be reviewed post-build, along with dispatch-conf.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Sun Mar 02, 2014 6:18 pm    Post subject: Reply with quote

TomWij wrote:
mv wrote:
Anyway, I strongly vote against fatal errors - no matter in which phase - because there may always be valid reasons why the users wants to install anyway.

Can you give an example?

I think that I already did: On a hardened system you may not want to expose /proc/config.gz (and not the kernel sources with .config either, of course). Being low on ram/disk space might be another reason.
Quote:
Otherwise we could introduce an experimental I_KNOW_WHAT_I_AM_DOING_AND_WANT_TO_BREAK_MY_BOOT.

Environment variables not directly supported by portage are a problem because you cannot change them when emerging binary packages. Indeed, portage will store the whole environment (with a few dedicated exceptions) into the *.tbz2 file and you cannot change it during emerge -k (unlless you hack the *.tbz2 file or portage, of course).
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Sun Mar 02, 2014 7:20 pm    Post subject: Reply with quote

mv wrote:
TomWij wrote:
mv wrote:
Anyway, I strongly vote against fatal errors - no matter in which phase - because there may always be valid reasons why the users wants to install anyway.

Can you give an example?

I think that I already did: On a hardened system you may not want to expose /proc/config.gz (and not the kernel sources with .config either, of course). Being low on ram/disk space might be another reason.


The suggestion intends to limit to systems that do expose this.

mv wrote:
Quote:
Otherwise we could introduce an experimental I_KNOW_WHAT_I_AM_DOING_AND_WANT_TO_BREAK_MY_BOOT.

Environment variables not directly supported by portage are a problem because you cannot change them when emerging binary packages. Indeed, portage will store the whole environment (with a few dedicated exceptions) into the *.tbz2 file and you cannot change it during emerge -k (unlless you hack the *.tbz2 file or portage, of course).


Have heard binary packages as a reason too many times that I to this very day still think they block progress to some extent; they are of course useful, so I think this would be fixed by being able to specify environment files that can affect the phases of the binpkg. Though, before doing so; thinking this through, I_KNOW_WHAT_I_AM_DOING_AND_WANT_TO_BREAK_MY_BOOT is not yet present in that environment which I think makes you able to change it. It kind of depends here on whether the entire outer environment is ignored; seems like a thing to prototype and experiment with, unless this is documented somewhere.
Back to top
View user's profile Send private message
broken_chaos
Guru
Guru


Joined: 18 Jan 2006
Posts: 370
Location: Ontario, Canada

PostPosted: Sun Mar 02, 2014 7:35 pm    Post subject: Reply with quote

TomWij wrote:
For upgrading users the ebuild had a file in place on your system, which you needed to explicitly remove to obtain the new naming; without preparation at all, I wasn't affected by the udev upgrade and had the old naming continue for a quite long while. Weeks to months later whilst updating my system further I decided to make the switch by removing the file after hearing about it so much; besides that, to make sure to follow new standards to prepare for the moment they would eventually drop the old naming...

I'm fairly certain the upgrade that included the new naming by default was also the same one which removed the ability to rename ethX to ethY. If not that upgrade, it was a very-closely-following one and I'd skipped the in-between version. This is my major complaint about udev's (upstream) maintenance of late, much more so than just changing things for sometimes-reasonable, sometimes-flimsy reasons... It's changing things without any backwards compatibility, without any (significant, if at all) transition period, rather than allowing the old configuration to continue working while the new one is the default for new setups.

It's just so stark a contrast compared to the upstream kernel, despite udev being all-but-required for running the kernel. Compounding the issue somewhat is the speed with which old versions of udev are purged from the portage tree after a new one is stabled. Given the configuration churn, it would be nice to have versions (especially versions from just before a news item is required on upgrade) left available for a fair while without resorting to an overlay, barring severe/security bugs in old versions.

As for the specifics, the issue I was thinking of was on a system with two NICs (so I had no option of just using the kernel naming without also probably breaking things), and the problem was that I setup a new configuration... And I thought I'd fixed all the references to network interfaces in my config (grep -r eth /etc), but I'd neglected that the firewall config was actually stored in /var/lib/iptables. As the machine had two NICs, I didn't (and couldn't, at least not very effectively) use rules without interfaces attached to them, and this ended with me not having SSH access on the appropriate interface.

But, as I said, I knew it could happen and had a serial cable on hand to fix it, so it wasn't a more serious problem.
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: Sun Mar 02, 2014 8:28 pm    Post subject: Reply with quote

broken_chaos wrote:
It's just so stark a contrast compared to the upstream kernel, despite udev being all-but-required for running the kernel. Compounding the issue somewhat is the speed with which old versions of udev are purged from the portage tree after a new one is stabled. Given the configuration churn, it would be nice to have versions (especially versions from just before a news item is required on upgrade) left available for a fair while without resorting to an overlay, barring severe/security bugs in old versions.


Yep, and the devs response has been basically FY the current version works fine. At least that's been the mantra in the past. :roll:
I quit trying to convince a certain dev that it would be wise to keep an old one or two around,
because I got tired of trying to make them have common sense and just locked my own system down.
It's a shame when the users of a distro can't trust a dev of that distro to watch out for them.

Quote:
But, as I said, I knew it could happen and had a serial cable on hand to fix it, so it wasn't a more serious problem.

Maybe not so serious for you, for others *shrugs*
_________________
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
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Sun Mar 02, 2014 9:04 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Yep, and the devs response has been basically FY the current version works fine. At least that's been the mantra in the past. :roll:
I quit trying to convince a certain dev that it would be wise to keep an old one or two around,
because I got tired of trying to make them have common sense and just locked my own system down.
It's a shame when the users of a distro can't trust a dev of that distro to watch out for them.


https://bugs.gentoo.org/show_bug.cgi?id=485546
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: Sun Mar 02, 2014 10:48 pm    Post subject: Reply with quote

Tom, I looked at your last post to see what you were saying.

The bug was about systemd, and this discussion was about udev. Two different things.

I'll give you the benefit of the doubt that maybe you gave the wrong link.
sys-apps/systemd-204-r1: PolicyKit UID

I'm not even going to get on to you about it. But try and look at it from someone elses perspective,
it seems as it you are simply trying to muddy the issue that is being discussed by answering my post
with something not related to it, other than extremely tangentially.

If you are trying to say that pointing to some bug about systemd refutes what I was saying, then you are in error.

I do think that most of the gentoo devs (yes, that includes you) are trying their best, but it would help,
if some of you would simply quit trying to justify each and every post some one else makes.
Actions speak louder than words. Let the actions speak for themselves. Just some friendly advice.
And whether you take it or not, or simply think I'm too stupid to understand things is ok by me.
_________________
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: Sun Mar 02, 2014 10:59 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Tom, I looked at your last post to see what you were saying.

The bug was about systemd, and this discussion was about udev. Two different things.

I'll give you the benefit of the doubt that maybe you gave the wrong link.
sys-apps/systemd-204-r1: PolicyKit UID

I'm not even going to get on to you about it. But try and look at it from someone elses perspective,
it seems as it you are simply trying to muddy the issue that is being discussed by answering my post
with something not related to it, other than extremely tangentially.

If you are trying to say that pointing to some bug about systemd refutes what I was saying, then you are in error.

I do think that most of the gentoo devs (yes, that includes you) are trying their best, but it would help,
if some of you would simply quit trying to justify each and every post some one else makes.
Actions speak louder than words. Let the actions speak for themselves. Just some friendly advice.
And whether you take it or not, or simply think I'm too stupid to understand things is ok by me.


You are right, it was a mistake to link to that bug. It was not related to the removal of old udev's. The old udev's were incompatible with the current sys-apps/hwids (conflicting 60-keyboard.hwdb in new hwids), sys-fs/udisks (no hwdb.bin in old udev), the old version of google-chrome binary-only package shipped it's own prebuilt libudev.so.0, the google-musicmanager stopped requiring eth0, OpenVZ containers no longer needed udev as they only needed couple of nodes created by mknod, not a full scaled /dev, ...
That's only some 1% of the story, but it started to be work to keep the old versions around, and since they were completely redudant, as nobody could give any reason whatsover for keeping them, there was no point to put any work into them anymore
Plus, nothing is ever completely deleted from internet (like Portage tree, which is on a version control, CVS):
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-fs/udev/?hideattic=0
I believe the only person I've seen ranting about this in the forums are you, and yet again, you are rehashing an old issue we have already discussed to death, and for what?
Back to top
View user's profile Send private message
jonathan183
Guru
Guru


Joined: 13 Dec 2011
Posts: 318

PostPosted: Sun Mar 02, 2014 11:22 pm    Post subject: Reply with quote

ssuominen wrote:
Plus, nothing is ever completely deleted from internet (like Portage tree, which is on a version control, CVS):
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-fs/udev/?hideattic=0

thanks ... I was looking for that yesterday but I think the server was down so ended up trying to search on git 8)
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: Sun Mar 02, 2014 11:30 pm    Post subject: Reply with quote

I'm really not trying to have a fight with gentoo devs, any of them.
But some of you need to stop and think that maybe, just maybe, not all of us users are idiots.

I know that the attic exists. I personally tar up the whole portage tree (ebuilds/eclasses minus distfiles)
each night, but I only keep the sources of those things that I have downloaded, and AFAIK the sources
aren't kept around once the ebuilds are gone. I know that in the past I've been lucky enough to find
old sources in some obscure archive, but it's not a given.

The ebuilds are only a small part of being able to rebuild something old. So what I said is in effect true.
If I can't recreate the binaries because the sources are unavailable even with an ebuild, then the ebuild is useless, for my purposes.


Edit to add: I would love to be wrong and find out that the sources are kept along with ebuilds, but if so I haven't run across them in the past.

Edit to add2: I'm not asking for the sources to be kept, just trying to clarify.
_________________
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
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Sun Mar 02, 2014 11:48 pm    Post subject: Reply with quote

OK, udev is now dead to me. I sync'd today and it requires systemd. The old versions are gone from tree. I tried to copy the udev-204 ebuild from another box into my local overlay, but I get:
Quote:
emerge -a1v udev

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

Calculating dependencies... done!
[ebuild N ] sys-fs/eudev-1.3 USE="gudev introspection modutils openrc rule -generator -doc -hwdb -keymap -kmod (-selinux) -static-libs {-test}" ABI_X86="(6 4) (-32) (-x32)" 1,641 kB
[ebuild UD ] sys-fs/udev-204::x-portage [208::gentoo] USE="acl firmware-load er gudev introspection keymap%* kmod openrc -doc -hwdb% (-selinux) -static-libs" ABI_X86="(-32%) (-64%*) (-x32%)" 0 kB
[blocks B ] sys-fs/udev ("sys-fs/udev" is blocking sys-fs/eudev-1.3)

Total: 2 packages (1 downgrade, 1 new), Size of downloads: 1,641 kB
Conflict: 1 block (1 unsatisfied)

* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.

(sys-fs/udev-204::x-portage, ebuild scheduled for merge) pulled in by
sys-fs/udev required by @selected
udev

(sys-fs/eudev-1.3::gentoo, ebuild scheduled for merge) pulled in by
>=sys-fs/eudev-1.3[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n3 2(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,modutils,gudev?,introspection?,selinux?, static-libs?] (>=sys-fs/eudev-1.3[abi_x86_64(-),modutils,gudev,introspection]) r equired by (virtual/udev-208-r1::gentoo, installed)


For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked


!!! The following installed packages are masked:
- virtual/udev-208-r1::gentoo (masked by: package.mask)
/etc/portage/package.mask:
#>=sys-fs/udev-init-scripts-18

The 208-r1 is gone and 204 seems to be telling me to install eudev instead.

Neddy Seagoon, I trust your judgement. Please recommend the best altrenative that does NOT require systemd. Is it mdev or eudev? Should I emerge -C udev, before or after?
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 8933

PostPosted: Mon Mar 03, 2014 12:00 am    Post subject: Reply with quote

Before trying to make sense of that output, why have you masked virtual/udev-208-r1?
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Mon Mar 03, 2014 12:08 am    Post subject: Reply with quote

Tony0945 wrote:
OK, udev is now dead to me. I sync'd today and it requires systemd.


Untrue, sys-fs/udev does not, and will never require sys-apps/systemd. The old version of sys-fs/udev, like 204, is incompatible with current sys-apps/hwids because hwids now has 60-keyboard.hwdb file which would generate an incompatible hwdb.bin for anything older than 208.
So, don't try mask 208 or anything like that, it's unnecessary and the propable cause of such Portage conflict.
Also, make sure to use virtual/udev and sys-fs/udev both either from stable, or from ~arch, don't try to mix them up.
Back to top
View user's profile Send private message
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Mon Mar 03, 2014 12:25 am    Post subject: Reply with quote

I masked >=208 because portage wanted to install systemd and make other changes after syncing today. The 208-r1 that I installed yesterday is gone from the mirror and thus from my system after today's sync.

I really don't want to quibble about the meaning of "required". I can't 'emerge -auvND world' without systemd which the terminal tells me is because of udev. Maybe that isn't 'required', but it's close enough for me. I just want to keep my OpenRC systems and I don't want a fixed /dev because I do use usb sticks.
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Mon Mar 03, 2014 1:03 am    Post subject: Reply with quote

Tony0945 wrote:
I masked >=208 because portage wanted to install systemd and make other changes after syncing today. The 208-r1 that I installed yesterday is gone from the mirror and thus from my system after today's sync.

I really don't want to quibble about the meaning of "required". I can't 'emerge -auvND world' without systemd which the terminal tells me is because of udev. Maybe that isn't 'required', but it's close enough for me. I just want to keep my OpenRC systems and I don't want a fixed /dev because I do use usb sticks.


The only version of virtual/udev in Portage is =virtual/udev-208-r1 which is marked stable. That virtual allows >=sys-fs/udev-208, so any version, =sys-fs/udev-208, =sys-fs/udev-210, or =sys-fs/udev-9999 will do.
So, don't try to mask virtual/udev, sys-fs/udev or their dependencies like sys-apps/hwids. Masking them would cause unexpected results, like Portage attempting to replace sys-fs/udev with alternate version of
sys-apps/systemd or sys-fs/eudev.
The whole reason of sys-fs/udev's existance is that there are people who still want to use original unforked udev with sys-apps/openrc.
The output you just posted, looks like an result of something you did in /etc/portage, so undo those changes, and if you still have problems, post a new output.
Back to top
View user's profile Send private message
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Mon Mar 03, 2014 1:14 am    Post subject: Reply with quote

Removed sys-fs/udev and virtual/udev from package.mask, unmerged both and emerged eudev which installed v1.3 and vitual/udev. I was then able to complete the world update without blockers or attempts to install systemd (which remains in package.mask). It looks good but I haven't rebooted, although I did run '/etc/init.d/udev restart as called for in the postinst notes. I was encoraged the the putty link stayed up. I should check that my files are still there to keep eth0 and reboot (tomorrow).


I chose eudev instead of mdev purely because it's in the tree.
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 4 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