This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 3892 - Mount of Iomega Zip 100 fails after upgrade from 5.2
Mount of Iomega Zip 100 fails after upgrade from 5.2
Status: CLOSED NEXTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-07-03 23:32 EDT by sol0
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-08-25 18:53:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description sol0 1999-07-03 23:32:21 EDT
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-08 21:51:59 EDT
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 10:55:59 EDT
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 08:44:59 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.