Bug 136971 - Zip drive not handled
Zip drive not handled
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
:
: 139719 (view as bug list)
Depends On: 139939
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-24 10:27 EDT by Leon Stringer
Modified: 2013-03-05 22:41 EST (History)
3 users (show)

See Also:
Fixed In Version: 0.4.2-1.FC3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-01 18:12:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
file requested by developer (67.93 KB, text/plain)
2004-11-12 17:34 EST, Gerry Tool
no flags Details
file requested by developer (173.86 KB, text/plain)
2004-11-12 17:35 EST, Gerry Tool
no flags Details

  None (edit)
Description Leon Stringer 2004-10-24 10:27:54 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20040929 Epiphany/1.4.0

Description of problem:
(With the change to device management I'm not exactly sure where to
report this - apologies if it's the wrong place).

I have an internal 250MB IDE Zip drive. When I insert Zip disks Fedora
does not detect and mount these automatically unlike CD-ROM discs for
example.

I think this is a relatively serious issue as it worked fine in FC2 so
loss of this functionality (unless there's a good reason) represents a
backward step.

Note that I can mount Zip disks as root: mount -t vfat /dev/hdb4
/home/leons/zip/

Version-Release number of selected component (if applicable):
032-8

How reproducible:
Always

Steps to Reproduce:
1. Insert Zip disk into drive.


Actual Results:  No icon appears in desktop. Nothing mounted in /media
or /mnt. No changes to /etc/fstab.

Expected Results:  Icon on desktop.
Zip disk mounted at some point (presumably /media).

Additional info:

Details from /etc/sysconfig/hwconf:

class: FLOPPY
bus: IDE
detached: 0
device: hdb
driver: ignore
desc: "IOMEGA ZIP 250 ATAPI"
physical: 0/0/0
logical: 96/64/32
Comment 1 Leon Stringer 2004-10-24 10:32:28 EDT
I've just noticed the post on fedora-test-list and tried "/sbin/sfdisk
-R /dev/hdb" but there's still no hdb4 directory in /media (or /mnt).
Comment 2 Leon Stringer 2004-10-24 13:15:51 EDT
Retested with udev 039-6, same problem.
Comment 3 Harald Hoyer 2004-10-25 05:19:49 EDT
do you have a message in /var/log/messages about udev creating
/dev/hdb4 ???
Comment 4 Leon Stringer 2004-10-25 15:38:53 EDT
I booted with no Zip disk in drive and logged into desktop.

I inserted a Zip disk, nothing in /var/log/messages.

I ran /sbin/sfdisk -R /dev/hdb as root and the following appears in
/var/log/messages:

Oct 25 20:45:51 localhost kernel: hdb: 98304kB, 196608 blocks, 512
sector size
Oct 25 20:45:51 localhost kernel:  hdb: hdb4
Oct 25 20:45:52 localhost udev[3601]: creating device node '/dev/hdb4'
Oct 25 20:45:52 localhost 05-pam_console.dev[3602]: Restoring console
permissions for /dev/hdb4

There is no change to /media or /etc/fstab.
Comment 5 Gerry Tool 2004-11-11 09:32:00 EST
I am having similar problems in FC3 with a 100MB internal zip drive on
hdb.

My fstab entry (created by FC3) on an updated FC2 -> FC3 system is
/dev/hdb                /media/floppy           auto   
pamconsole,exec,noauto,managed 0 0

With a drive already inserted during boot, there is an icon for the
drive in "Computer".  If I click on it to mount the drive, I get a
Mount Error dialog saying "Unable to mount the selected volume".  If I
click on Show more details in the dialog, it says "mount: I could not
determine the filesystem type, and none was specified."

These disks have a vfat system installed on hdb4, and were always
mounted and worked fine in FC2 and previous releases.

I also have a fresh install of FC3 on another partition, and there is
no entry for my zip drive in its fstab.

I use the zip drive frequently enough that this is a serious bug to me.

Comment 6 Harald Hoyer 2004-11-12 04:42:42 EST
reassigning to HAL
Comment 7 David Zeuthen 2004-11-12 11:10:29 EST
I am not sure we can make this work with the state of the IDE driver
as it is today - please have a look at bug 130232 (it's for ide-cs but
it also applies to other IDE drives). 

The problem, in a nutshell, is that we cannot open the device to probe
for filesystems because that will trigger hotplug remove/add events.
Therefore, we cannot determine whether the media is partitioned or
not. E.g. we cannot determine whether we should add /dev/hdb4 or
/dev/hdb to the /etc/fstab file.

IIRC, earlier releases of Fedora Core just assumed non-partitioned
media which is clearly a bug. 

Anyway I want to confirm this is true, because if it's not we might be
able to fix it. Since I don't have this hardware handy please attach
the following information

1. Full output of lshal with the device attached.

and

2. The output of 'hald --daemon=no --verbose=yes'; please remember to
shut down the existing hald processing by 'service haldaemon stop'.
When hald is done probing (and while you still capture the output),
please attempt to do a 'blockdev --rereadpt /dev/hdb'.

I need this for both partitioned media (from Leon) and without
partitioned media (from Gerry).
Comment 8 Gerry Tool 2004-11-12 17:34:31 EST
Created attachment 106615 [details]
file requested by developer
Comment 9 Gerry Tool 2004-11-12 17:35:32 EST
Created attachment 106616 [details]
file requested by developer

terminal output while running hal as requested.
Comment 10 Gerry Tool 2004-11-16 09:11:34 EST
Some added info, comments:

My /etc/fstab has the following line on boot: (whether or not I have a
disk in the drive on boot)

/dev/hdb               /media/floppy           auto   
pamconsole,exec,noauto,managed 0 0

I cannot mount the drive manually or by right clicking on the drive
icon in 'Computer.'

If I edit fstab to append '4' to 'hdb', then I can mount the drive.

After reboot of course, my change to fstab has been rewritten to the
original non-working form.

If I have a disk in the drive on boot:
During boot, the following lines appear on the screen:
Creating root device
 hdb: hdb4
During shutdown, the following lines appear on the screen:
Unmounting file system
 hdb: hdb4
 
If there is no disk in the drive on boot, those messages do not
appear, but if I insert a disk during operation after making the above
change to fstab, I can mount the drive.  

There is also lack of consistency between fstab and the labeling in
'Computer'

My zip drive is listed as /media/floppy and my regular 1.44MB floppy
drive is listed as /media/floppy1 in fstab.  In 'Computer', the label
for the zip drive is 'Floppy Drive (2)' and for the 1.44MB floppy is
'Floppy Drive'.  This isn't a big deal, but leads to confusion.

Handling of internal zip drives has really regressed in the current
version of FC.  I really don't see why something that has always
worked cannot be made to work again.
Comment 11 Gerry Tool 2004-11-16 10:06:37 EST
Added info:
Comment #10 is my experience with an install that was originally FC2
upgraded to FC3 by anaconda.

On an install that was a fresh anaconda install of FC3, the fstab
entry for hdb disappears altogether on a reboot.  Hardware monitor
shows /dev/hdb as an IOMEGA ZIP 100 ATAPI.  The drive had a disk in it
on this boot. There is no /media/floppy1 now, either.  If I add a line
to fstab for /dev/hdb4 and save it AND create /media/floppy1, the
drive will mount.
Comment 12 David Zeuthen 2004-11-16 15:42:23 EST
Hi,

Attachment in comment 9 confirms that IDE subsystem is still emitting
hotplug add/remove whenever the last opener closes the device.

So, as stated in comment 7 the really good reason this isn't working
is caused by the IDE subsystem going crazy (bug 130232) and causing
hotplug remove/add. For instance this is when hald (your output from
comment 9) starts up:

 11:19:21.210 [I] linux/osspec.c:785: handling /sys/block/hdb block
 11:19:21.233 [E] linux/common.c:700: /usr/bin/udevinfo returned 60672
 for /block/hdb

meaning "there is no device node /dev/hdb for /block/hdb (e.g. first
slave IDE device". This is most probably caused by the fact that
something (not hal, we specifically don't open IDE devices) is trying
to open the device and hal just called udevinfo at the wrong time.

This is a regression (caused by the 2.6 kernel and a dynamic /dev),
yes, and it won't get fixed until the IDE system is fixed, sorry.
Making bug 130232 block this bug, so we don't forget to fix hal when
the IDE subsystem is fixed.

ps. : You may just manually add this entry

/dev/hdb4               /media/floppy           auto   
pamconsole,exec,noauto 0 0

to /etc/fstab. Note that 'managed' is not included, thus
hal/fstab-sync wont remove it. Hope this helps.

Thanks,
David
Comment 13 Gerry Tool 2004-11-16 16:22:29 EST
Thanks for your ps, David.  That indeed works for me and will make use
of the zip drive just fine.

Gerry
Comment 14 Alan Cox 2004-11-16 17:42:43 EST
Why isn't the hal/udev stuff *assuming* there may be partitions on the
device if it doesn't know. It seems rather brain dead to asusme none.
If you generated the hda1-15 values on the basis you didn't know it
would just work.

It's a hardware limitation. Hal needs to be sensible about the
situation. There are no plans to fix the IDE layer if it is even
possible to fix. 
Comment 15 David Zeuthen 2004-11-23 11:02:21 EST
*** Bug 139719 has been marked as a duplicate of this bug. ***
Comment 16 David Zeuthen 2004-11-23 11:07:41 EST
OK, I think I have fixed this bug (took me quite some time to locate
an IDE Zip drive, FWIW) - please test.

Remember to remove existing lines you put in /etc/fstab, cf. comment
12). Also manually fix  the file /etc/udev/rules.d/50-udev.rules as
detailed in bug 139939. Then install and rebuild this SRPM 

http://people.redhat.com/davidz/hal-cvs20041122/hal-0.4.1.cvs20041122-1.src.rpm

and install the resulting four RPMS (I've put i386 and ppc RPMS in the
same directory) and restart the haldaemon. You should know have an
entry /media/zip in your /etc/fstab that points to the right device file.

You may note that the icons are wrong in GNOME - this will be
addressed in a gnome-vfs2 update.

Thanks,
David
Comment 17 Gerry Tool 2004-11-23 21:09:44 EST
Hi David,
Unfortunately, this arrives on the first day of a week I'm away from
home.  When I return I will do this and respond.
Thanks.  Gerry
Comment 18 David Zeuthen 2004-12-02 17:23:17 EST
Btw, you will need a new udev to make sure this works when booting
without media in the drive. You may look at bug 139939 as that
contains the fix.
Comment 19 Gerry Tool 2004-12-03 09:57:17 EST
I updated to hal-0.4.2-1.FC3 and made the changes to
/etc/udev/rules.d/50-udev.rules that you specified.  The zip drive now
works, both when present at boot and when inserting after boot.

Thanks for the fix.
Comment 20 Leon Stringer 2004-12-13 16:41:15 EST
As the original reporter I thought I'd say "thanks, it works for me
too" and also apologize for being off line after the initial post.

However... (without wishing to seem ungrateful) the eject
functionality doesn't work. Should I open that as a new bug? I get
"eject: unable to open `/dev/hdb4'".
Comment 21 Vaclav Bucha 2005-01-20 18:33:42 EST
Hello,
I am using updated FC3.
kernel-2.6.10-1.741_FC3
udev-039-10.FC3.6
hal-0.4.5-1.FC3

I have still a small problem with mounting
IOMEGA ATAPI ZIP 250MB drive.
I use 3 mount points for 3 file system types for many years
(RH6.1..7.2) with no problems.
/dev/hdd4   /zip     ext2    defaults,user,noauto  0      0
/dev/hdd4   /i       msdos   defaults,user,noauto  0      0
/dev/hdd4   /ivfat   vfat    defaults,user,noauto  0      0

Problem in FC3 is that after each boot of the system only the first
mount command, e.g. mount /zip causes error:
mount: /dev/hdd4 is not a valid block device

All subsequent mount /zip (umount /zip) commands work perfectly.
This problem does not occur when I boot with ZIP disk inserted.

I do not like automatic "icon mounting" so I hope there is
a way how to solve my problem. I found a problem to determine
the filesystem type of the inserted disk when using
/dev/hdd4   /media/zip1 auto  pamconsole,exec,noauto,managed 0 0

Thank you. Vaclav Bucha
Comment 22 David Zeuthen 2005-01-20 19:38:21 EST
> Problem in FC3 is that after each boot of the system only the first
> mount command, e.g. mount /zip causes error:
> mount: /dev/hdd4 is not a valid block device
>
> All subsequent mount /zip (umount /zip) commands work perfectly.
> This problem does not occur when I boot with ZIP disk inserted.

That's because /dev is now dynamic thanks to udev. If you do
a 'blockdev --rereadpt /dev/hdd' before mounting then the
kernel will create /dev/hdd4.

> I do not like automatic "icon mounting" so I hope there is
> a way how to solve my problem. I found a problem to determine
> the filesystem type of the inserted disk when using
> /dev/hdd4   /media/zip1 auto  pamconsole,exec,noauto,managed 0 0

Just double-click on the icon in Nautilus and you should be
all set. Alternatively, just manually add you entries for
/dev/hdd4 if you don't want it to "just work".
Comment 23 Vaclav Bucha 2005-01-21 18:50:29 EST
I am sorry for incomplete specification of the problem in comment 21.
/dev/hdd4 is created in both cases, boot with or without ZIP disk
inserted (checked with ll /dev/hdd*). Why the first mount command
after boot without ZIP disk inserted ignores /dev/hdd4 that really exists?
Thank you for your help. Vaclav
Comment 24 Vaclav Bucha 2005-01-31 14:45:56 EST
Please, is there an answer to my question in comment 23. I shall
repeat it. Why the first mount command after boot without ZIP disk
inserted 
ignores /dev/hdd4 that really exists? Vaclav

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