remove udev completely since most of it's functions are moved to the kernel (I chose the later option).

Can you comment on that last point a bit ? I moved to static /dev on my server some time ago (not new hardware and nothing hot-pluggable in years),
but what needs to be done on a laptop to be udev free ?

remove udev completely since most of it's functions are moved to the kernel (I chose the later option).

Can you comment on that last point a bit ? I moved to static /dev on my server some time ago (not new hardware and nothing hot-pluggable in years),
but what needs to be done on a laptop to be udev free ?

Same as with your server, actually. Device nodes creation is done by kernel with devtmpfs. And since kernel 3.7, firmware is also loaded by kernel itself. Just make sure you have the necessary options enabled in your kernel config. The only thing you have to do by hand without udev is loading the kernel modules.

I'm actually thinking about either hotplug2 revival or porting freebsd devd as a sane alternative to udev.

It wasn't lost time anyway, without this fork, nothing would have change, and we (users) would have end with systemd crap.
So thank you for being the one who start saying "no".

++

I have been living with devtmpfs+mdev for a while. I refuse to move to systemd. Ever. I will sooner drop Linux entirely. No matter how insistent people are that the only reason I don't love systemd, is that I'm simply not educated enough to know why it's the best thing since sliced bread (ahhh, takes me back to pulseaudio!). Creating a useful fork that gives us an alternative and spurs a change is huge huge hugely important and awesome.

grey_dot wrote:

I'm actually thinking about either hotplug2 revival or porting freebsd devd as a sane alternative to udev.

It wasn't lost time anyway, without this fork, nothing would have change, and we (users) would have end with systemd crap.
So thank you for being the one who start saying "no".

++

I have been living with devtmpfs+mdev for a while. I refuse to move to systemd. Ever. I will sooner drop Linux entirely. No matter how insistent people are that the only reason I don't love systemd, is that I'm simply not educated enough to know why it's the best thing since sliced bread (ahhh, takes me back to pulseaudio!). Creating a useful fork that gives us an alternative and spurs a change is huge huge hugely important and awesome.

grey_dot wrote:

I'm actually thinking about either hotplug2 revival or porting freebsd devd as a sane alternative to udev.

sweet!

move to what os?_________________Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein

I'm sorry to announce this, but both me and consus decided to abandon the development of this fork. Too much of bad [Mod edit for language. — JRG] code and not enough free time. Repo and overlay will still be accessible.

You can either try to use gentoo devs' fork, stick to an older version, or remove udev completely since most of it's functions are moved to the kernel (I chose the later option).

Thanks to everyone who took part in the development. It was cool

Fine, but how do some of us, I bet I'm not alone, figure out how to do that?
Any guides somewhere?
How nice: "remove udev completely"...
I don't have the cogs and wheels of Gentoo in my subconscious like you...
More verbose tips could do the difference... if possible...

Fine, but how do some of us, I bet I'm not alone, figure out how to do that?
Any guides somewhere?
How nice: "remove udev completely"...
I don't have the cogs and wheels of Gentoo in my subconscious like you...
More verbose tips could do the difference... if possible...

Your options are as follows:
1) Use upstream systemd-udev with an initramfs if you have separate /usr, although there has been some talk of fixing the ebuild.

2) Mask versions of udev above 171.

3) Switch to eudev, which works nicely with separate /usr and should meet your requirements for udev.

if linux became nearly impossible to use without systemd, i would cling to every last possible workaround.
when that became too much - our software at work works perfectly fine on FreeBSD, and has for over a decade - so that would be my next logical choice.I simply will not be forced into using systemd. I refuse. I don't care what other negatives may exist on another platform, I will not be forced into stupid. If the way I have been doing things for years changes into an unrecognizable monstrosity, might as well be because I've moved to a different platform.

if linux became nearly impossible to use without systemd, i would cling to every last possible workaround.

If Linux becomes unusable without a particular init system, it's probably fair to say that it ceases being UNIX, as the kernel should never be tied to any specific userland utility or program. Even the BSD's which maintain the userland along with the kernel can function with different init systems._________________"To design the perfect anti-Unix, make all file formats binary and opaque, and require heavyweight tools to read and edit them." - The Art of Unix Programming

Fine, but how do some of us, I bet I'm not alone, figure out how to do that?
Any guides somewhere?
How nice: "remove udev completely"...
I don't have the cogs and wheels of Gentoo in my subconscious like you...
More verbose tips could do the difference... if possible...

Your options are as follows:
1) Use upstream systemd-udev with an initramfs if you have separate /usr, although there has been some talk of fixing the ebuild.

2) Mask versions of udev above 171.

3) Switch to eudev, which works nicely with separate /usr and should meet your requirements for udev.

Thanks!
Your lines will be gone over numerous times. Things are not "developing" fast here (meaning my Gentoo cogs'n'wheels understanding). Hope I won't be too late for related questions (which I couldn't produce pronto no way).
Maybe just one question is ready:
/etc/portage/package.accept_keywords:

# this is /etc/portage/package.accept_keywords
# and it is empty
# sure, if people have unrelated to ::udev entries, those remain

in all the cases (of which systemd is out of consideration) you suggest?
And, which other things are there to undo before thinking of options.
And, maybe, which one's the easiest one that doesn't put too much strain on avarage user to accomplish, do you think?

in all the cases (of which systemd is out of consideration) you suggest?
And, which other things are there to undo before thinking of options.

Of course, systemd is out of the question I am currently using eudev (and it's working quite well). For reference:
/etc/portage/package.accept_keywords

Code:

sys-fs/eudev
virtual/udev
sys-fs/udev-init-scripts

/etc/portage/package.mask

Code:

sys-fs/udev

miroR wrote:

And, maybe, which one's the easiest one that doesn't put too much strain on avarage user to accomplish, do you think?

The solution that puts the least amount of strain on the average user is probably to simply mask versions of udev greater than 171. This should allow you to keep a stable system and not run into any problems with portage being annoying because of using keyworded packages. And then to simply wait and see what options develop over time._________________"To design the perfect anti-Unix, make all file formats binary and opaque, and require heavyweight tools to read and edit them." - The Art of Unix Programming

in all the cases (of which systemd is out of consideration) you suggest?
And, which other things are there to undo before thinking of options.

Of course, systemd is out of the question I am currently using eudev (and it's working quite well). For reference:
/etc/portage/package.accept_keywords

Code:

sys-fs/eudev
virtual/udev
sys-fs/udev-init-scripts

/etc/portage/package.mask

Code:

sys-fs/udev

Entries added into there.

hcaulfield57 wrote:

miroR wrote:

And, maybe, which one's the easiest one that doesn't put too much strain on avarage user to accomplish, do you think?

The solution that puts the least amount of strain on the average user is probably to simply mask versions of udev greater than 171. This should allow you to keep a stable system and not run into any problems with portage being annoying because of using keyworded packages. And then to simply wait and see what options develop over time.

Fine, but no. I am already offered eudev by portage, and that is probably best option, long term.
Haven't emerge-updated system in 10 or more days, so it's normal to have a few extra hurdles for solving...
Might be back to ask more questions if I don't solve these so soon.

miroR: That looks correct, there is no reason to mask xz-utils, kmod, udev-init-scripts, or virutal/udev because they should all install correctly from portage. However, if you want to use eudev, you will need to enable testing udev-init-scripts, and virtual/udev as they are dependencies. You should also make sure to have docbook-xsl-stylesheets installed, as eudev needs that (right now) for some reason._________________"To design the perfect anti-Unix, make all file formats binary and opaque, and require heavyweight tools to read and edit them." - The Art of Unix Programming

miroR: That looks correct, there is no reason to mask xz-utils, kmod, udev-init-scripts, or virutal/udev because they should all install correctly from portage. However, if you want to use eudev, you will need to enable testing udev-init-scripts, and virtual/udev as they are dependencies. You should also make sure to have docbook-xsl-stylesheets installed, as eudev needs that (right now) for some reason.

Warning. Following is non-related to this topic.
BTW, I got a suspicious activity non-related to this thread, but happening at the time about half hour ago from now:

Code:

# date
Thu 20 Dec 10:47:54 CET 2012
#

and this is just to mark the truth about it in real time. Will post about it in less restrictive place on Gentoo forums (and give a link to there in here, since I'm talking about it). Need only to mark it here, because this thread at this time features in the video I am now posting on vimeo.
EDIT start
https://forums.gentoo.org/viewtopic-p-7207178.html
("Preparation to demonstrate strange intrusion into my system")
EDIT end

Last edited by miroR on Thu Dec 20, 2012 11:41 am; edited 1 time in total

Remove the overlay, you can use udev-init-scripts that are in portage._________________"To design the perfect anti-Unix, make all file formats binary and opaque, and require heavyweight tools to read and edit them." - The Art of Unix Programming

If Linux becomes unusable without a particular init system, it's probably fair to say that it ceases being UNIX

Yes. The goal of these people (systemd freedesktop etc) is GNOME OS which in philosophy and main concepts is something completely different than UNIX. This is the main problem: If they would develop these concept in their own kernel and own users nobody would complain. The problem is that they want to force it over the linux world although it obviously contradicts in its main concepts.

Remove the overlay, you can use udev-init-scripts that are in portage.

Give us the command, gov!
Which overlay is it?
It takes time warming up here (remember I was telling about cogs'n'wheels of Gentoo in people's subconscious... Well, it's in deeper subconscious here, that's deep fishing for thought less someone comes to the aid of the needy )

I walked away from updating udev at 171-r7 when they required adding udev-mount to startup.
Not that that's a problem per se, but I saw the handwriting on the wall for further complexity to come.

I copied udev-171-r6 to my local portage tree and added ">=sys-fs/udev-171-r7" to package.mask.

I've had a /dev directory since before udev and have done a tar backup of /dev that udev has created
so it wouldn't be too hard to do away with it completely and go back to a static /dev.
The only thing I would have to do is go back to the old style xorg.conf (I think that's required if udev goes bye-bye).

Yes. The goal of these people (systemd freedesktop etc) is GNOME OS which in philosophy and main concepts is something completely different than UNIX. This is the main problem: If they would develop these concept in their own kernel and own users nobody would complain. The problem is that they want to force it over the linux world although it obviously contradicts in its main concepts.

Yes, and therein lies one of the most important issues with this whole systemd/udev thing.

miroR wrote:

Give us the command, gov!
Which overlay is it?

The problem is you still have the 'udev' overlay installed, which is not necessary if you want to use eudev. You should run `layman -d udev` to get rid of it. The version of udev-init-scripts I'm using is sys-fs/udev-init-scripts-18. Let me know if that helps.

Anon-E-moose wrote:

I've had a /dev directory since before udev and have done a tar backup of /dev that udev has created
so it wouldn't be too hard to do away with it completely and go back to a static /dev.
The only thing I would have to do is go back to the old style xorg.conf (I think that's required if udev goes bye-bye).

That actually should be uncessary, I tested out static-/dev at one point to see it's viability (it works properly, does what it should), and not much is required to get xorg working properly._________________"To design the perfect anti-Unix, make all file formats binary and opaque, and require heavyweight tools to read and edit them." - The Art of Unix Programming

I walked away from updating udev at 171-r7 when they required adding udev-mount to startup.
Not that that's a problem per se, but I saw the handwriting on the wall for further complexity to come.

I copied udev-171-r6 to my local portage tree and added ">=sys-fs/udev-171-r7" to package.mask.

I've had a /dev directory since before udev and have done a tar backup of /dev that udev has created
so it wouldn't be too hard to do away with it completely and go back to a static /dev.
The only thing I would have to do is go back to the old style xorg.conf (I think that's required if udev goes bye-bye).

Good luck to those fighting the newer udevs.

just as a heads up, Chromium will not build without a relatively recent udev
so even though I moved to mdev ages ago, I've had to at least have the udev package installed as a build dependency for certain things. Nothing from udev is ever run, but it's there so the chromium build doesn't complain.

this is one of many seemingly trivial things that make me raise an eyebrow, and bring up the idea of "being unusable without systemd" - how long until chromium depends on some library from systemd?

NB: i didnt really mean to deviate from the subject of the thread, i.e. the udev fork, but it's worth noting some things just plain can't exist without udev. Merely having a /dev manager may become insufficient, and at this rate it won't be long before nearly every application we use requires "official" udev. Slipper slope and such, today it's packages linking against udev, tomorrow it's packages linking against systemd._________________Lost configuring your system?
dump lspci -n here | see Pappy's guide | Link Stash

34992 views of this thread at this time.
(in words and rounded up, it's thirty-five thousands, 35,000)...
I'm afraid I haven't solve this for myself, for one. Yet.
I was away for a few days. So....

hcaulfield57 wrote:

mv wrote:

Yes. The goal of these people (systemd freedesktop etc)
... [snip] ...
...is that they want to force it over the linux world although it obviously contradicts in its main concepts.

And I haven't rid of systemd yet.
The ::gentoo udev, actually what should've been marked with ::gentoo instead of this abandoned ::udev (and I don't know where I lost it if I did), more precisely:
(I tried in vain to post in pastebin.com ... They're boycotting my Tor browser, can't post unless I log in, mozilla already removed some of my pastes... nowhere can I paste)...
So I'll have to post it here... shortened to most relevant.
========= emerge --info sys-fs/udev start ===========

I know it's incomplete (and I didn't snip so well, never mind my trying), but there it is, the main ::gentoo repo (in top of the shortened paste), where I think this package is from... so my doubt is solved, IIUC.
But how come that package shows these files, I'm following in short intervals this topic right now in real time, if the previous output would need putting in say useflags, or if the following output need be cut shorter, someone tell me, because I'm afraid if I shorten the following upfront, it might be too incomplete. This is a difficult and uncertain decision to post all of the following...
========= equery files sys-fs/udev start ===========

========= equery files sys-fs/udev end ===========
I haven't rid of systemd.
How come?

hcaulfield57 wrote:

miroR wrote:

Give us the command, gov!
Which overlay is it?

The problem is you still have the 'udev' overlay installed, which is not necessary if you want to use eudev. You should run `layman -d udev` to get rid of it.

I did figure out after I rummaged about it in my subconscious... More verbosity upfront on your part would have helped me figure out sooner back then. But as you can see further above, my problem has probably not gone away. I still have that systemd in there IIUC.

hcaulfield57 wrote:

The version of udev-init-scripts I'm using is sys-fs/udev-init-scripts-18. Let me know if that helps.

Nope. I'm afraid I went completely elsewhere, under the systemd creators' claws... or I don't know where exactly.
Because, for shortness this time (I can expand if necessary later):

I've had a /dev directory since before udev and have done a tar backup of /dev that udev has created
so it wouldn't be too hard to do away with it completely and go back to a static /dev.
The only thing I would have to do is go back to the old style xorg.conf (I think that's required if udev goes bye-bye).

That actually should be uncessary, I tested out static-/dev at one point to see it's viability (it works properly, does what it should), and not much is required to get xorg working properly.

So something seems to be happaning to poor udev, and she might be dying on us...
Fine, if it's not much, then there maybe someone of you might teach us how to do it, e.g. make a tutorial on http://en.gentoo-wiki.com/ or somewhere...
Because this frightens me sick a little. I had plans with working Gentoo, not for working on my non-booting Gentoo or such...
I haven't rebooted in some week's time yet (it's usual here, TV card is recording a lot of time), exactly for fear that I would have to spend all my skills, mental power and time into fixing a non-booting system.
That much about the state of my Gentoo.
It just might not boot. All is different now. One detail. On a reboot about a week and a day ago, I think, there was a message to the effect of:
"No /sbin/udevd" and no devices were created...
Previously, with ::udev repo udev bunch:

and I already had a few days down with the udev a month or two ago, in this thread it should be documented.
Sure, apart from my hate for SELinux and despise of too much, too much NSA's eavesdropping on the world, not only in the U.S.A... (those are definitely interrelated, but things seem to be developing into different stories slowly)...
Sure, apart from that reason, I still very much like Gentoo but with a lot of uncertainty, for the same reason.
I should go and have a nap now, but I won't for an hour more, till I see if there are any necessary corrections for me to do in regard to the extensive pasting in the post instead of in a pastebin (which wasn't possible for my Tor browser).
EDIT: Bump. Thu 27 Dec 04:20:18 CET 2012

Wait, what? A web browser, which is by definition pure user application, requires an exact implementation of one of the core system components? Huh...

try hacking the ebuild to remove the udev dependency. observe smoke and fire if udev is not installed (presumably eudev or your fork would fulfill the requirements)

genstorm wrote:

List of rebuilds after udev -> eudev update:

not too terrible. Course I a)don't use/have consolekit, b)have been udev-free long enough I'm going to have to figure out a valid excuse to try it again (any udev, be it eudev or otherwise). Maybe a new box.