Today I installed Gentoo on my main computer, just the bare minimal installation, from the AMD64 minimal install 20130418 iso. If it's relevant, the computer has a Tyan k8we server board, dual opteron 256 cpus, 12 GB ram (basically it's the Ars Technica god box from June 2005: http://arstechnica.com/gadgets/2005/06/system-guide-200506/4/, but without the ultra-expensive-at-the-time dual-sli graphics cards, and using an old creative SB sound card).

then edit the file there and change the lines as necessary. Which sounds simple, but alas there are no files under /etc/udev/rules.d and also no files under /usr/lib/udev/rules.d; in fact, there is no folder named "udev" under /usr/lib.

The thing is, I didn't want to install udev or systemd at all, under the assumption that anything I can do with udev, I can do with xorg.conf plus pmount/su'ing to root to mount/dismount the occasional usb key/external hard drive. I'm not sure how udev got installed in the first place, as I added the USE flags "-udev" and "-systemd" to my make.conf:

Code:

# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /usr/share/portage/config/make.conf.example for a more
# detailed example.
CFLAGS="-O2 -march=native -pipe"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j4"
# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult http://www.gentoo.org/doc/en/change-chost.xml before changing.
CHOST="x86_64-pc-linux-gnu"
# These are the USE flags that were used in addition to what is provided by the
# profile used for building.

It's a little more involved than just evdev support for X and USB stick mounting. Basically, you need something to set up the device tree or else you can set up static devices like the good old days () if you like. However, a Handbook install gives you a udev system.

virtual/dev-manager is in the @system set (i.e., it's practically unavoidable) and can be satisfied by one of:

virtual/udev. It's listed first so that's what you get if you don't explicitly do something else. This, in turn, can be satisfied by one of:

sys-fs/udev

sys-apps/systemd

sys-fs/eudev

all with lots of USE flag and version constraints.

sys-apps/busybox[mdev]

sys-fs/devfsd

sys-fs/static-dev

sys-freebsd/freebsd-sbin

You can look at the virtuals yourself if you like in /usr/portage/virtual.

- John_________________I can confirm that I have received between 0 and 999 National Security Letters.

Okay, good. Saves some troubleshooting, although I don't really understand the causality. As you've probably garnered by now, you have the new "predictable network names" from the newest udev. The Handbook hasn't caught up yet, so there's some confusion.

- John_________________I can confirm that I have received between 0 and 999 National Security Letters.

I reinstalled Gentoo from scratch (it was the easiest way to recover from having unmerged pam and acl without having properly dealt with "new use") and as before did not have network access. So I created the file "/etc/udev/rules.d/80-net-name-slot.rules" with contents "#dummy file" (just so it wasn't an empty file, not sure if any content is needed). When I restarted the computer, I had network access. This is also what I did the first time around to restore network access, in addition to removing the "-udev" flag which didn't do anything anyway, it seems.

Having or not having "/etc/udev/rules.d/80-net-name-slot.rules" seems to be the key, perhaps something about it might be added to the handbook?

There are a lot of threads on the Gentoo forums about udev, some of which make it sound like udev is perhaps to be avoided. Upon reading John's very kind presentation of the alternatives, I realized I didn't know enough about udev to make any decision about whether to use it or not. So I did some research. Here's what I found out:

Linux needs (among other things) a device manager and an "init" process. udev is a device manager. Device managers inform the Linux OS about which devices are attached to the machine. Devices include:

"init (short for initialization) is a daemon process that is the direct or indirect ancestor of all other processes. . . Init is the first process started during booting, and is typically assigned PID number 1. It is started by the kernel using a hard-coded filename, and if the kernel is unable to start it, a kernel panic will result. Init continues running until the system is shut down."

systemd is an init process that has been recently adopted by several major Linux distributions. At one time udev and systemd were separate programs. But in April 2012 they were merged into one.

By default Gentoo uses udev-200 (1.97?) as the device manager and OpenRC+sysvinit as the init process; systemd is an alternative: http://wiki.gentoo.org/wiki/Comparison_of_init_systems. As John kindly advised, Gentoo offers several options for device managers besides the default udev. I checked out the alternatives:

*freebsd-sbin requires a bunch of packages be installed first. I suspect it also has a steep learning curve for people like myself who aren't familiar with the freebsd way of doing things.

*static-dev is the "old" way of doing things. I suspect that to set static-dev up properly would require a deeper knowledge of linux than I have time/energy to acquire.

*eudev is a fork of udev. eudev removes all the systemd code. Gentoo's udev-200 also seems to be stripped of systemd functionality (the systemd code is still there, but it's disabled?), as systemd can be installed in place of udev. So I'm not sure what the practical difference between Gentoo's udev and eudev really is. Several forum threads discuss cases where /usr isn't mounted on root. For the mythical typical desktop gentoo, usr probably is mounted on root. So perhaps for these users (of which I am one), the eudev/udev discussion has no immediate practical significance. The other hot forum topic is device naming. The latest udev gives each device it's own unique (and odd) name, ostensibly so that the user doesn't ever face a situation where sdf and sdg, or eth0 and eth1, etc, suddenly change places. One practical consequence is that stuff that used to work (eg networking) might not work until "something is done to make it work" (eg put in a dummy file to restore the old network-device behavior for those of us who never had problems with the "old" way and don't want to take all the required steps to, and/or learn how to, enable the "new udev" way).

Probably for Gentoo newbies like myself, udev is the easier and perhaps device manager to use. Any comments/clarifications/corrections are very welcome.

Frankly Gentoo is a lot of work and I might not have gotten around to installing it on my main computer, which *was* running openSUSE. Except after I installed Gnome3 on openSUSE (for test purposes, in connection with a side project) and then uninstalled it, upon rebooting openSuse insisted that I didn't have the right password. All system rescue/password recovery efforts ended with pam/authentication issues. So I nuked openSUSE.

I'm not looking for a can of worms. I'm looking for the best, most trouble-free way of getting my main computer back up and running. For a long time I've wanted a kit-free system, without pam and without selinux. Gentoo seems to be the only major Linux distribution that allows this to happen. In my ignorance it seemed to me that udev was somehow connected with the "kit"/pam/selinux/etc stuff that I'm trying to keep off my computer, having cordially hated all of it since it started cluttering up my process list. But it turns out that udev is actually a device manager, without one of which things don't work at all. Gentoo seems to be a learning process.

My main computer is old hardware. Things build not much quicker than on my laptop. So I'm trying to get things right the first time around. I've done my level best to get a basic understanding of what device managers/init processes do. Right now I'm using the default udev+OpenRC+sysvinit. I haven't installed X yet, so if I'm going to switch to something else, now's the time to do so. (At this point I begin to feel silly even having asked the question, so I will press onward to the next steps of installing Gentoo.)

Paul, thanks! I didn't know there was a kitless alternative to Gentoo. But I really like Gentoo. The udev/eudev/etc stuff was confusing, so I'm moving on to something less confusing. Yesterday I upgraded gcc to 4.7 and watched some interesting warnings flash by. Today I discovered the portage summary.log, so now I can track down the warnings and try to understand them. In the process I just discovered why the "terminal history of commands" keeps disappearing and how to restore it. Gentoo is amazing.

A few posts ago, that was a pretty remarkable demonstration of ability to absorb and summarize complex minutia. Just a couple of minor conceptual corrections for you:

ElleStone wrote:

Device managers inform the Linux OS about which devices are attached to the machine.

Actually, it's kind of the other way around. The device manager creates special device node files in /dev in response to kernel generated events under control of a set of udev rules. So, really, the device manager informs the rest of the system about the available devices. The other thing the device manager does for some devices (also under rule control) is load necessary firmware into the device. This keeps things that can be accomplished in userspace out of the kernel.

ElleStone wrote:

Gentoo's udev-200 also seems to be stripped of systemd functionality (the systemd code is still there, but it's disabled?)

They're still mostly independent. Although the udev code base has been made part of the systemd project, it's still possible to build udev independent of systemd. The Gentoo udev ebuild actually unpacks the systemd tarball but builds only udev. To my knowledge, except for minor patches, the udev source code is used as-is.Hope this helps.

- John_________________I can confirm that I have received between 0 and 999 National Security Letters.

Frankly Gentoo is a lot of work and I might not have gotten around to installing it on my main computer

ElleStone ... I don't think that is the case, yes, there is a learning curve, but a good part of the time invested is recouped if re-install/re-configure time is considered (ie, with distributions which will *need* to be reinstalled every one/two years). I recently installed kbuntu on a friends laptop, it took no time at all, but having run the software update various things were broken (including font rendering) it took longer to fix these issues than it would have taken (me) to install gentoo, the only reason I didn't is that the owner has no clue about computers at all (the machine was previously running windows and virus infested). So, yes, it takes some time to understand how gentoo works but that work is repaid in various ways, not least of which is the greater understanding acquired as to how an OS actually works (as there is greater transparency in this regard).

ElleStone wrote:

I'm not looking for a can of worms. I'm looking for the best, most trouble-free way of getting my main computer back up and running.

Of course, but the subject matter is such a "can". I wasn't saying that asking such a question was futile, but merely that it may prompt a storm of "comments" that may not help. The point being that there is a variety of opinions as to what is "the best", and a wider context to the question (some of which are unrelated to your particular problem). As a veteran of such discussions I thought I'd insert a touch of joviality at the offset, because quite frankly its often needed.

ElleStone wrote:

For a long time I've wanted a kit-free system, without pam and without selinux. Gentoo seems to be the only major Linux distribution that allows this to happen. In my ignorance it seemed to me that udev was somehow connected with the "kit"/pam/selinux/etc stuff that I'm trying to keep off my computer, having cordially hated all of it since it started cluttering up my process list. But it turns out that udev is actually a device manager, without one of which things don't work at all. Gentoo seems to be a learning process.

A system can function without udev (or eudev for that matter) as there are other methods that could be employed (such as mdev) but this may require more work as udev has become ubiquitous, and is the defacto method of device management. So, something like xorg will require additional work to setup if udev is not in use, and some applications absolutely require it and will not work with any other form of device management. Having disabled the udev useflag globally you will need to deal with these issues ... or adjust your useflags to be more selective. In my case the only thing that requires eudev is xorg but I could quite easily switch to mdev as I don't require dbus, *kit, etc ... and I'm quite capable of configuring xorg by hand. Others have gone another route and still use udev-171, and some have dived headlong into systemd (which is what udev was merged with) ... if you don't like the vertical integration that is part and parcel of "the desktop" then you'll want to steer clear of dbus, *kit, systemd, systemd-udev, etc, but that doesn't mean you can't find some happy medium, but such a choice will require additional work as the level of integration makes it far more difficult to switch out one component for another.

ElleStone wrote:

So I'm trying to get things right the first time around.

Your not supposed to do this ... all of these decisions need to be made by people who know how your user experience *should* work ... your circumventing the greater plan, and are likely to be crushed as an irrelevant casualty of progress. Sheeesh ... if you want things done right then get someone else to do it ;)

ElleStone wrote:

(At this point I begin to feel silly even having asked the question, so I will press onward to the next steps of installing Gentoo.)

No, your question was perfectly legitimate ... its just that you, as a "user", are not supposed to have such concerns, your supposed to be blindly oblivious to what the OS is doing, enjoying your new-shiny, and letting the machinery of progress grind to its logical conclusion ... its all written on the box, had you taken the time to read it ;)

The device manager creates special device node files in /dev in response to kernel generated events under control of a set of udev rules. So, really, the device manager informs the rest of the system about the available devices.

John, thanks! You answered a nagging question I've had for a long time, but never figured out how to ask. Before udev came on the scene, "something", possibly hal? relentlessly polled "something else" every 15 seconds, just in case a cd, floppy, etc might have been plugged in in the intervening 15 seconds. You are saying that whatever it was that polled every 15 seconds, wasn't listening to the devices directly, but rather to the kernel? (If so, I would ask how the kernel knows when a device is plugged in, but probably the answer is long and complicated.) Does udev likewise constantly poll in case something gets plugged in? Like an automated "dmesg | tail"? (The nagging question turned out to be "where does the 'dmesg | tail' information come from?" the answer is "from the kernel"?).

Quote:

The Gentoo udev ebuild actually unpacks the systemd tarball but builds only udev. To my knowledge, except for minor patches, the udev source code is used as-is.

That clarifies the Gentoo udev a bit and explains how openSUSE yast can offer udev and systemd separately. Again, thanks!

Khayyam, I like rolling distributions, too, and I don't mind the Gentoo up-front learning curve at all as long as I can avoid Linux creeping vertical integration. It was just a bit intimidating to get started, til openSUSE obligingly made the decision easier. I'm guessing/anticipating that in the long run Gentoo will be at least as easy to maintain as any other Linux distribution.

Quote:

all of these decisions need to be made by people who know how your user experience *should* work ... your circumventing the greater plan, and are likely to be crushed as an irrelevant casualty of progress.

Methinks you speak truth. The last time I installed Windows (Vista), the user experience obviously was supposed to be "you are an idiot and your computer is really your home entertainment center". I just finished installing several "out of the box" Linuxes with complete Gnome and KDE desktops; I hadn't actually seen a default Linux desktop install in quite a few years and was kinda shocked to discover that the new Linux user experience seems to be "reach out and touch someone, and don't bother thinking because the desktop will magically hand you whatever you want." Good, bad, or indifferent, neither my brain nor my old computer can handle that much built-in "convenience".

Anyway, I installed eudev in place of udev, followed the instructions in summary.log, and restarted the computer. The only puzzling thing so far is that in regards to eudev the "summary.log" says "ERROR: setup DEVTMPFS is not set in this kernel. Udev will not run." But a quick check of .config/device drivers/generic driver options shows that "Maintain a devtmpfs filesystem etc" is checked, though the automount option isn't checked. But everything seems fine and it will be interesting to see what issues arise as I install additional packages.

Thanks! to everyone for advice and encouragement. On to the next step!

Anyway, I installed eudev in place of udev, followed the instructions in summary.log, and restarted the computer. The only puzzling thing so far is that in regards to eudev the "summary.log" says "ERROR: setup DEVTMPFS is not set in this kernel. Udev will not run." But a quick check of .config/device drivers/generic driver options shows that "Maintain a devtmpfs filesystem etc" is checked, though the automount option isn't checked. But everything seems fine and it will be interesting to see what issues arise as I install additional packages.

ElleStone ... ok, thats odd, firstly because here the CONFIG_CHECK didn't produce any errors, and secondly without DEVTMPFS you wouldn't be able to boot. I have DEVTMPFS and DEVTMPFS_MOUNT enabled which may perhaps explain it, but anyhow seems harmless.

After starting icewm (startx) and then looking at the output of htop, there is an instance of "udevd --daemon" running. I can kill it with

Quote:

rc-service udev-postmount stop
rc-service udev-mount stop

The second command elicits dire warnings about stopping a sysinit service, but nothing bad seems to happen at all.

Is there a way to keep "udevd --daemon" from starting at all? Root starts it, it's the second PID after "init". Would really bad things happen if I use "rc-service del" to remove udev-postmount and udev-mount from their respective runlevels?

Elle, very much wishing to not see udevd in her list of running processes.

Is there a way to keep "udevd --daemon" from starting at all? Root starts it, it's the second PID after "init". Would really bad things happen if I use "rc-service del" to remove udev-postmount and udev-mount from their respective runlevels?

ElleStone ... ummmm, that is eudev and unless you want to migrate to some other device management you need it.

You either need a static /dev, or one of the packages listed in virtual/dev-manager to manage /dev.
I'm playing with a static /dev just now, but since udev is the default /dev/ manager, its difficult to just rip it out.

A few things won't work, nothing major, yet ... lvm2, pciutils usbutils all seem to insist on udev.
Hmm, I have root on lvm2 on raid5 so I need to fix lvm2.

My approach so far is along the lines of a stage1 install._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

At present, starting icewm, then starting urxvt, then starting htop, there are a total of 20 processes running, including the root-owned udevd daemon.

There were a couple more default processes upon startup that I didn't want (dbus-launch and dbus-daemon). But I modified the .xinitrc file and they don't start any more. When I want to run a program that uses dbus (digikam and krita are the only programs that seem to need dbus), I wrote a little script that starts dbus-launch, and then kills dbus and everything kde-related as soon as I close the program. It seems to work just fine, but I haven't fully tested as I'm still setting things up.

Anyway, I've been killing the udevd daemon upon starting icewm routinely for the last couple of days, and everything seems to work just fine. I can mount external drives, run all my installed programs, etc. I was just looking for a way to kill the udevd daemon automatically upon running startx.

"rc-update show" shows three entries for udev: udev (sysinit), udev-mount (sysinit), and udev-postmount (default). I suspect that "rc-service udev stop" might result in an unbootable system (just a feeling). But it seems like stopping the other two might be OK. The udevd daemon in the process list isn't killed by stopping udev-postmount, only by stopping udev-mount. I don't think I can kill it from the .xinitrc script because only root can kill it.

NeddySeagoon ... honestly mdev is a shoe in, I too have lvm (on dm-crypt ... though I set this up via the initramfs) and had no issues with migration. Takes a little work as you obviously have useflag changes and need to configure xorg sans evdev, but really no issues other than those.

ElleStone, you should consider switching to mdev. The process you are killing is eudev. Its probably not harmful since /dev/ has already been populated, but its better to use software that you don't want to kill on sight. I have been using mdev for a while now it it does everything I need it to. Another advantage is that it actually decreases my boot time. mdev is fairly easy to set up._________________First things first, but not necessarily in that order.

Anyway, I've been killing the udevd daemon upon starting icewm routinely for the last couple of days, and everything seems to work just fine. I can mount external drives, run all my installed programs, etc. I was just looking for a way to kill the udevd daemon automatically upon running startx.

ElleStone ... my first question would be "why exactly?" because all you are doing is preventing further hardware detection with very little gain (udev is not doing anything that is going to effect your workflow, its just a device manager that has grown too big for its boots). That aside, you should understand what udev is doing, devices require nodes under /dev that provide a method for hardware to interface with software, these devices can be created statically (which has some drawbacks as you would then have to create the nodes with the required permissions prior to devices being connected) or via some dynamic method (often called "hotplugging"). That's all udev is doing, when a device is connected the event is registered with udev and udev creates a device node (or, as is sometimes the case, goes out for lunch). This happens in userspace, all the kernel is responsible for is the event trigger.

The issue that arises is that device nodes need to be there early in the boot process (so that mounts, etc, can have a device node, etc, etc) and so we enter the crucible of ... uuuhhhggggg ... suffice there is a history to this: there was devfs, then it was decided that device management should be in userspace (and udev was born), then it was decided that really devfs wasn't a bad idea after all, and so devtmpfs was born, and during the whole period of time userspace crept further and further up the boot process to make sure that things happen jus' right. As userspace needs to have access to the filesystem, you often need to do this before the system actually boots, so it moves into an initramfs and/or before anything else is initialised, the side effect of this is should it not work, the boot process will fail. I've simplified that a lot, but in order to save further digression I'll just skip right to the point: in your case the "udev (sysinit), udev-mount (sysinit), and udev-postmount (default)" are all there to make the magic happen, the second of the three rcscripts is there to setup /dev (now devtempfs) the third, udev-postmount, is now obsolete [edit: for systemd-udev] and a victim of some about turn, and the first rcscript is to start the udev daemon itself.

EDIT: eudev still uses udev-postmount for net device naming, and so this is required in the default runlevel

There is a wider story here but those who have lived through these dark events are too scared, wounded and traumatised to speak anything but babble ... myself included.

best ... khay

Last edited by khayyam on Mon May 13, 2013 7:43 am; edited 1 time in total