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