problems with Iomega Zip drives in Suse 9.2
I have just installed Suse 9.2, and can't get my Iomega Atapi zip drive to work. The boot log indicates that this drive is detected as hdd. However, when I run the suse hardware tool, it is unable to find the drive unless there is a zip disk in the drive. When I put a zip disk in the drive, the drive acts as if it is being read briefly more frequently than once a minute. The slows the system down dramatically an produces very frequently repeated string of msgs in the system log of the form Jan 31 00:00:20 linux /etc/dev.d/block/50-hwscan.dev[20540]: new block device /block/hdd/hdd4 Jan 31 00:00:20 linux /etc/dev.d/block/51-subfs.dev[20550]: mount block device /block/hdd/hdd4 Jan 31 00:00:21 linux /etc/dev.d/block/51-subfs.dev[20609]: umount block device /block/hdd/hdd4 Jan 31 00:00:21 linux kernel: hdd: hdd4 Jan 31 00:00:21 linux /etc/dev.d/block/51-subfs.dev[20609]: umount: /dev/hdd4: not mounted Jan 31 00:00:21 linux kernel: hdd: hdd4 As far as I can tell, subfs doesn't support zip drives. I have tried inserting the appropriate entries in fstab for the zip drive such as /dev/hdd4 /media/zip vfat noauto,users but this has no effect. Similar fstab entries worked fine in Suse 9.1 and several different versions of Red Hat. The oddest thing about all of this is that, when I list the directory /dev, there is no entry of the form hdd4. Every other possible hdd# is there, but hdd4 is missing. However, this is the right partition for a vfat formatted zip disk. Any help would be appreciated. Thanks, Gaunce Lewis
Sorry Gaunce... I sent the first reply to you instead of the list. Gaunce Lewis writes:
I have just installed Suse 9.2, and can't get my Iomega Atapi zip drive to work.
As far as I can tell, subfs doesn't support zip drives. I have tried inserting the appropriate entries in fstab for the zip drive such as
/dev/hdd4 /media/zip vfat noauto,users
but this has no effect. Similar fstab entries worked fine in Suse 9.1 and several different versions of Red Hat.
The oddest thing about all of this is that, when I list the directory /dev, there is no entry of the form hdd4. Every other possible hdd# is there, but hdd4 is missing. However, this is the right partition for a vfat formatted zip disk.
n 9.1 I needed fstab to use /dev/hdd4. In 9.2 I had to change that to read /dev/hdd (no parttiton number). This worked for me and some others. A few said it didn't work for them. At least it's easy to try! Doug
-----Original Message----- From: Gaunce Lewis [mailto:lglist@twcny.rr.com] Sent: Tuesday, 1 February 2005 5:04 AM To: suse-linux-e@suse.com Subject: [SLE] problems with Iomega Zip drives in Suse 9.2 I have just installed Suse 9.2, and can't get my Iomega Atapi zip drive to work. The boot log indicates that this drive is detected as hdd. However, when I run the suse hardware tool, it is unable to find the drive unless there is a zip disk in the drive. When I put a zip disk in the drive, the drive acts as if it is being read briefly more frequently than once a minute. The slows the system down dramatically an produces very frequently repeated string of msgs in the system log of the form Jan 31 00:00:20 linux /etc/dev.d/block/50-hwscan.dev[20540]: new block device /block/hdd/hdd4 Jan 31 00:00:20 linux /etc/dev.d/block/51-subfs.dev[20550]: mount block device /block/hdd/hdd4 Jan 31 00:00:21 linux /etc/dev.d/block/51-subfs.dev[20609]: umount block device /block/hdd/hdd4 Jan 31 00:00:21 linux kernel: hdd: hdd4 Jan 31 00:00:21 linux /etc/dev.d/block/51-subfs.dev[20609]: umount: /dev/hdd4: not mounted Jan 31 00:00:21 linux kernel: hdd: hdd4 As far as I can tell, subfs doesn't support zip drives. I have tried inserting the appropriate entries in fstab for the zip drive such as /dev/hdd4 /media/zip vfat noauto,users but this has no effect. Similar fstab entries worked fine in Suse 9.1 and several different versions of Red Hat. The oddest thing about all of this is that, when I list the directory /dev, there is no entry of the form hdd4. Every other possible hdd# is there, but hdd4 is missing. However, this is the right partition for a vfat formatted zip disk. Any help would be appreciated. Thanks, Gaunce Lewis -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com Yes, I had similar problems and went to the suse forums and found many other people had the same problem. Try to use hdd (without the 4) and auto not vfat as this worked for me and others.(But not everyone) Chris
The Monday 2005-01-31 at 13:03 -0500, Gaunce Lewis wrote:
As far as I can tell, subfs doesn't support zip drives. I have tried inserting the appropriate entries in fstab for the zip drive such as
/dev/hdd4 /media/zip vfat noauto,users
but this has no effect. Similar fstab entries worked fine in Suse 9.1 and several different versions of Red Hat.
Did you see any other entry related to hdd, and with subfs mentioned?
The oddest thing about all of this is that, when I list the directory /dev, there is no entry of the form hdd4. Every other possible hdd# is there, but hdd4 is missing. However, this is the right partition for a vfat formatted zip disk.
It really should be there. You could recreate it. My 9.1 has: brw-rw---- 1 root disk 22, 68 2004-08-15 14:00 /dev/hdd4 -- Cheers, Carlos Robinson
On Monday 31 January 2005 08:55 pm, Carlos E. R. wrote:
The oddest thing about all of this is that, when I list the directory /dev, there is no entry of the form hdd4. Every other possible hdd# is there, but hdd4 is missing. However, this is the right partition for a vfat formatted zip disk.
It really should be there. You could recreate it. My 9.1 has:
brw-rw---- 1 root disk 22, 68 2004-08-15 14:00 /dev/hdd4
Hi Carlos, For whatever reason with 9.2, SuSE doesn't create the device hdx4 where the zip drive is attached. Mine is /dev/hdb and there is no /dev/hdb4. Several people have reported this on various list/forums. When I first started looking for an answer, I found the suggestion to create the /dev/hdx4. They put a script in boot.local to do this every boot. It didn't work for me Some reformatted the disks with linux filesystems and mounted at hdx1. I couldn't use that because I share the disks between my home linux box and work windows box. I played around with mounting at partition 4 (as in all other distros/releases I've used) then tried 1, 2, and 3 with no luck. I don't know why I tried hdx with (no partition) but it worked! I haven't had the time or desire to find out why this is. I probably wouldn't understand it anyway. Doug
On 2005-02-01 05:05, Doug B wrote:
It really should be there. You could recreate it. My 9.1 has: brw-rw---- 1 root disk 22, 68 2004-08-15 14:00 /dev/hdd4
Hi Carlos,
For whatever reason with 9.2, SuSE doesn't create the device hdx4 where the zip drive is attached. Mine is /dev/hdb and there is no /dev/hdb4. Several people have reported this on various list/forums.
Weird.
When I first started looking for an answer, I found the suggestion to create the /dev/hdx4. They put a script in boot.local to do this every boot. It didn't work for me
It wasn't created, or if created did not work? Did anybody try setting the sticky bit?
Some reformatted the disks with linux filesystems and mounted at hdx1.
I do that with some disks, but not all of them, I use zips for interchange. But I'm still using 9.1, and from the parallell port, I can't duplicate your problem.
I couldn't use that because I share the disks between my home linux box and work windows box.
Right.
I played around with mounting at partition 4 (as in all other distros/releases I've used) then tried 1, 2, and 3 with no luck. I don't know why I tried hdx with (no partition) but it worked!
Funny. The other partitions will not work, unless formatted that way. But yes, I remember the issue being comented here, on list.
I haven't had the time or desire to find out why this is. I probably wouldn't understand it anyway.
I understand. But, did you report to feedback? They really should know about this problem. -- Cheers, Carlos Robinson
On Tuesday 01 February 2005 04:56 am, Carlos E. R. wrote:
When I first started looking for an answer, I found the suggestion to create the /dev/hdx4. They put a script in boot.local to do this every boot. It didn't work for me
It wasn't created, or if created did not work?
Did anybody try setting the sticky bit?
As I remember (I'm bad at making notes), it was created but I still couldn't mount the disk. No one had suggested the sticky bit and I didn't try it.
Some reformatted the disks with linux filesystems and mounted at hdx1.
I do that with some disks, but not all of them, I use zips for interchange. But I'm still using 9.1, and from the parallell port, I can't duplicate your problem.
I have only seen a couple of post about problems with 9.1 and zip drives. I don't think those were related the hdx4 issue. I think that appeared with 9.2.
I played around with mounting at partition 4 (as in all other distros/releases I've used) then tried 1, 2, and 3 with no luck. I don't know why I tried hdx with (no partition) but it worked!
Funny. The other partitions will not work, unless formatted that way. But yes, I remember the issue being comented here, on list.
I knew it had always mounted at hdx4, but I was tired and ready to try anything! That was easy to try and I've been surprised before when something worked in an unexpected way. Since mounting at /dev/hdx I have had no problems. I can read/write and even export through nfs so other machines can use it.
I haven't had the time or desire to find out why this is. I probably wouldn't understand it anyway.
I understand. But, did you report to feedback? They really should know about this problem.
No I haven't. I just figured this was the 'new' and 'undocumented' to mount a zip. In another email in this thread you said: "However, I think that the reason the device file is deleted every boot, as some seem to report, should be worth investigating." I truly can't say from personal experience that the device gets deleted. The suggestion I read said to put the script in boot.local so the device gets created on each boot. I just assumed it was deleted everytime and had to be recreated. Doug
The Tuesday 2005-02-01 at 09:02 -0600, Doug B wrote: ...
I knew it had always mounted at hdx4, but I was tired and ready to try anything! That was easy to try and I've been surprised before when something worked in an unexpected way. Since mounting at /dev/hdx I have had no problems. I can read/write and even export through nfs so other machines can use it.
Very funny, to say something.
In another email in this thread you said:
"However, I think that the reason the device file is deleted every boot, as some seem to report, should be worth investigating."
I truly can't say from personal experience that the device gets deleted. The suggestion I read said to put the script in boot.local so the device gets created on each boot. I just assumed it was deleted everytime and had to be recreated.
Fair enough :-) -- Cheers, Carlos Robinson
On Tuesday 01 February 2005 10:19 am, Carlos E. R. wrote:
The Tuesday 2005-02-01 at 09:02 -0600, Doug B wrote:
...
I knew it had always mounted at hdx4, but I was tired and ready to try anything! That was easy to try and I've been surprised before when something worked in an unexpected way. Since mounting at /dev/hdx I have had no problems. I can read/write and even export through nfs so other machines can use it.
Very funny, to say something.
This thread is starting to get old, but I'm home sick... and bored. I moved the zip from /dev/hdb to /dev/hdd Still no /dev/hdb4 but /dev/hdd4 was there. Tried mounting /dev/hdd4 but failed. I don't recall the error. Not a vaild block device? Maybe that was it. (I've already put things back to the way they were so I can't check.) I tried mounting /dev/hdd and it worked fine. It works... I'm happy... back to bed. Doug
Carlos, On Tuesday 01 February 2005 02:56, Carlos E. R. wrote:
On 2005-02-01 05:05, Doug B wrote:
It really should be there. You could recreate it. My 9.1 has: brw-rw---- 1 root disk 22, 68 2004-08-15 14:00 /dev/hdd4
Hi Carlos,
For whatever reason with 9.2, SuSE doesn't create the device hdx4 where the zip drive is attached. Mine is /dev/hdb and there is no /dev/hdb4. Several people have reported this on various list/forums.
Weird.
When I first started looking for an answer, I found the suggestion to create the /dev/hdx4. They put a script in boot.local to do this every boot. It didn't work for me
It wasn't created, or if created did not work?
Did anybody try setting the sticky bit?
That doesn't seem likely to help. Presumably "/dev" is owned by and only writable by root, so making it sticky isn't going to have any real effect. Root was the only user that could have removed an entry there and will still be able to even if the directory is marked sticky.
...
-- Cheers, Carlos Robinson
Randall Schulz
The Tuesday 2005-02-01 at 08:11 -0800, Randall R Schulz wrote:
Did anybody try setting the sticky bit?
That doesn't seem likely to help. Presumably "/dev" is owned by and only writable by root, so making it sticky isn't going to have any real effect. Root was the only user that could have removed an entry there and will still be able to even if the directory is marked sticky.
Probably, yes. Although I was thinking of the file, not the directory. I'm just hopping - I have never tried - that a "delete file" operation complains about the sticky bit having to be removed first. As I say, I don't know if that is the case, I'm just hoping. -- Cheers, Carlos Robinson
Carlos, On Tuesday 01 February 2005 11:42, Carlos E. R. wrote:
The Tuesday 2005-02-01 at 08:11 -0800, Randall R Schulz wrote:
Did anybody try setting the sticky bit?
That doesn't seem likely to help. Presumably "/dev" is owned by and only writable by root, so making it sticky isn't going to have any real effect. Root was the only user that could have removed an entry there and will still be able to even if the directory is marked sticky.
Probably, yes. Although I was thinking of the file, not the directory. I'm just hopping - I have never tried - that a "delete file" operation complains about the sticky bit having to be removed first. As I say, I don't know if that is the case, I'm just hoping.
The sticky bit has two interpretations, one ancient and, I think, obsolete and the other newer and still relevant: 1/old) The executable text (instructions) of pure binary executables with their sticky bit set remain in the swap space even when no process is executing them. Then instead of recreating their core image from scratch (from the executable file contents) the next time that program is executed, it can simply be swapped in again. 2/new) Directories whose sticky bit is set can be made writable by all while allowing only the owner of a file to remove it (more precisely, a directory entry referring to it) from that directory. As ever, root is not subject to the restriction created by the second use of the sticky bit. So I don't see how making /dev or a device entry therein sticky is going to have any actual effect on the operation of the system.
Carlos Robinson
Randall Schulz
The Tuesday 2005-02-01 at 16:20 -0800, Randall R Schulz wrote:
The sticky bit has two interpretations, one ancient and, I think, obsolete and the other newer and still relevant:
yes, I saw that.
1/old) The executable text (instructions) of pure binary executables with their sticky bit set remain in the swap space even when no process is executing them. Then instead of recreating their core image from scratch (from the executable file contents) the next time that program is executed, it can simply be swapped in again.
2/new) Directories whose sticky bit is set can be made writable by all while allowing only the owner of a file to remove it (more precisely, a directory entry referring to it) from that directory.
As ever, root is not subject to the restriction created by the second use of the sticky bit.
So I don't see how making /dev or a device entry therein sticky is going to have any actual effect on the operation of the system.
I tried to test it, as user, and I can't even set the sticky bit for the owner: cer@nimrodel:~/tmp> touch test cer@nimrodel:~/tmp> chmod u+t test cer@nimrodel:~/tmp> l test -rw-r--r-- 1 cer users 0 2005-02-03 02:04 test cer@nimrodel:~/tmp> rm test cer@nimrodel:~/tmp> l test /bin/ls: test: No such file or directory Same result for a directory, and the same as root, I can not create sticky files/dirs, for the owner. It only applies to "others": cer@nimrodel:~/tmp> chmod o+t test cer@nimrodel:~/tmp> l test -rw-r--r-T 1 cer users 0 2005-02-03 02:07 test cer@nimrodel:~/tmp> chmod g+t test cer@nimrodel:~/tmp> l test -rw-r--r-T 1 cer users 0 2005-02-03 02:07 test This is not mentioned in the manual, that was what missled me: The letters `rwxXstugo' select the new permissions for the affected users: read (r), write (w), execute (or access for directories) (x), execute only if the file is a direc tory or already has execute permission for some user (X), set user or group ID on execution (s), sticky (t), the permissions granted to the user who owns the file (u), the permissions granted to other users who are members of the file's group (g), and the permissions granted to users that are in neither of the two preceding categories (o). -- Cheers, Carlos Robinson
Gaunce Lewis
However, this is the right partition for a vfat formatted zip disk.
It depends on how the zip disk was formatted. By default most are formatted as hard disk and use the 4th partition (hdX4). But you can also format them as super floppy (hdX) or use the first partition (hdX1). Philipp
On 2005-02-01 09:17, Philipp Thomas wrote:
Gaunce Lewis
[Mon, 31 Jan 2005 13:03:48 -0500]: However, this is the right partition for a vfat formatted zip disk.
It depends on how the zip disk was formatted. By default most are formatted as hard disk and use the 4th partition (hdX4). But you can also format them as super floppy (hdX) or use the first partition (hdX1).
Except if you use zips discs for interchanging files with other systems. However, I think that the reason the device file is deleted every boot, as some seem to report, should be worth investigating. -- Cheers, Carlos Robinson
Hi, On Tue, 1 Feb 2005 11:48:15 +0100 "Carlos E. R." <.> wrote: ...
It depends on how the zip disk was formatted. By default most are formatted as hard disk and use the 4th partition (hdX4). But you can also format them as super floppy (hdX) or use the first partition(hdX1).
Except if you use zips discs for interchanging files with other systems.
I use frequently 100Mb ZIP disks formatted with vfat, and having data exclusively on their first partition. At least with 9.1 they work well, and I can exchange data with M$Y2K-XP systems without any problem. OK, I agree: on 9.1 the setup of my parallel Iomega drive was close to a real nichtmare... Now I have subfs disabled, and it's just fine with the /dev/sda1 /media/zippo vfat noauto,user,exec,sync 0 0 fstab entry. Best regards, Pelibali
The Tuesday 2005-02-01 at 22:48 +0100, pelibali wrote:
OK, I agree: on 9.1 the setup of my parallel Iomega drive was close to a real nichtmare... Now I have subfs disabled, and it's just fine with the
/dev/sda1 /media/zippo vfat noauto,user,exec,sync 0 0
fstab entry.
I have: /dev/sda1 /media/zip auto defaults,noauto,user,exec 0 4 /dev/sda4 /media/zip2 auto defaults,noauto,user,exec 0 0 I have had that setting for years, and 9.1 worked first time, but I never allowed it to use automount. The only snag is that I have to issue "modprobe imm" manually. I would like to automate it somehow, so that issuing the mount command triggers the module loading as needed. It should be possible, I suppose, but I haven't bothered much to learn how. -- Cheers, Carlos Robinson
Hi Carlos, On Wed, 2 Feb 2005 13:36:51 +0100 (CET) "Carlos E. R." <.> wrote: ...
I have had that setting for years, and 9.1 worked first time, but I never allowed it to use automount. The only snag is that I have to issue "modprobe imm" manually. I would like to automate it somehow, so that issuing the mount command triggers the module loading as needed. It should be possible, I suppose, but I haven't bothered much to learn how.
I had previously a similar question, concerning e.g. the 'acerhk' module I modprobed always manually; but the problem was solved on this list by someone:) I went to Yast -> System -> /etc/sysconfig Editor, and wrote the modules I wanted to load into the "MODULES_LOADED_ON_BOOT" (sorry, please do search for it) field, actually separated by single spaces. I would say in case you have only 'imm', just write it into the above field, and that's all; for me on 9.1 this works perfectly with all of my modules. Alternative way was still, as suggested by someone else, to write all of the modules, still under the sysconfig editor, but into the "INITRD_MODULES"; but with that I was more careful, and didn't want to touch that seriously looking option... ;) By the way my parallel ZIP loads the module it needs (ppa) surprisingly through this latter one; hmmm, I'm too newbie to comment on that. That was decided by YaST. Pelibali
The Wednesday 2005-02-02 at 23:57 +0100, pelibali wrote:
I went to Yast -> System -> /etc/sysconfig Editor, and wrote the modules I wanted to load into the "MODULES_LOADED_ON_BOOT" (sorry, please do search for it) field, actually separated by single spaces.
Yes, I know about that; but then it is loaded always, and I only want it when needed.
By the way my parallel ZIP loads the module it needs (ppa) surprisingly through this latter one; hmmm, I'm too newbie to comment on that. That was decided by YaST.
ppa is older, used for zip 100 drives. Mine is 250+. -- Cheers, Carlos Robinson
-----Original Message-----
From: Philipp Thomas [mailto:philipp.thomas@t-link.de]
Sent: Tuesday, 1 February 2005 7:17 PM
To: suse-linux-e@suse.com
Subject: Re: [SLE] problems with Iomega Zip drives in Suse 9.2
Gaunce Lewis
However, this is the right partition for a vfat formatted zip disk.
It depends on how the zip disk was formatted. By default most are formatted as hard disk and use the 4th partition (hdX4). But you can also format them as super floppy (hdX) or use the first partition (hdX1). Philipp -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com Actually suse has changed the way the zip drive is treated; as on 9.1 you will need to use hdx4 but ob 9.2 hdx.(Even if you use the exact same zip disk). So it doesnot depend on how it is formatted and it's partitions etc. So far as I know suse is the only os to manage this. Chris
Thanks for the numerous responses to my question about mounting ATAPI zip 100 drives in 9.2. Unfortunately, none of the suggestions made worked for me. I have, however, found one thing that seems to work, which I'll pass on since I gather I'm not the only one who has had no luck with this problem. Here's what worked for me: Open the sysconfig Editor in Yast, go to the Hardware section, go to the Hotplug subsection, and change the entry HOTPLUG_DO_MOUNT to no. I also changed the entry HOTPLUG_MOUNT_TYPE to fstab, but I doubt that matters. With this change, the traditional fstab entries like /dev/hdd4 /mnt/zip vfat user, noauto 0 0 seem to work fine for mounting and unmounting the zip drive manually on the command line. My guess is that, with this change, you may have to mount things like cdroms and floppies manually as well. Without this change in Sysconfig, I could find no way to gain access to my zip drive in 9.2. Both the entry above, the entry /dev/hdd /mnt/zip auto user, noauto 0 0 and every variant of either of these that I could dream up produced essentially the same problem. Trying to mount the drive would produce an error msg (for filetype auto in fstab the msg was that the filetype had to be specified -- for filetype vfat the error msg was a much longer and less specific one). After the error msg, the system would go into a loop in which it the drive activity light would come on briefly, the drive would spin briefly, and then the light and spinning would stop. This cycle repeated more often than once a minute and so loaded the system that almost nothing else could be done. The cycling also produced a huge number of error msgs in the syslog like those mentioned in my earlier msg copied below. Moreover, the device /dev/hdd4 was deleted every time. Each time I tried something new, I put it back in with mknod, but it disappeared shortly after the cycling started whenever I tried to mount the drive. What a mess! Best wishes, Gaunce On Mon January 31 2005 1:03 pm, Gaunce Lewis wrote:
I have just installed Suse 9.2, and can't get my Iomega Atapi zip drive to work. The boot log indicates that this drive is detected as hdd. However, when I run the suse hardware tool, it is unable to find the drive unless there is a zip disk in the drive. When I put a zip disk in the drive, the drive acts as if it is being read briefly more frequently than once a minute. The slows the system down dramatically an produces very frequently repeated string of msgs in the system log of the form
Jan 31 00:00:20 linux /etc/dev.d/block/50-hwscan.dev[20540]: new block device /block/hdd/hdd4 Jan 31 00:00:20 linux /etc/dev.d/block/51-subfs.dev[20550]: mount block device /block/hdd/hdd4 Jan 31 00:00:21 linux /etc/dev.d/block/51-subfs.dev[20609]: umount block device /block/hdd/hdd4 Jan 31 00:00:21 linux kernel: hdd: hdd4 Jan 31 00:00:21 linux /etc/dev.d/block/51-subfs.dev[20609]: umount: /dev/hdd4: not mounted Jan 31 00:00:21 linux kernel: hdd: hdd4
As far as I can tell, subfs doesn't support zip drives. I have tried inserting the appropriate entries in fstab for the zip drive such as
/dev/hdd4 /media/zip vfat noauto,users
but this has no effect. Similar fstab entries worked fine in Suse 9.1 and several different versions of Red Hat.
The oddest thing about all of this is that, when I list the directory /dev, there is no entry of the form hdd4. Every other possible hdd# is there, but hdd4 is missing. However, this is the right partition for a vfat formatted zip disk.
Any help would be appreciated.
Thanks, Gaunce Lewis
participants (8)
-
Carlos E. R.
-
Chris
-
Doug B
-
Gaunce Lewis
-
pelibali
-
Philipp Thomas
-
Randall R Schulz
-
suse