LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
LinkBack Search this Thread
Old 10-11-2013, 02:16 AM   #1
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 2,903

Rep: Reputation: 45
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.

Last edited by stf92; 10-11-2013 at 08:38 AM.
 
Old 10-11-2013, 02:39 AM   #2
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware-14.0 on a Lenovo T61 6457-4XG
Posts: 3,642

Rep: Reputation: 827Reputation: 827Reputation: 827Reputation: 827Reputation: 827Reputation: 827Reputation: 827
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.

Last edited by Didier Spaier; 10-11-2013 at 02:42 AM.
 
1 members found this post helpful.
Old 10-11-2013, 02:47 AM   #3
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 2,903

Original Poster
Rep: Reputation: 45
Quote:
Originally Posted by Didier Spaier View Post
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.
 
Old 10-11-2013, 03:24 AM   #4
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware-14.0 on a Lenovo T61 6457-4XG
Posts: 3,642

Rep: Reputation: 827Reputation: 827Reputation: 827Reputation: 827Reputation: 827Reputation: 827Reputation: 827
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.
 
Old 10-11-2013, 04:01 AM   #5
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 2,903

Original Poster
Rep: Reputation: 45
Quote:
Originally Posted by Didier Spaier View Post
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.
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.
 
Old 10-11-2013, 05:40 AM   #6
guanx
Senior Member
 
Registered: Dec 2008
Posts: 1,014

Rep: Reputation: 145Reputation: 145
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.
 
Old 10-11-2013, 07:19 AM   #7
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 2,903

Original Poster
Rep: Reputation: 45
Quote:
Originally Posted by guanx View Post
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?
 
Old 10-11-2013, 07:24 AM   #8
guanx
Senior Member
 
Registered: Dec 2008
Posts: 1,014

Rep: Reputation: 145Reputation: 145
Quote:
Originally Posted by stf92 View Post
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 View Post
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?
 
Old 10-11-2013, 08:21 AM   #9
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 2,903

Original Poster
Rep: Reputation: 45
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 View Post
[...]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.
 
Old 10-11-2013, 08:49 AM   #10
guanx
Senior Member
 
Registered: Dec 2008
Posts: 1,014

Rep: Reputation: 145Reputation: 145
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.
 
Old 10-11-2013, 08:58 AM   #11
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Slackware
Posts: 14,868
Blog Entries: 2

Rep: Reputation: 3804Reputation: 3804Reputation: 3804Reputation: 3804Reputation: 3804Reputation: 3804Reputation: 3804Reputation: 3804Reputation: 3804Reputation: 3804Reputation: 3804
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.
 
Old 10-11-2013, 09:01 AM   #12
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 2,903

Original Poster
Rep: Reputation: 45
Quote:
Originally Posted by guanx View Post
[...] 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.
 
Old 10-11-2013, 09:18 AM   #13
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 2,903

Original Poster
Rep: Reputation: 45
Talking

Quote:
Originally Posted by TobiSGD View Post
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.
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".

Last edited by stf92; 10-11-2013 at 09:36 AM.
 
Old 10-11-2013, 10:43 AM   #14
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Slackware
Posts: 14,868
Blog Entries: 2

Rep: Reputation: 3804Reputation: 3804Reputation: 3804Reputation: 3804Reputation: 3804Reputation: 3804Reputation: 3804Reputation: 3804Reputation: 3804Reputation: 3804Reputation: 3804
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.
 
Old 10-11-2013, 10:54 AM   #15
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 2,903

Original Poster
Rep: Reputation: 45
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.

Last edited by stf92; 10-11-2013 at 10:57 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Zenwalk 6.4 udev rules for disabling touchpad when usb mouse is plugged ?? hottdogg Zenwalk 0 11-21-2010 08:10 AM
Fedora Core 6 won't start after updates installed - Starting udev: Disabling IRQ #16 Martin01234 Linux - Newbie 3 01-11-2008 06:24 PM
udev: disabling IRQ #20 (or #21) damber Linux - Desktop 0 03-01-2007 09:37 AM
slackware-current, udev 0.96, and custom udev rules not working rignes Slackware 6 08-10-2006 03:43 AM
Slackware - slow on multi task intmail Slackware 7 08-04-2005 08:09 AM


All times are GMT -5. The time now is 11:09 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration