how many are using this fork already? how stable is it?
I'm thinking of migrating to it but I cannot afford it to shutdown my server.

Udev-189 have been downloaded about 40 times, and I don't know how many people use -9999 (probably more than -189, though bitbucket doesn't provide statistics on repo access, so I can't say for sure).
At the moment we have no runtime issues, and I think I can say it's stable enough to be used. No system restart is needed :)

how many are using this fork already? how stable is it?
I'm thinking of migrating to it but I cannot afford it to shutdown my server.

Udev-189 have been downloaded about 40 times, and I don't know how many people use -9999 (probably more than -189, though bitbucket doesn't provide statistics on repo access, so I can't say for sure).
At the moment we have no runtime issues, and I think I can say it's stable enough to be used. No system restart is needed

the 9999 is the equivalent of udev-9999?

yup.

I assume right that that the ebuilds are layman?_________________Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein
ProjectFootball

Not quite sure I understand what you mean, but yeah, you can install udev from the udev overlay.

I know I had trouble getting the correct udev (and kmod) to be pulled in by portage, and had to specify udev::udev and kmod::udev respectively, but it worked fine after that, I'm sure its because this was my first time using an overlay.

I know I had trouble getting the correct udev (and kmod) to be pulled in by portage, and had to specify udev::udev and kmod::udev respectively, but it worked fine after that, I'm sure its because this was my first time using an overlay.

hcaulfield57 ... as I tried to explain above, but perhaps I wasn't clear enough, becuase udev-189 and udev-9999 are not keyworded but udev-init-scripts-16 is (~arch) if not stating the '**' you may end up with udev-9999 and udev-init-scripts-16. The later expects udevd to be in /lib/udev/ while the udev-init-scripts-9999 in /sbin. Its the mis-match I reported in post 7136814

The problem as I reported it is that you can't state 'sys-fs/udev-9999::udev **' or 'sys-fs/udev-189 **' (becuase '**' implies 9999 and so amounts to an invalid atom) but as both sys-fs/udev-189 and sys-fs/udev-9999 are not keyworded, but udev-init-scripts-16 is, without explicitily stating the live ebuild ('**') you will end up (as you did) with two mis-matched packages.

The sys-fs/udev-189.ebuild can not be installed without first keywording, and should only be installed along side udev-init-scripts-16 (unless of course you do as I advised above and edit /etc/conf.d/udev).

Users should probably also mask the udev, udev-init-scripts, and kmod packages from ::gentoo

Not quite sure I understand what you mean, but yeah, you can install udev from the udev overlay.

that is what I meant, I'll try it when I get the time, thanks._________________Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein
ProjectFootball

The above keywording issue has been fixed in the overlay (thanks grey_d0t) ... so, for those not wanting the live ebuilds the following should now provide udev-189 and udev-init-scripts-16 (and udevd located in /lib/udev)

/etc/portage/package.accept_keywords

Code:

sys-apps/kmod::udev
sys-fs/udev::udev
sys-fs/udev-init-scripts::udev

and for the live ebuilds, providing udev-9999 and udev-init-scripts-9999 (and udevd located in /sbin)

I read this topic. I very much agree and appreciate udev-standalone that you developed.
However, those guys behind some apparently silly ideas described in this topic seem to still have a way to make the udev-standalone development difficult...
I only bet it must be something to do with this transition.
I am no programmer, just somewhat experienced user.
My systems generally just work, updated daily or so, testing ~amd branch.

udev is from gentoo overlay, which is currently installed in the system...

wouldn't boot at all.
All the older kernels boot with just a handful of devices created...

I bet so much it is something to do with this transition, that I dare post this issue here.
I'm available for testing to fix this. I can't do the planned upgrade unless I get it fixed.
To not have to type things in here manually, I do need to boot with sysresccd, get the network up and chroot to repair my system and to uproot, if possible, what's left of evil code deriving from the bad and annoying areas intruding into GNU Linux, as some people dare to see them, don't thay?

I read this topic. I very much agree and appreciate udev-standalone that you developed. However, those guys behind some apparently silly ideas described in this topic seem to still have a way to make the udev-standalone development difficult...

miroR ... this just looks to me as though you have installed udev-standalone but haven't installed the udev-init-scripts also from the udev overlay. So, gentoo's init scripts are looking for /usr/lib/systemd/systemd-udevd which of course udev-standalone doesn't have.

More info on the mess above.
But first: of course, if you devs deem my posts don't belong here, feel free to move them to somewhere else!
OTOH, since I broached it here, I do need to supply more info now. So here I go.
From sysresccd, where I got the network and X and all for the box currently handicapped. Chrooted, as recommended (by my friend François Dupoux) here:
http://www.sysresccd.org/Sysresccd-Partitioning-EN-Repairing-a-damaged-Grub:
The info:

EDIT: But the guide refers to renaming those binaries in initramfs directory, doesn't touch the system's ones. So I didin't get that warning, really. It'll take longer for me to figure it out, in my old age, as I am. (end of EDIT)
And now I don't anymore bet with such certainty as before...
Sorry... (Not yet in the clear though, either. Need more pondering, deep thinking and stretching my capabilities to figure this out... God, this will kill me, again! )

Last edited by miroR on Sun Sep 16, 2012 11:23 pm; edited 1 time in total

I read this topic. I very much agree and appreciate udev-standalone that you developed. However, those guys behind some apparently silly ideas described in this topic seem to still have a way to make the udev-standalone development difficult...

miroR ... this just looks to me as though you have installed udev-standalone but haven't installed the udev-init-scripts also from the udev overlay. So, gentoo's init scripts are looking for /usr/lib/systemd/systemd-udevd which of course udev-standalone doesn't have.

best ... khay

khayyam,
nice to converse with you, I respect what you do for us users! Thanks!
But no, see this:

* Depclean may break link level dependencies. Thus, it is
* recommended to use a tool such as `revdep-rebuild` (from
* app-portage/gentoolkit) in order to detect such breakage.
*
* Always study the list of packages to be cleaned for any obvious
* mistakes. Packages that are part of the world set will always
* be kept. They can be manually added to this set with
* `emerge --noreplace <atom>`. Packages that are listed in
* package.provided (see portage(5)) will be removed by
* depclean, even if they are part of the world set.
*
* As a safety measure, depclean will not remove any packages
* unless *all* required dependencies have been resolved. As a
* consequence, it is often necessary to run `emerge --update
* --newuse --deep @world` prior to depclean.

Continuing.
(The kernel can be read the name of in earlier post above. The newest, last night's or so.)
The lvm2 and xorg-server installed fine.
Here, the third package not,
/var/log/portage_logs/sys-fs:udisks-1.0.4-r3:20120916-235246.loghttp://pastebin.mozilla.org/?dl=1826216
The error:

I can't figure what it means.
Neither what to do now.
Let alone not clear to me, still, still! if these posts of mine with these woes belong here... Sorry if they don't. Glad if they do. Because then bigger issues are solved along with mine...
Any more info, like emerge --info and things. Doing them, in the similar hopefully non-obtrusive pasted form as the above!
EDIT: emerge --info:
http://pastebin.mozilla.org/?dl=1826225
(end of EDIT)
Just:
PORTAGE_TMPDIR="/var/tmp" is only so temporarily with sysresccd. It is sure:
PORTAGE_TMPDIR="/dev/shm" regularly.

/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libudev.so.1, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libatasmart.so, not found (try using -rpath or -rpath-link)

/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libudev.so.1, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libatasmart.so, not found (try using -rpath or -rpath-link)

miroR: Do you have automount devtmpfs enabled in the kernel? I find it odd that you are having so many errors, because I just did a reinstall of Gentoo on my desktop, and I'm using the forked udev-189 with udev-init-scripts-16 and everything is working perfectly.

I'm very glad that udev has been forked, please keep up the good work.

miroR: Do you have automount devtmpfs enabled in the kernel? I find it odd that you are having so many errors, because I just did a reinstall of Gentoo on my desktop, and I'm using the forked udev-189 with udev-init-scripts-16 and everything is working perfectly.

I'm very glad that udev has been forked, please keep up the good work.

Hi, hcaulfield57!
It's the sysresccd kernel, because I'm chrooted with it.
I don't know. How do I found out. And why would it matter?

But VoidMage was, I think, wrong.
This piece of code form the paste above the .. sys-fs:udisks-1.0.4-r3... .log)

No, but the error is now different, and I got way past the error above!
/var/log/portage_logs/sys-fs:udisks-1.99.0-r1:20120917-012727.loghttp://pastebin.mozilla.org/1826341
I actually can't even post the entire log on mozilla pastebin. The above link is short.
I'll make another with the ending of
/var/log/portage_logs/sys-fs:udisks-1.99.0-r1:20120917-012727.log:
http://pastebin.mozilla.org/1826356
Back at hcaulfield57's advice I might be if I don't get to boot into my box normally. Or indeed if I don't get normal boot, that is if these problems persist... Don't know yet. I'll try boot into this Gentoo box now and be back to tell. Or maybe I study the error that's left for me... first...
Can't figure out the errors...
Which are, in brief, withe the aforementioned
/usr/lib64/libatasmart.so:

got me into X, but, alas, no keyboard, no mouse. True Vulcan pinch only to restart the system. That is, the mechanical reset switch. Because, still no network (meaning: no ssh from my home/no-internet network into the box), because udev don't start and makes no devices...
I had that no kbd, no mouse situation already, I know it's somewhere on the Forums to find how to deal with it, but if someone remembers the trick or where it is, thanks!
Recompiling my kernel, and willl probably try and reboot again.
I think this got to do with this topic where I put it.
It's udev the principal culprit here... I think.
EDIT: Upon reboot with anotther kernel recompile, the situation still stabilized into what already above stated: no net, X w/ no kbd/mouse, udev don't start. end of EDIT.

Most certainly a dev understands what to do with this "easy" piece of advice, but I'm not one, and getting to be one, not in my old age!

Code:

(try using -rpath or -rpath-link)

That is a piece of advice for the programmer to put in the program for users to compile, IMHO, ain't it?

Before taking an advice, be sure to understand it.

Now that's a nice maxim which I'll try to remember!
And this is what I could've figured, from `man ldd`:

VoidMage wrote:

See 'ldd -r /usr/lib/libatasmart.so' for a partial explanation.

but it sure is a programmer's piece of learning:

Quote:

-r --function-relocs
Perform relocations for both data objects and functions, and report
any missing objects or functions (ELF only).

hcaulfield57, worth trying simple causes, but I'm not that inexperienced to not have had added:

Code:

# rc-update add udev default

long ago, at the time some guide somewhere said to do it.
OTOH, on a non running kernel (I'm in sysresccd chroot, as explained above), I can't run

Code:

# rc-status

to check it.
But you do seemm to have a point, hey!
I got three other clones (same model MBO and partitioning, mostly dd made clones, with arfterwords modified /etc/fstab /etc/hosts /etc/confd./hostname /etc/confd.d/net and /etc/udev/rules.d/70-persistent-net.rules that, the last one, I moved to /lib/udev/rules.d/70-persistent-net.rules but keep a symlink /etc/udev/rules.d -> /lib/udev/rules.d/ end of describing cloning), and only one of those three other cloned boxes shows:

Code:

# rc-status|grep udev
* udev [started]
* udev-mount [started]
#

and it's the one with the

Code:

sys-kernel/hardened-sources-3.5.3-r2_120914_0200

where "120914_0200" is my local version showing hand written date and hour when I was compiling it.
The other clones show, one

Code:

# rc-status|grep udev
#

that is nada, nichts, nil, and the other

Code:

# rc-status|grep udev
* udev-mount [started]
#

Both of them are running the kernel:

Code:

sys-kernel/3.5.2-hardened-r4_120829_1200

and I have only now found why these wouldn't get my /etc/init.d/net.eth0 and /etc/init.d/net.eth1, of which one is no-outside world home network (for safety, I am just not surveilled all the time) and the other is dhcpcd Croatia's poor man's broadband (ADSL max 700kbs, when they're not choking your connection, depends what your're doing)... But I was saying... I have only now found some of the reason why these wouldn't get my eth0 and eth1 configured properly.
It's the fabulous money making and probably (for one program, I do suspect money and corruption must be involved: SELinux) gov money taking or no spine and dignity having (no proof, but how on Earth else?), individuals from RedHat (now Fedora) community's great systemd into udev piece of programming, that so much nicer people, though imperfect, you gentoo developers have to rescue GNU Linux from...
That is what I as Joe User suspect is what we're dealing with here. Just what honest devs like khayyam and others eplained in previous posts in this thread.
As an aside: At first SELinux was introduced as if it was RedHat's and not NSA's! (want a link?), and it almost broke the GNU licence for the kernel! (No more rambling, I promise! I'll even take the flak hands down and speechless!)
Now, I sure have to follow the still timely (it's Good morning to you from Europe, lads!) piece of advice by VoidMage.

But it doesn't tell me, the user, much... Thanx for the support so far, and hopefully for solving this issue soon!
EDIT (Sorry, I have flaky connection to www from sysresccd, and also my friend Françoiis Dupoux's zsh is driving me crazy, God, bash is my dear cutie! And a previous edition got in for those reasons, instead of the finer worded last one a.k.a. final edition... and it took time. It's past noon, was still morning when I began this current post, end of EDIT)

Just as in the earliest post of mine in this thread (https://forums.gentoo.org/viewtopic-p-7142184.html#7142000), I have on every reboot after all the kernel recompiles and emerge --depclean and revdep-rebuild's, as the system was starting services and angels (oh, they are called 'daemons', but that's so ugly), I have always, ever since the breakage showed up 10-15 hours ago now, seen the same line as in that first post of mine in this thread:

That is what is currently broken in my system. The line on booting also means that udev is in the default rc services. The thing is, I'm very reluctunt now, to load or experiment in any minimal ways with the other three clones, especially not in the sense of rebooting them, because of the broken udev, shown in this one, but clearly present in the other three clones as well...
I would need expert help here as I don't seem to be able to fix this on my own, no way!
EDIT: Just, since we're talking, if you go and revisit my last years thread (with a timid unsuccessful but noted and criticized renewal this year), my system IMO was under attack. I can still show you my /var/log/auth.log file is still stumped at this time as well, right at the same time and place where it got stumped probably by the attacker, apparently before I went hardened-kernel with grsecuriy/pax ...), and doesn't seem to be touched by intruders later on. Read this part: https://forums.gentoo.org/viewtopic-t-905472.html#6901814
I mean, since not other people seem to be experiencing these issues (anyone else has these issues?), could it be someone hacking into and breaking things in my systems when they are open to www?
But if noone else has these issues, I cannot expect too much of anybody else's time on these issues.
Thanks again for the support given so far, though! end of EDIT

Last edited by miroR on Mon Sep 17, 2012 11:38 am; edited 1 time in total

miroR ... this just looks to me as though you have installed udev-standalone but haven't installed the udev-init-scripts also from the udev overlay. So, gentoo's init scripts are looking for /usr/lib/systemd/systemd-udevd which of course udev-standalone doesn't have.

Yes, exactly as I stated, the version you have installed is sys-fs/udev-init-scripts-16::gentoo, which would be replaced by sys-fs/udev-init-scripts-16::udev. So, the wrong package.

Now, assuming the above revdep-rebuild was successful, replacing udev-init-scripts should be all thats needed.

Point of order: please try to focus your report into something that is parsable, and please try to focus on the issue and not digress into all manner of observations. It would also help if you made one succinct post rather than a whole chain of posts, that is, less noise more signal.