Bug 136971

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).

Retested with udev 039-6, same problem.

do you have a message in /var/log/messages about udev creating
/dev/hdb4 ???

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.

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.

reassigning to HAL

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).

Created attachment 106615 [details]
file requested by developer

Created attachment 106616 [details]
file requested by developer

terminal output while running hal as requested.

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.

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.

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

Thanks for your ps, David.  That indeed works for me and will make use
of the zip drive just fine.

Gerry

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. 

*** Bug 139719 has been marked as a duplicate of this bug. ***

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

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

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.

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.

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'".

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

> 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".

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

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