View previous topic :: View next topic |
Author |
Message |
rndpkt n00b
Joined: 04 Mar 2003 Posts: 59
|
Posted: Sun Jun 20, 2004 4:36 am Post subject: |
|
|
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 |
|
|
dsd Developer
Joined: 30 Mar 2003 Posts: 2162 Location: nr London
|
Posted: Sun Jun 20, 2004 7:39 am Post subject: |
|
|
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 |
|
|
dsd Developer
Joined: 30 Mar 2003 Posts: 2162 Location: nr London
|
Posted: Sun Jun 20, 2004 7:44 am Post subject: |
|
|
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 |
|
|
rndpkt n00b
Joined: 04 Mar 2003 Posts: 59
|
Posted: Sun Jun 20, 2004 12:30 pm Post subject: |
|
|
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... |
|
Back to top |
|
|
Decibels Veteran
Joined: 16 Aug 2002 Posts: 1623 Location: U.S.A.
|
Posted: Sun Jun 20, 2004 2:35 pm Post subject: |
|
|
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 |
|
|
dsd Developer
Joined: 30 Mar 2003 Posts: 2162 Location: nr London
|
Posted: Sun Jun 20, 2004 4:33 pm Post subject: |
|
|
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 |
|
|
Decibels Veteran
Joined: 16 Aug 2002 Posts: 1623 Location: U.S.A.
|
Posted: Sun Jun 20, 2004 4:43 pm Post subject: |
|
|
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 |
|
|
mr.twemlow Tux's lil' helper
Joined: 12 Nov 2003 Posts: 90 Location: Illinois
|
Posted: Mon Jun 21, 2004 2:49 pm Post subject: |
|
|
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 |
|
|
nesl247 Veteran
Joined: 15 Jun 2004 Posts: 1614 Location: Florida
|
Posted: Mon Jun 21, 2004 3:18 pm Post subject: |
|
|
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 |
|
|
dsd Developer
Joined: 30 Mar 2003 Posts: 2162 Location: nr London
|
Posted: Mon Jun 21, 2004 3:43 pm Post subject: |
|
|
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 |
|
|
mr.twemlow Tux's lil' helper
Joined: 12 Nov 2003 Posts: 90 Location: Illinois
|
|
Back to top |
|
|
Decibels Veteran
Joined: 16 Aug 2002 Posts: 1623 Location: U.S.A.
|
Posted: Wed Jun 23, 2004 1:46 am Post subject: |
|
|
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 |
|
|
dsd Developer
Joined: 30 Mar 2003 Posts: 2162 Location: nr London
|
Posted: Wed Jun 23, 2004 8:46 am Post subject: |
|
|
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 |
|
|
Decibels Veteran
Joined: 16 Aug 2002 Posts: 1623 Location: U.S.A.
|
Posted: Wed Jun 23, 2004 10:46 am Post subject: |
|
|
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 |
|
|
dsd Developer
Joined: 30 Mar 2003 Posts: 2162 Location: nr London
|
Posted: Wed Jun 23, 2004 11:15 am Post subject: |
|
|
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 |
|
|
Decibels Veteran
Joined: 16 Aug 2002 Posts: 1623 Location: U.S.A.
|
Posted: Wed Jun 23, 2004 1:45 pm Post subject: |
|
|
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 |
|
|
Decibels Veteran
Joined: 16 Aug 2002 Posts: 1623 Location: U.S.A.
|
Posted: Thu Jul 01, 2004 1:28 am Post subject: |
|
|
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 |
|
|
dweigert Guru
Joined: 04 Oct 2002 Posts: 369 Location: Somerset, NJ USA
|
Posted: Sat Jul 03, 2004 8:17 pm Post subject: |
|
|
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 |
|
|
semiSfear Guru
Joined: 08 Jul 2003 Posts: 302 Location: Adelaide, SA
|
Posted: Sun Jul 04, 2004 2:50 pm Post subject: |
|
|
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 |
|
|
Jakub Guru
Joined: 04 Oct 2003 Posts: 377 Location: Warsaw, Poland
|
Posted: Thu Jul 08, 2004 12:11 am Post subject: |
|
|
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):
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 |
|
|
asimon l33t
Joined: 27 Jun 2002 Posts: 979 Location: Germany, Old Europe
|
Posted: Thu Jul 08, 2004 12:28 am Post subject: |
|
|
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 |
|
|
Decibels Veteran
Joined: 16 Aug 2002 Posts: 1623 Location: U.S.A.
|
Posted: Thu Jul 08, 2004 11:08 am Post subject: |
|
|
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 |
|
|
Jakub Guru
Joined: 04 Oct 2003 Posts: 377 Location: Warsaw, Poland
|
Posted: Thu Jul 08, 2004 1:00 pm Post subject: |
|
|
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 |
|
|
asimon l33t
Joined: 27 Jun 2002 Posts: 979 Location: Germany, Old Europe
|
Posted: Thu Jul 08, 2004 1:15 pm Post subject: |
|
|
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 |
|
|
Jakub Guru
Joined: 04 Oct 2003 Posts: 377 Location: Warsaw, Poland
|
Posted: Thu Jul 08, 2004 1:22 pm Post subject: |
|
|
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 |
|
|
|