LinuxQuestions.org - [SOLVED] Is disabling udev in slackware 14.0 an easy task?

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Is disabling udev in slackware 14.0 an easy task? (https://www.linuxquestions.org/questions/slackware-14/is-disabling-udev-in-slackware-14-0-an-easy-task-4175480387/)

Is disabling udev in slackware 14.0 an easy task?

Hi:
In my machine I run Slackware 14.0. I would like to dispense with udev and go back to devfs and the devices being statically managed. In the ANNOUNCE.14_0 file of Slackware 14.0, it says:

Quote:

These desktops utilize udev, udisks, and udisks2, and many of the
specifications from freedesktop.org which allow the system administrator
to grant use of various hardware devices according to users' group
membership so that they will be able to use items such as USB flash
sticks, USB cameras that appear like USB storage, portable hard drives,
CD and DVD media, MP3 players, and more, all without requiring sudo, the
mount or umount command. Just plug and play. Slackware's desktop
should be suitable for any level of Linux experience.

I'm the only user and if the only price I'd pay is, according to the quote, to put the mount command path into the user's PATH variable and issue a 'sudo mount /dev/xxx' the few times I use my flash stick, I would gladly go back to the old system. There would remain the thing of mounting and dismounting optical disks, but this is a very little burden that I had already got used to. I know before hand that there will come the inevitable question "Why do you want to do such a thing?", therefor I'm trying to answer it at this point. To make the answer complete, I should say that the use of udev has added some complications I would gladly dispense with.

I will sacrifice my DOS/Windows partition and use it to install a second instance of slackware 14.0, so I may experiment without risk of damaging valuable data. I commented out the invocation of /etc/rc.d/rc.udev in rc.M (later on I discovered it can be run from rc.S too), but the result was of a catastrophic type. I also remember having read the following in file rc.S:

Code:

# Initialize udev to manage /dev entries and hotplugging for 3.x kernels.

# You may turn off udev by making the /etc/rc.d/rc.udev file non-executable

# or giving the "nohotplug" option at boot, but realize that if you turn off

# udev that you will have to load all the kernel modules that you need

# yourself (possibly in /etc/rc.d/rc.modules, which does not promise to list

# all of them), and make any additional device nodes that you need in the

# /dev directory.  Even USB and IEEE1394 devices will need to have the

# modules loaded by hand if udev is not used.  So use it.  :-)

By the way, I don't either wish any hotplugging capability. I remember having painstakingly written down on paper all of the entries listed by lsmod, and having made sure /etc/rc.d/rc.modules contained all of them, before making /etc/rc.d/rc.udev non-executable (this was part of a second try I did, I think).

So, the many "buts" above (code block) and my unhappy experience tell me that turning udev off may be not an easy thing to do. But that is really the contents of my question. What is my definition of ease? I reformulate: what would be the degree of knowledge I would need in order to turn udev off in a tidy way? I could also revert to some previous Slackware distribution, but that would be a rather drastic measure, I think.

You should first be familiar with the /dev directory and its layout and making devices nodes manually using mknod. Read /usr/src/Documentation/devices.txt.

Be aware e.g. that to use an USB key you'll have to create the device node yourself before mounting the key.

Good luck.

Quote:

Originally Posted by Didier Spaier (Post 5043846)

You should first be familiar with the /dev directory and its layout and making devices nodes manually using mknod. Read /usr/src/Documentation/devices.txt.

That I will do. Thanks Didier.

Re-reading you initial post I'm under the impression that what you actually want is get rid of the stuff that allows auto-mounting of devices.

If I'm correct IMO you'd better keep udev but get rid of udisk and udisks2 then. I don't now how/where the daemons are called though, so you'll have to find by yourself or ask.

I don't know if there are some settings needed for that depending on the desktop(s) you use, as I I'm a fluxbox user.

Quote:

Originally Posted by Didier Spaier (Post 5043871)

Please forgive the use of superfluous quotations, but somebody could post while I am writing. Your suggestion about disposing of udisk and udisk2 is welcome. In my attempt to get rid of some undesirable side effects that I associate with the use of udev, I'll first try your suggestion. There is perhaps some interaction between xfce 4, the desktop environment I am using at present, and udisk, udisk2, as may be inferred from the following, written by Volkerding himself (optical disk #1://ANNOUNCE.14_0):

Quote:

Slackware 14.0 brings many updates and enhancements, among which
you'll find two of the most advanced desktop environments available
today: Xfce 4.10.0, a fast and lightweight but visually appealing and
easy to use desktop environment, and KDE 4.8.5, a recent stable release
of the 4.8.x series of the award-winning KDE desktop environment.
These desktops utilize udev, udisks, and udisks2, and many of the
specifications from freedesktop.org which allow the system administrator
to grant use of various hardware devices according to users' group
membership so that they will be able to use items such as USB flash
sticks, USB cameras that appear like USB storage, portable hard drives,
CD and DVD media, MP3 players, and more, all without requiring sudo, the
mount or umount command. Just plug and play. Slackware's desktop
should be suitable for any level of Linux experience.

That, I will deal with after having properly disposed of udisk/udisk2. There is also a upower, by the way. The automount capability was in my opinion making me life difficult. However, the fundamental cause of my original wanting to dispense with udev and hotplugging is the continuous, never ending access to the hard disk, for as long as the machine is turned on. I once detected this begins at the exact moment when rc.udev is invoked in the init scripts (which starts udev). Whether this effect is due to udev alone or can be independently solved, I would not like to elucidate right now. But I'm afraid, on second thought, that disabling automount will do little for it. But disabling automount capabilities will anyways be a first step in the direction I aim at. Please forgive me if I was too verbose and thanks again for your generous help.

In my small system with less than 16MB available memory I don't use udev but I still use devtmpfs. Also I wonder why on your system udev accesses the hard disk endlessly.

Quote:

Originally Posted by guanx (Post 5043914)

In my small system with less than 16MB available memory I don't use udev but I still use devtmpfs. Also I wonder why on your system udev accesses the hard disk endlessly.

In regard to the latter, I reference you to this link, started by me because of the very same issue. In regard to the former, does that system use dynamic allocation of the nodes in /dev, or are these a set of static and fixed nodes? Put more simply, are the devices in your system static devices?

Quote:

Originally Posted by stf92 (Post 5043944)

In regard to the latter, I reference you to this link, started by me because of the very same issue.

Did you figure out with block tracing that it's udev who was accessing your harddisk?

Quote:

Originally Posted by stf92 (Post 5043944)

In regard to the former, does that system use dynamic allocation of the nodes in /dev, or are these a set of static and fixed nodes? Put more simply, are the devices in your system static devices?

Dynamic. I have a few USB things there. Either dynamic or static, devtmpfs doesn't harm. Does it?

Quote:

Did you figure out with block tracing that it's udev who was accessing your harddisk?

I can only answer your question with the following, as I do not know what "block tracing" is:

Quote:

Originally Posted by stf92 (Post 5043887)

[...]However, the fundamental cause of my original wanting to dispense with udev and hotplugging is the continuous, never ending access to the hard disk, for as long as the machine is turned on. I once detected this begins at the exact moment when rc.udev is invoked in the init scripts (which starts udev). [...]

("this begins" = "the disk begins being continously accessed").

Quote:

Dynamic. I have a few USB things there. Either dynamic or static, devtmpfs doesn't harm. Does it?

I'll assume it doesn't. If you are a slackware user or by any means know something about it, when was devtmpfs for the first time implemented in that distribution? Or even a better question: what would be the drawbacks of entirely falling back to devfs and forget even about devtmpfs?

Anyways, I must read .../Documentation/devices.txt very carefully, assuming it's written in a language more or less accessible to me first. Then proceed with the issue of dispensing with udisks, udisks2. Or maybe the other way around. The ultimate goal being to put and end to the continuous hard disk access. Any further comment on the continuous hard disk access issue I will post it in the thread referenced to in post #8. My immediate goal is to dispense with udisks, udisk2 and see what happens.

Since this thread is marked as SOLVED I won't explain further.

But one thing -- devfs no longer exists in newer kernels. You may want to resort to statically created device nodes if you don't want to use devtmpfs.

Just removing udev will not do the kob, you also need to recompile several packages that are built against udev. I don't which these are on Slackware, but on CRUX these are:
- libdevmapper
- util-linux-ng
- mesa3d
- xorg-server

Since Crux only comes with a very minimal installation there may be more packages on Slackware that are built against udev.

Quote:

Originally Posted by guanx (Post 5043982)

[...] You may want to resort to statically created device nodes if you don't want to use devtmpfs.

That was the intention stated at the beginning of the thread that is, to rely on static devices alone. Until somebody cares to convince me to the contrary, I do not see what the advantages of using dynamic devices can be in my case.

Quote:

Originally Posted by TobiSGD (Post 5043992)

I am perhaps being a bit naive, but have you seen this (it's from /etc/rc.d/rc.S, Slackware 14.0 x86_64, the distribution I am dealing with)?:

Quote:

# Initialize udev to manage /dev entries and hotplugging for 3.x kernels.
# You may turn off udev by making the /etc/rc.d/rc.udev file non-executable
# or giving the "nohotplug" option at boot, but realize that if you turn off
# udev that you will have to load all the kernel modules that you need
# yourself (possibly in /etc/rc.d/rc.modules, which does not promise to list
# all of them), and make any additional device nodes that you need in the
# /dev directory. Even USB and IEEE1394 devices will need to have the
# modules loaded by hand if udev is not used. So use it. :-)

That does not seem to imply the need to recompile any packages, TobySGD. Maybe I need to know first what "to remove udev" exactly means. rc.S only speaks about "turning off udev".

Removing udev and disabling it are basically the same, it becomes unavailable for services that are built in the way that they need it. These services will not run flawlessly anymore.

And why would the rc.S script author express himself in such terms? Could not he be Volkerding himself? Infact, I donot find any contradictions between said script and your words. Only that Volderding, should he be the author, would be forgetting to explain an important thing.