Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Got udev working, now what?!
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 26, 27, 28, 29, 30  Next  
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo
View previous topic :: View next topic  
Author Message
rndpkt
n00b
n00b


Joined: 04 Mar 2003
Posts: 59

PostPosted: Sun Jun 20, 2004 4:36 am    Post subject: Reply with quote

Hey all, I'm trying to build a new lappy from scratch with 2.6 + UDEV and I'm running into a problem where ethX devices aren't showing up. Everything WORKS just fine (i.e. ifconfig responds to eth0 and I can get on the network) but I have no /dev/eth0. I've tried creating a rule to map eth* to /dev/eth* but it seems to be completely ignored. I looked at my desktop system that's been running 2.6 + UDEV but is an old crufty Gentoo install and it doesn't have a /dev/eth0 either! Am I missing something obvious?

I have udev built in the kernel, UDEV 026-r1, hotplugging is installed and started on boot.

My /dev:
Code:
fir udev # ls -ld /dev/eth*
ls: /dev/eth*: No such file or directory


My ifconfig output:
Code:
fir udev # ifconfig
eth0      Link encap:Ethernet  HWaddr 00:06:25:18:0D:D8
          inet addr:172.16.3.50  Bcast:172.16.3.255  Mask:255.255.254.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5101 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2301 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:411891 (402.2 Kb)  TX bytes:624187 (609.5 Kb)
          Interrupt:3 Base address:0x100

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)


UDEV sees the device:
Code:
fir udev # udevinfo -a -p /sys/class/net/eth0/
  looking at class device '/sys/class/net/eth0':
    SYSFS{addr_len}="6"
    SYSFS{address}="00:06:25:18:0d:d8"
    SYSFS{broadcast}="ff:ff:ff:ff:ff:ff"
    SYSFS{features}="0x0"
    SYSFS{flags}="0x1003"
    SYSFS{ifindex}="2"
    SYSFS{iflink}="2"
    SYSFS{mtu}="1500"
    SYSFS{tx_queue_len}="1000"
    SYSFS{type}="1"


But the following rule in /etc/udev/rules.d/10-udev.rules do nothing:
Code:
KERNEL="eth*", NAME="%k"


Am I missing something really obvious? I've read this entire thread and all of the udev primer stuff at reactivated.net and I can't solve this.

EDIT: Interestingly enough, I also get this behavior:
Code:
fir rules.d # udevinfo -q all -p /sys/class/net/eth0/
device not found in database


Something odd is going on here.


Last edited by rndpkt on Sun Jun 20, 2004 4:53 am; edited 1 time in total
Back to top
View user's profile Send private message
dsd
Developer
Developer


Joined: 30 Mar 2003
Posts: 2162
Location: nr London

PostPosted: Sun Jun 20, 2004 7:39 am    Post subject: Reply with quote

since when has eth0 been a node in /dev ? it's not a character device, nor a block device...
_________________
http://dev.gentoo.org/~dsd
Back to top
View user's profile Send private message
dsd
Developer
Developer


Joined: 30 Mar 2003
Posts: 2162
Location: nr London

PostPosted: Sun Jun 20, 2004 7:44 am    Post subject: Reply with quote

decibels, a few things have changed yes. its not obvious why your rules don't work, but here;s the right way to do things now:

ensure that /etc/udev/udev.conf is pointing at the /etc/udev/rules.d directory for the rules
create your rules in a file such as /etc/udev/rules.d/10-local.rules and put your rules there, never edit the main 50-udev.rules
your rule would be best suited by a multiple-SYMLINK style rule, infact, the section I added to the page (here) yesterday includes the exact rule you need to use

after updating the rules files, run "udevstart" and see if the dvd symlink turned up.
_________________
http://dev.gentoo.org/~dsd
Back to top
View user's profile Send private message
rndpkt
n00b
n00b


Joined: 04 Mar 2003
Posts: 59

PostPosted: Sun Jun 20, 2004 12:30 pm    Post subject: Reply with quote

dsd wrote:
since when has eth0 been a node in /dev ? it's not a character device, nor a block device...


Wow.. you're right... I've used Linux for years and never gave that a second thought until I was trying to do udev renaming on the device.... Boy I feel stupid now... :oops:
Back to top
View user's profile Send private message
Decibels
Veteran
Veteran


Joined: 16 Aug 2002
Posts: 1623
Location: U.S.A.

PostPosted: Sun Jun 20, 2004 2:35 pm    Post subject: Reply with quote

dsd wrote:
decibels, a few things have changed yes. its not obvious why your rules don't work, but here;s the right way to do things now:

ensure that /etc/udev/udev.conf is pointing at the /etc/udev/rules.d directory for the rules
Yes, it is.

dsd wrote:
create your rules in a file such as /etc/udev/rules.d/10-local.rules and put your rules there, never edit the main 50-udev.rules
your rule would be best suited by a multiple-SYMLINK style rule, infact, the section I added to the page (here) yesterday includes the exact rule you need to use

after updating the rules files, run "udevstart" and see if the dvd symlink turned up.


Okay, created the 10-local.rules file in /etc/udev/rules.d .
Added to it:
Code:
# cdrom/dvd devices
KERNEL="hdc", SYMLINK="dvd"

Ran 'udevstart', Bam created Symlink: /dev/dvd !!

Thanks a bunch!

ASIDE: Okay, we have 50-udev.rules in (/etc/udev/rules.d)[EDIT] which are the default rules. See that you can place some local rules of your own creation in there also to override default rules (10-local.rules). What has become of /etc/udev/udev.rules and what is it's function? (a temp location to place local rules until udev started reading the local rules (ie 10-local.rules).
They are similar except for the addition of these in 50-udev.rules:
Code:
BUS="usb", KERNEL="lp[0-9]*",   NAME="usb/%k"

# CAPI devices
KERNEL="capi", NAME="capi20", SYMLINK="isdn/capi20"
KERNEL="capi*", NAME="capi/%n"

# Network devices
KERNEL="tun", NAME="net/%k"

# raw devices

KERNEL="raw[0-9]*",  NAME="raw/%k"


Looks like based on some of your writings that /etc/udev/udev.rules may be replaced by the default 50-udev.rules and by your own rules in a seperate file in same folder (ie. /etc/udev/rules.d). At least that is the way I am reading it.
_________________
Support bacteria – they’re the only culture some people have.”

– Steven Wright


Last edited by Decibels on Sun Jun 20, 2004 4:46 pm; edited 3 times in total
Back to top
View user's profile Send private message
dsd
Developer
Developer


Joined: 30 Mar 2003
Posts: 2162
Location: nr London

PostPosted: Sun Jun 20, 2004 4:33 pm    Post subject: Reply with quote

Decibels wrote:
ASIDE: Okay, we have 50-udev.rules in (/etc/udev/udev.d) which are the default rules. See that you can place some local rules of your own creation in there also to override default rules (10-local.rules).


you mean /etc/udev/rules.d - and yes, thats right. you can actually place as many rules files in that directory as you want. but if you want to override the udev defaults, then your file must be parsed _before_ 50-udev.rules (this is easily achieved by starting your file with a 2-digit number less than 50).

Quote:
What has become of /etc/udev/udev.rules and what is it's function? (a temp location to place local rules until udev started reading the local rules (ie 10-local.rules).


/etc/udev/udev.rules has no use now. you can safely delete it (this does not happen automatically due to config file protection). the new way of managing rules is as i described above (files in rules.d)
_________________
http://dev.gentoo.org/~dsd
Back to top
View user's profile Send private message
Decibels
Veteran
Veteran


Joined: 16 Aug 2002
Posts: 1623
Location: U.S.A.

PostPosted: Sun Jun 20, 2004 4:43 pm    Post subject: Reply with quote

Looking thru the thread and seems still haven't found a reason why /dev/mixer isn't being created.

Watching bootup, Alsa restores mixer settings fine, sound works great. But some progs want a /dev/mixer (even with alsa), for example aumix.

Notice in /etc/init.d/aumix :
Code:
"/dev/mixer does not exist, please create it, or load the correct modules to enable your card's mixer"

That is what pops up during boot, AFTER udev and alsa restores mixer settings and module deps are calculated.

Looking further in kernel, see that have CONFIG_SND_MIXER_OSS=m . And it is in /etc/modules.d/alsa to alias snd-mixer-oss. Going to add snd-mixer-oss to load at boot, thought it should have done that to start with (my booboo).

LATER: Added snd_mixer_oss, snd_seq_oss, snd_pcm_oss to load. Udev starts and calculate module deps fine, still get the /dev/mixer error when init runs aumix from default (not boot). Looks like udev hasn't finished creating all the devices so /dev/mixer isn't there yet by the time it reaches that init script.
Guess really don't need it (aumix) to load at default level anyway since have alsamixer set. So just removed it from default runlevel.
snd_pcm_oss also loads snd_mixer_oss, so you get /dev/dsp and /dev/mixer .
snd_seq_oss gives you /dev/midi .

DSD Thanks. Fixed my typo's. Going to delete that file to avoid confusion in the future and put a note in the Primer.
_________________
Support bacteria – they’re the only culture some people have.”

– Steven Wright
Back to top
View user's profile Send private message
mr.twemlow
Tux's lil' helper
Tux's lil' helper


Joined: 12 Nov 2003
Posts: 90
Location: Illinois

PostPosted: Mon Jun 21, 2004 2:49 pm    Post subject: Reply with quote

Right,

I've made the switch over to udev pretty easily (thanks for the primer, Decibels). Everything seemed to work fine when I switched. Sound works and the nvidia module loads fine, and creates the devices.

But when I go to start X all I get is a blank screen. The logs seem to say that it's starting fine, but the monitor just stays black and the keyboard is locked. The system still runs fine, because I can punch the power and it shuts down, but I can't see anything again until I reboot.

I updated my bootsplash at the same time as udev, but I don't think that would do it...

Any clues?
_________________
Get Gentoo icons: http://boxturtleme.2ya.com/gentoo-icons.xml

Gentium--A typeface for the nations: https://forums.gentoo.org/viewtopic.php?p=1351563
Back to top
View user's profile Send private message
nesl247
Veteran
Veteran


Joined: 15 Jun 2004
Posts: 1614
Location: Florida

PostPosted: Mon Jun 21, 2004 3:18 pm    Post subject: Reply with quote

Has it been said already but there is a guide in the gentoo documentation.. It works without any mknod and mounting /sys in fstab and stuff.. Anyways just wanted to tell you if you didnt know.. Wasnt going to read 27 pages to find out.
Back to top
View user's profile Send private message
dsd
Developer
Developer


Joined: 30 Mar 2003
Posts: 2162
Location: nr London

PostPosted: Mon Jun 21, 2004 3:43 pm    Post subject: Reply with quote

mr.twemlow: your problems sound unrelated to udev. i always suggest that people make the transition in two stages - 1. reconfigure kernel, check it works, etc. 2. install udev + disable devfs

it sounds like you have got 4k stacks enabled in your kernel, this breaks nvidia
_________________
http://dev.gentoo.org/~dsd
Back to top
View user's profile Send private message
mr.twemlow
Tux's lil' helper
Tux's lil' helper


Joined: 12 Nov 2003
Posts: 90
Location: Illinois

PostPosted: Mon Jun 21, 2004 6:06 pm    Post subject: Just got a little frantic Reply with quote

Yeah, you're right. It's probably nothing to do with udev. Using the nv driver in xorg.conf works fine, so I'll just hunt around until I make the silly thing work.

Sorry, just got a little frantic.
_________________
Get Gentoo icons: http://boxturtleme.2ya.com/gentoo-icons.xml

Gentium--A typeface for the nations: https://forums.gentoo.org/viewtopic.php?p=1351563
Back to top
View user's profile Send private message
Decibels
Veteran
Veteran


Joined: 16 Aug 2002
Posts: 1623
Location: U.S.A.

PostPosted: Wed Jun 23, 2004 1:46 am    Post subject: Reply with quote

DSD, have you seen any progress on the timing issue with creation of nvidia devices and X . Had 'udevstart' added to my local.start file and hadn't thought about it for awhile. Took it out the other day and worked a few times, then other times not, so the time issue seems very small. But still seems that the nvidia devices aren't being created fast enough most of the time.

Went ahead and put 'udevstart' back in local.start for now. :(
_________________
Support bacteria – they’re the only culture some people have.”

– Steven Wright
Back to top
View user's profile Send private message
dsd
Developer
Developer


Joined: 30 Mar 2003
Posts: 2162
Location: nr London

PostPosted: Wed Jun 23, 2004 8:46 am    Post subject: Reply with quote

as nvidia advise, you just need to autoload the module. this will give it enough time to create the nodes before you are able to start x. i dont see why udevstart in local.start helps, as we effectively do just this in the init scripts..
_________________
http://dev.gentoo.org/~dsd
Back to top
View user's profile Send private message
Decibels
Veteran
Veteran


Joined: 16 Aug 2002
Posts: 1623
Location: U.S.A.

PostPosted: Wed Jun 23, 2004 10:46 am    Post subject: Reply with quote

Wish I could say it is so, but X isn't starting everytime if don't have 'udevstart' in local.start. Will need to look in the XFree86.log when get home and try it again. Assume it is that nvidia nodes aren't there yet.

More than likely it is just timing. Udevstart is probably not creating anything 'new', it is just causing a slight delay by running and local.start is just before X starts. Probably putting a sleep for a sec or two will cause the same results. Will try and pin down more today.
You have to remember that, just like I forgot had the 'udevstart' in local.start, lot of people probably have mknod for nvidia devices still in there also and have just forgot about it.

Quote:
as nvidia advise, you just need to autoload the module.

That issue was beat to death a while back, look back in the notes, I have always loaded nvidia module during boot.
But thanks for asking. :)
_________________
Support bacteria – they’re the only culture some people have.”

– Steven Wright
Back to top
View user's profile Send private message
dsd
Developer
Developer


Joined: 30 Mar 2003
Posts: 2162
Location: nr London

PostPosted: Wed Jun 23, 2004 11:15 am    Post subject: Reply with quote

do you have XDM or something? that might be starting X too early... i assumed you would start it manually with startx or similar.

also, all of the sysfs issues are resolved in nvidia-kernel-1.0.5336-r4 so people should not have to mknod anything any more.
_________________
http://dev.gentoo.org/~dsd
Back to top
View user's profile Send private message
Decibels
Veteran
Veteran


Joined: 16 Aug 2002
Posts: 1623
Location: U.S.A.

PostPosted: Wed Jun 23, 2004 1:45 pm    Post subject: Reply with quote

dsd wrote:
do you have XDM or something? that might be starting X too early... i assumed you would start it manually with startx or similar.

also, all of the sysfs issues are resolved in nvidia-kernel-1.0.5336-r4 so people should not have to mknod anything any more.

No, using kdm (xdm is set in default, but you have to do that to get kdm to run). Yes, even though it fails you can login and startx and X starts up fine.

Ran some tests and it is a timing issue and it wasn't resolved by emerging nvidia-kernel-1.0.5336-r4. I had the r3 version previous and for the first few test, but the results were the same for both.

Test
1) removed udevstart from local.start .
Results: X doesn't start. XFree86.0.log shows:
Code:
(EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module!
(EE) NVIDIA(0):  *** Aborting ***
(II) UnloadModule: "nvidia"
(II) UnloadModule: "vgahw"
(II) Unloading /usr/X11R6/lib/modules/libvgahw.a
(EE) Screen(s) found, but none have a usable configuration.

2) Reboot and same results.
3) Left udevstart out of local.start, but added sleep 3. X starts right up. Reboot and X starts up again.
4) Emerged nvidia-kernel-1.0.5336-r4. Removed sleep 3. Rebooted and X doesn't start. Reboot and X starts up, Reboot 3rd time and X doesn't start.
Results of log are the same as test #1.
5) Put sleep 1 in local.start.
1st reboot -- no X.
Change to sleep 2, reboot -- no X.
Change to sleep 3, reboot twice -- X starts up both times.

Sleep 3 works on my system, but also have a few other items in local.start, if removed them might have to increase the time. But this sure still looks like a timing issue, maybe not with udev, but with nvidia. Noticed it doesn't say that nvidia nodes not found, just failed to initialize.
_________________
Support bacteria – they’re the only culture some people have.”

– Steven Wright
Back to top
View user's profile Send private message
Decibels
Veteran
Veteran


Joined: 16 Aug 2002
Posts: 1623
Location: U.S.A.

PostPosted: Thu Jul 01, 2004 1:28 am    Post subject: Reply with quote

Just wrote a neat little python script called udevread.py to read all the nodes in /dev, then call udevinfo to get the information for them. Broke it down to block, character, pipe, symlinks, folders, sockets. Really only the block and character devices are of any useful information. But nice to see all of it laid out. Newest version added capability to search for just one device.

To see what output looks for --all: http://webpages.charter.net/decibelshelp/udevread.html

To get file 'udevread.py' from snippets section of Primer link: http://webpages.charter.net/decibelshelp/udevread-0.3.tar

To run: python udevread.py --all
To get /sys info for all devices

or

python udevread.py --dev input/mouse0
or
python udevread.py --dev /input/mouse0
or
python udevread.py --dev /dev/input/mouse0

To get /sys info for just that device


Of course you can chmod to make it executable and run
./udevready.py --dev input/mice

example single device output:
Code:
bash-2.05b$ python udevprint.py --dev /dev/dvd
************ DEVICE NODE *************
-----------------------------
/dev/dvd
P: /block/hdc
N: hdc
T: b
M: 060660
S: dvd cdrom ide/host0/bus1/target0/lun0/cd cdroms/cdrom0
O: root
G: disk
F: /etc/udev/rules.d/50-udev.rules
L: 17
U: 9761

 Examining /sys for information on Device
looking at class device '/sys/block/hdc':
SYSFS{dev}="22:0"
SYSFS{range}="1"
SYSFS{size}="8388604"
SYSFS{stat}="       0        0        0        0        0        0        0        0        0        0        0"

follow the class device's "device"
looking at the device chain at '/sys/devices/pci0000:00/0000:00:07.1/ide1/1.0':
BUS="ide"
ID="1.0"
SYSFS{detach_state}="0"

looking at the device chain at '/sys/devices/pci0000:00/0000:00:07.1/ide1':
BUS=""
ID="ide1"
SYSFS{detach_state}="0"

looking at the device chain at '/sys/devices/pci0000:00/0000:00:07.1':
BUS="pci"
ID="0000:00:07.1"
SYSFS{class}="0x01018a"
SYSFS{detach_state}="0"
SYSFS{device}="0x0571"
SYSFS{irq}="0"
SYSFS{subsystem_device}="0x0571"
SYSFS{subsystem_vendor}="0x1106"
SYSFS{vendor}="0x1106"

looking at the device chain at '/sys/devices/pci0000:00':
BUS=""
ID="pci0000:00"
SYSFS{detach_state}="0"

-----------------------------
*********** END DEVICE NODE ***********

_________________
Support bacteria – they’re the only culture some people have.”

– Steven Wright


Last edited by Decibels on Tue Jul 06, 2004 12:30 am; edited 3 times in total
Back to top
View user's profile Send private message
dweigert
Guru
Guru


Joined: 04 Oct 2002
Posts: 369
Location: Somerset, NJ USA

PostPosted: Sat Jul 03, 2004 8:17 pm    Post subject: Reply with quote

Just a quick note... udev-029 segfaults on AMD64 processors running 64 bit Gentoo. udevstart fails, thus preventing they system from coming up cleanly.

Dan
_________________
"Always remember to mount a scratch monkey..."
Back to top
View user's profile Send private message
semiSfear
Guru
Guru


Joined: 08 Jul 2003
Posts: 302
Location: Adelaide, SA

PostPosted: Sun Jul 04, 2004 2:50 pm    Post subject: Reply with quote

I have another issue that hasn't been brought up yet. I'v been searching for it in the forums without luck.

If you got RTC Clock enabled in your kernel, the device node can not be used by a normal user. I use it to speed up permormance in mplayer thru /etc/sysctl.conf

Anyway. When I start mplayer I get an error saying RTC device can not be read bt normal user. So I changed that in my udev.permissions from 0660 to 0664. Still this doesn't help. Everytime I reboot the permissions are still 0660 on the device. Anyone know how to resolve this?

I have also a security related question. There have been reported bugs that normal users can't use SSH with udev because of permissions. There is a really easy fix for this which involves the same work-around as with the permissions on /dev/nvidia*. How do these changes in udev.permissions reflect on the security on my system? For example setting 0666 permissions on my /dev/nvidia* makes the device read and writable by all users. Isn't this a potential security breach? Same thing goes for tty devices (read above about the ssh bug).
_________________
DnB is my religion, Jungle is my church.
Back to top
View user's profile Send private message
Jakub
Guru
Guru


Joined: 04 Oct 2003
Posts: 377
Location: Warsaw, Poland

PostPosted: Thu Jul 08, 2004 12:11 am    Post subject: Reply with quote

Hi, I'm running a pure udev system (udev-029 and hotplug-20040401). I have a problem with permissions set on my:
a) cdrw (/dev/hda, there's a symlink to it: /dev/cdroms/cdrom0)
b) cdrom (/dev/hdd, and a symlink to it: /dev/cdroms/cdrom1).

Well, I would like the permissions for those devices to be:
a) root:cdrw
b) root:cdrom
respectively, but how can I achieve that?

The hdX devices have permissions root:disk (set in /etc/udev/permissions.d/50-udev.permissions):
Code:

hd*:root:disk:660

which wouldn't be a problem, since the important files are the simlinks in /dev/cdroms. However, the symlinks
Code:

/dev/cdroms/cdrom0
/dev/cdroms/cdrom1

have permissions root:root, even though I have this line in /etc/udev/permissions.d/50-udev.permissions:
Code:

cdroms/*:root:cdrom:0660
.

Thanks in advance for any help.

PS. I have erased the contents of /etc/security/console.perms.
Back to top
View user's profile Send private message
asimon
l33t
l33t


Joined: 27 Jun 2002
Posts: 979
Location: Germany, Old Europe

PostPosted: Thu Jul 08, 2004 12:28 am    Post subject: Reply with quote

semiSfear wrote:
For example setting 0666 permissions on my /dev/nvidia* makes the device read and writable by all users. Isn't this a potential security breach?

Because I don't want to have the nvidia devices world writable I set their permission not via udev.permission but in /etc/security/console.perms. I think this is the best solution, then they are only writable by the user on the console and nobody else.
Back to top
View user's profile Send private message
Decibels
Veteran
Veteran


Joined: 16 Aug 2002
Posts: 1623
Location: U.S.A.

PostPosted: Thu Jul 08, 2004 11:08 am    Post subject: Reply with quote

I've not had any permissions problems, but it is irritating that 50-udev.permissions doesn't seem to do anything. Even after removing console.perms and even after rebooting or logging out.

I was playing with my cdroms to see if could get anywhere with your problem and couldn't change the group.

Seems that sometimes people are able to do something with permissions, but would suspect that there are other devices that doing the same thing on wouldn't produce the same results. In other words, seems to be a hit and miss.
_________________
Support bacteria – they’re the only culture some people have.”

– Steven Wright
Back to top
View user's profile Send private message
Jakub
Guru
Guru


Joined: 04 Oct 2003
Posts: 377
Location: Warsaw, Poland

PostPosted: Thu Jul 08, 2004 1:00 pm    Post subject: Reply with quote

Thank you very much for your reply.

Well, I've just read somewhere that symlinks don't have permissions and (the way that I understand it) they should reflect the permissions of the file that they are pointing to. If that is the case, how come
Code:

romek@mymachine romek $ ls -l /dev/cdroms/
total 0
lrwxrwxrwx  1 root root 6 Jul  8 14:46 cdrom0 -> ../hda
lrwxrwxrwx  1 root root 6 Jul  8 14:46 cdrom1 -> ../hdd

and
Code:

romek@mymachine romek $ ls -l /dev/hd*
brw-rw----  1 root disk  3,  0 Jul  8 14:46 /dev/hda
...
brw-rw----  1 root disk 22, 64 Jul  8 14:46 /dev/hdd
...

?

Is ls -l the right way to check permissions? What is even more bizarre, I've checked them in midnight commander and they showed up as root:disk (for /dev/cdroms/cdrom0 and /dev/cdroms/cdrom0), not root:root.

EDIT: What I actually meant was setting the owner and group of a symlink, not the permissions as such.
Back to top
View user's profile Send private message
asimon
l33t
l33t


Joined: 27 Jun 2002
Posts: 979
Location: Germany, Old Europe

PostPosted: Thu Jul 08, 2004 1:15 pm    Post subject: Reply with quote

links have permissions and they're always rwxrwxrwx. But they actually don't matter at all because the permissions of links are not used. What matters are the permissions of the target. So don't try to set permissions of a link -- that will not work, because chmod can't change a link's permissions anyway. Set the permissions of the target.

ls -l shows the right permissions of your links. But those permissions are not used, what matteres are the permissions of the target.

I never used Midnight Commander, but from what you wrote it sound like it shows not the link's ownership but that of the target, which is confusing and probably a bug in Midnight Commander. Anyhow I would trust ls -l more than midnight commander.
Back to top
View user's profile Send private message
Jakub
Guru
Guru


Joined: 04 Oct 2003
Posts: 377
Location: Warsaw, Poland

PostPosted: Thu Jul 08, 2004 1:22 pm    Post subject: Reply with quote

Thanks for the reply asimon.

And what about the owner and group of a symlink? Is it always set to root:root but actually never used as well (the owner and group of the original file is important)?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo All times are GMT
Goto page Previous  1, 2, 3 ... 26, 27, 28, 29, 30  Next
Page 27 of 30

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum