Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 3892

Summary: Mount of Iomega Zip 100 fails after upgrade from 5.2
Product: [Retired] Red Hat Linux Reporter: sol0
Component: kernelAssignee: David Lawrence <dkl>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0CC: sol0
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-08-25 22:53:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description sol0 1999-07-04 03:32:21 UTC
This is my fstab entry for the parallel zip:

/dev/hdb4    /mnt/zip     auto noauto,rw       0 0

In RH 5.2 I could mount the zip via "mount /mnt/zip", but
after the 6.0 upgrade I get this error:

[root@Pandy /root]# mount /mnt/zip
mount: you must specify the filesystem type

I'm at a loss as to what FS type to specify (-: I managed to
hang my session by specifying -t msdos (it's a PC formatted
disk).

This is the workaround - first mount a DOS partition:

[root@Pandy /root]# mount /mnt/zip
mount: you must specify the filesystem type
[root@Pandy /root]# df
Filesystem           1k-blocks      Used Available Use%
Mounted on
/dev/hda6              1981000   1078695    799894  57% /
/dev/hda7              5538191    452608   4798825   9% /home
/dev/hda8              3958767    265543   3488397   7% /usr/
local
[root@Pandy /root]# mount /mnt/dos
[root@Pandy /root]# mount /mnt/zip
[root@Pandy /root]# df
Filesystem           1k-blocks      Used Available Use%
Mounted on
/dev/hda6              1981000   1078695    799894  57% /
/dev/hda7              5538191    452608   4798825   9% /home
/dev/hda8              3958767    265543   3488397   7% /usr/
local
/dev/hda1              2044244    837584   1206660  41% /mnt/
dos
/dev/hdb4                98078      9556     88522  10% /mnt/
zip
[root@Pandy /root]#

Comment 1 sol0 1999-07-09 01:51:59 UTC
Note 1 - it's not a parallel Zip, rather an internal.

Note 2 - things ae worse that I suspected.  Even after mounting the
Zip, writing gzipped-tar-files leads to LOSS OF DATA - using either
gzip standalone or "tar -zc".  I'm able to create a tar file, and
title it afterwards.  gzip appears to work (I get a .tgz file), but
it cannot be gunzipped.... file shows it as type data....

Comment 2 Michael K. Johnson 1999-07-30 14:55:59 UTC
I have changed the component to kernel because the corruption
indicates that it is a kernel (or hardware, but that's not likely
since it worked with 5.2) problem.  The fact that data is being
corrupted is probably why mount can't figure out the filesystem
type.  Are you getting any kernel messages in /var/log/messages
complaining about the hdb4 device?

Comment 3 thibaut.cousin 1999-08-17 12:44:59 UTC
This problem is a known bug corrected in kernel version 2.2.11. Just
upgrade...

------- Additional Comments From   08/24/99 14:13 -------
1999/08/24

Yes, upgrading to 2.2.11 fixed all my ZIP problems.  Thanks.