Greets; My usb hd is automatically recognized and mounted as follows; /media/usb-0x05e3-0x0702:0:0:0p4 however SuSE see's this as /media/usb-0x05e3-0x0702\:0\:0\:0p4/ Now the problem with this notation is that it does not allow for NFS export due to name limitations which does not recognize the \'s Is there way to change the name of the drive as identified by Yast either when it auto mounts the drive to media or alternatively at a later point which would not be ideal. NFS will not work however unitl the naming convention changes. Regards /ch
Chris H wrote:
Greets;
My usb hd is automatically recognized and mounted as follows;
/media/usb-0x05e3-0x0702:0:0:0p4 however SuSE see's this as
Solution is simple. 1. Start SuSE plugger 2. Navigate to drive 3. Click on configure 4. unmount the drive partitions from a terminol 5. now use Yast to mount the drive where ever and call it whatever you want. 6. Reset NFS 7. exist yast 8. test NFS from another server. 9. done..:) Sorry to pester....:) /ch
Chris, On Tuesday 25 January 2005 09:45, Chris H wrote:
Chris H wrote:
Greets;
My usb hd is automatically recognized and mounted as follows;
/media/usb-0x05e3-0x0702:0:0:0p4 however SuSE see's this as
Solution is simple.
1. ... 9. ...
Simpler solution: Symlink.
/ch
Randall Schulz
Randall R Schulz wrote:
Simpler solution: Symlink.
Sure that is one way and probably will have to go that way. I was hoping that a more integrated solution was offered via Yast or other SuSE autoconfig tools. Nothing wrong with symlinks other then they are not automatic. /ch
Chris, On Tuesday 25 January 2005 10:03, you wrote:
Randall R Schulz wrote:
Simpler solution: Symlink.
Sure that is one way and probably will have to go that way. I was hoping that a more integrated solution was offered via Yast or other SuSE autoconfig tools. Nothing wrong with symlinks other then they are not automatic.
I don't understand what you mean by "automatic." With much less effort, the exact same result is obtained by creating a symbolic link. Automation is hardly an issue, it seems. Perhaps you're not aware that all those gibberish numbers and colons are device-specific, and whenever you plug in a particular memory stick you'll get the exact same sequence, so a symlink, once created, will always end up referring to the exact same memory stick. Or perhaps you want a single name that always refers to _whatever_ memory stick you plug in. In that case, perhaps your solution works.
/ch
Randall Schulz
Randall R Schulz wrote:
Chris,
On Tuesday 25 January 2005 10:03, you wrote:
Randall R Schulz wrote:
Simpler solution: Symlink.
The problem with a sym link to the SuSE supplied identifier is that is not carried through on NFS mounting. That is, when the drive is symlinked to say /media/usb1 when exported for NFS, SuSE still uses the original name which is illegal for NFS as it cannot read it..:(
Hence a sym link solution is not workable....for NFS export. /ch
Chris, On Tuesday 25 January 2005 10:24, Chris H wrote:
Randall R Schulz wrote:
Chris,
On Tuesday 25 January 2005 10:03, you wrote:
Randall R Schulz wrote:
Simpler solution: Symlink.
The problem with a sym link to the SuSE supplied identifier is that is not carried through on NFS mounting. That is, when the drive is symlinked to say /media/usb1 when exported for NFS, SuSE still uses the original name which is illegal for NFS as it cannot read it..:(
I know relatively little about NFS, but surely it can be configured to follow the symbolic links?
Hence a sym link solution is not workable....for NFS export.
That seems like a very odd limitation for a Unix-specific file sharing system...
/ch
Randall Schulz
On Tuesday 25 Jan 2005 18:24 pm, Chris H wrote:
Randall R Schulz wrote:
Chris,
On Tuesday 25 January 2005 10:03, you wrote:
Randall R Schulz wrote:
Simpler solution: Symlink.
The problem with a sym link to the SuSE supplied identifier is that is not carried through on NFS mounting. That is, when the drive is symlinked to say /media/usb1 when exported for NFS, SuSE still uses the original name which is illegal for NFS as it cannot read it..:(
Hence a sym link solution is not workable....for NFS export.
Since the mount point persists after the device/filesystem is unmounted, could a hardlink not be used? Dylan
/ch
-- "I see your Schwartz is as big as mine" -Dark Helmet
Chris, On Tuesday 25 January 2005 10:40, Chris H wrote:
Dylan wrote:
Since the mount point persists after the device/filesystem is unmounted, could a hardlink not be used?
No. Not for NFS as it will follow the link and read the original assigned device name.
There is no such thing as "following" a hard link. Symbolic links have direction to them. There is the symbolic link and the thing to which it refers. All hard links are co-equal names for an underlying file system entity and apart from the name itself, nothing distinguishes different hard links to a given entity. That said, other properties of hard links are relevant here. One is that hard links may not refer to directories (except for the one link that give the directory its name within its parent directory and the "." link that refers to itself). Second, hard links may not cross file system boundaries. Third, the mount point directory becomes inaccessible while a device is mounted on it. In effect, the mount point name changes the inode and resident device to which it refers when the mount operation takes place. Furthermore, file systems are devices mounted on directories. Only during the mount operation itself is the device name really relevant. Any use of a mounted file system (including sharing it via NFS) has nothing to do with the mounted device as such. That's the beauty of the Unix file system concept--it's a unified name space that can be dynamically extended by using the mount operation.
/ch
Randall Schulz
Randall R Schulz wrote:
That said, other properties of hard links are relevant here. One is that hard links may not refer to directories (except for the one link that give the directory its name within its parent directory and the "." link that refers to itself).
This makes setting a hard link in this sitation no an option nor workable. No, the answere to this problem lies more with SuSE's automounting process that I believe is at the kernel level and the assignment of the drive in scsi emulation mode. Remember that being a USB drive it is recognized as /dev/sda. Secondly the device hardware name is used. How to get around this is not known. Links of any kind do not work if the drive is to be exported and made available to other systems on the network. remain clueless..;) /ch
On Tuesday 25 Jan 2005 19:03 pm, Chris H wrote:
Randall R Schulz wrote:
That said, other properties of hard links are relevant here. One is that hard links may not refer to directories (except for the one link that give the directory its name within its parent directory and the "." link that refers to itself).
This makes setting a hard link in this sitation no an option nor workable. No, the answere to this problem lies more with SuSE's automounting process that I believe is at the kernel level and the assignment of the drive in scsi emulation mode. Remember that being a USB drive it is recognized as /dev/sda. Secondly the device hardware name is used. How to get around this is not known. Links of any kind do not work if the drive is to be exported and made available to other systems on the network.
Have you checked what happens during the hotplug part of the process to generate the name from the device h/ware? Dylan
remain clueless..;)
/ch
-- "I see your Schwartz is as big as mine" -Dark Helmet
Dylan, On Tuesday 25 January 2005 11:10, Dylan wrote:
...
Have you checked what happens during the hotplug part of the process to generate the name from the device h/ware?
It's derived from the device's identifying information, including its serial number: % cd /media % ls -ld usb* drwxrwxrwx 1 root root 0 2004-12-22 11:14 usb-storage-D235281419110:0:0:0p1 The relevent entry in /proc/bus/usb/devices: T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=05dc ProdID=0080 Rev= 0.01 S: Manufacturer=LEXAR MEDIA S: Product=JUMPDRIVE S: SerialNumber=D235281419110 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 90mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
Dylan
Randall Schulz
On Tuesday 25 Jan 2005 19:57 pm, Randall R Schulz wrote:
Dylan,
On Tuesday 25 January 2005 11:10, Dylan wrote:
...
Have you checked what happens during the hotplug part of the process to generate the name from the device h/ware?
It's derived from the device's identifying information, including its serial number:
I was thinking more of the scripts in /etc/hotplug to see if you can override it there Dylan
% cd /media % ls -ld usb* drwxrwxrwx 1 root root 0 2004-12-22 11:14 usb-storage-D235281419110:0:0:0p1
The relevent entry in /proc/bus/usb/devices:
T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=05dc ProdID=0080 Rev= 0.01 S: Manufacturer=LEXAR MEDIA S: Product=JUMPDRIVE S: SerialNumber=D235281419110 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 90mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
Dylan
Randall Schulz
-- "I see your Schwartz is as big as mine" -Dark Helmet
Dylan wrote:
I was thinking more of the scripts in /etc/hotplug to see if you can override it there
Well that may be possible, but.... Since Yast is the overall management tool for SuSE and it has a partitioning tool that specifically is designed to address partitions and mount points, and given that you can reassign the device name and mount points, and given that this does not survive a reboot.....I would consider this a bug in Yast. While it may be able to overide the various scripts this may lead to system inconsistancies or worse. Im going to go out on a limb here and test later but I going to assume the same situation exists with SLES9 as from looking at the yast logs, yast appears to be common now amoungst both versions. /ch
On Tuesday 25 Jan 2005 20:28 pm, Chris H wrote:
Dylan wrote:
I was thinking more of the scripts in /etc/hotplug to see if you can override it there
Well that may be possible, but.... Since Yast is the overall management tool for SuSE and it has a partitioning tool that specifically is designed to address partitions and mount points, and given that you can reassign the device name and mount points, and given that this does not survive a reboot.....I would consider this a bug in Yast.
No, most definitely not. Maybe you could say there is some configurability not covered there, but it is not a bug. The partitioning module in yast is for fixed devices, not hotplug devices. The hotplug/subfs system is still maturing so why don't you provide some feedback to SuSE and be constructive about it. Dylan -- "I see your Schwartz is as big as mine" -Dark Helmet
Dylan wrote:
No, most definitely not. Maybe you could say there is some configurability not covered there, but it is not a bug. The partitioning module in yast is for fixed devices, not hotplug devices.
Ok lets discuss this point. If that were the case then I could not partition the sled and or change its mount point. Since this is not the case and its do-able in yast, and I can change the mount point to anything I want, and yast accepts it (and creates the dir if they dont exist)...but...as it does not survive a reboot, I would classify this as a bug. If this functionality were not in place I would agree with you. Same applies to SLES9 which I just tested btw.
The hotplug/subfs system is still maturing so why don't you provide some feedback to SuSE and be constructive about it.
Sure. Whats the new URL if known, Its used to be this list and others prior too Novell. Thanks for your help. Its appreciated. /ch
Chris, On Tuesday 25 January 2005 13:20, Chris H wrote:
...
The hotplug/subfs system is still maturing so why don't you provide some feedback to SuSE and be constructive about it.
Sure. Whats the new URL if known, Its used to be this list and others prior too Novell.
I don't believe that's true. This list is provided as a courtesy to users of SuSE Linux products. Official bug reporting and change or enhancement requests must be made through the SuSE (Novell) Web site: <http://www.suse.de/cgi-bin/feedback.cgi>.
Thanks for your help. Its appreciated.
/ch
Randall Schulz
Randall R Schulz wrote:
I don't believe that's true. This list is provided as a courtesy to users of SuSE Linux products.
As said, things have changed. This uses to be the primary means of communication pre Novell. Not that we dont appreciate it, just pointing out that things have changed. Thats all. Some of us have been around for a while, like since 5.2 where the developers, Bodo and others, actually read this and other lists. Not a complaint by any means just an observation.
Official bug reporting and change or enhancement requests must be made through the SuSE (Novell) Web site: <http://www.suse.de/cgi-bin/feedback.cgi>.
Thanks again. Its appreciated. /ch
On Tuesday 25 Jan 2005 21:20 pm, Chris H wrote:
Sure. Whats the new URL if known, Its used to be this list and others prior too Novell.
http://support.novell.com/additional/bugreport.html
Thanks for your help. Its appreciated.
/ch
-- "I see your Schwartz is as big as mine" -Dark Helmet
Dylan wrote: All done; Filed for both SuSE 9.2 and SLES 9 Thanks /ch
Chris H wrote:
Solution is simple.
1. Start SuSE plugger 2. Navigate to drive 3. Click on configure 4. unmount the drive partitions from a terminol 5. now use Yast to mount the drive where ever and call it whatever you want. 6. Reset NFS 7. exist yast 8. test NFS from another server. 9. done..:)
Sorry to pester....:)
Further testing indicates that this method does not survive a reboot with SuSE still assigning the USB drive to /media/usb-0x05e3-0x0702:0:0:0p4 and media/usb-0x05e3-0x0702:0:0:0p1 the two available partitions on the drive. Now checking /etc/fstab both directories and mount points are identified as per yast method described above eg: -------------------------------- /dev/sda4 /media/usb2 ext3 no,auto,user,rw,exec,sync 0 0 /dev/sda1 /media/usb1 vfat defaults 0 0 -------------------------------- Since these are identified as scsi drives (emulated) there must be something in automount process that by-passes the yast config hence mounting the drive partitions as /media/usb-0x05e3-0x0702:0:0:0p4 Any clues...?? /ch
On Tuesday 25 January 2005 12:01 pm, Chris H wrote:
Chris H wrote:
Solution is simple.
1. Start SuSE plugger 2. Navigate to drive 3. Click on configure 4. unmount the drive partitions from a terminol 5. now use Yast to mount the drive where ever and call it whatever you want. 6. Reset NFS 7. exist yast 8. test NFS from another server. 9. done..:)
Sorry to pester....:)
Further testing indicates that this method does not survive a reboot with SuSE still assigning the USB drive to /media/usb-0x05e3-0x0702:0:0:0p4 and media/usb-0x05e3-0x0702:0:0:0p1 the two available partitions on the drive.
Use udev to make a persistent dev name and a fstab entry to mount it should do what you want. My setup doesn't auto mount when I plug in the jumpdrive (I have to mount it manually), but no matter what usb port I use, it gets mounted in a way I can remember and that nfs would accept. In /etc/udev/rules.d/50-udev.rules, I added the rule: BUS="usb", SYSFS{serial}="J319060125020", KERNEL="sd*", NAME="%k" SYMLINK="lexar%n" (The above in one line) Make it the first rule after the comments. You might be able to place it in a file by itself that gets read before the 50-udev.rules file. I think they are read alphabetically, so maybe 49-udev.rules? The BUS="usb" and SYSFS{serial}="device_serial_number" identify the jump drive. I got the serial number using usbview. If I had several Lexar Media thumb drives and wanted any one of them to mounted to the same place, I could use SYSFS{manufacturer}="Lexar Media" instead of a serial number. (I haven't actually tested that, but it should work). The KERNEL="sd*" makes sure I match a mountable block device and not a character device like sg0. NAME="%k" keeps the kernel name (like sda so the default block device doesn't get overwritten and you can still mount on that device. The SYMLINK="lexar%n" means that no matter what /dev/sdx the jumpdrive becomes when I plug it in, /dev/lexarx will point to it. The %n is for multiple partitions if you have them (ie: sda-lexar, sda1=lexar1, sda2=lexar2, etc). When the thumbdrive is plugged in, the devices are created (takes a few seconds). In /etc/fstab, I added: /dev/lexar1 /media/jumpdrive auto users,defaults 0 0 After creating /media/jumpdrive, any user can mount the thumdrive a few seconds after plugging it in. Some one who understands and can read/modify the various scripts involved could probably get this to hotplug and automount, but I leave that to some less scripting challenged. Hope that helps! Doug
participants (4)
-
Chris H -
Doug B -
Dylan -
Randall R Schulz