Description of problem: I have ultraportable laptop HP Omnibook 500 with floppy in docking station. When updfstab was used, it did not detect floppy on undocked laptop. Now hal thinks that floppy is present even whan laptop is undocked, device is present in "Computer" window and it produces huge delay if somebody tries to "open" it. Floppy icon was not available on this laptop in all previous versions of redhat linux (since fall 2001) and fedora core. Version-Release number of selected component (if applicable): 0.2.98.cvs20040923-1 How reproducible: always
Hi, please include the information mentioned here http://freedesktop.org/Software/HalTraces Remember to shutdown the hal daemon by running 'service haldaemon stop' as root. Thanks, David
Created attachment 104433 [details] output of hald --daemon=no --verbose=yes
Created attachment 104434 [details] lshal output
Thanks for the traces. Apparently the kernel seems to believe there is a floppy drive since /sys/devices/platform/floppy0 exists. I don't have such a directory when my laptop has the DVD-ROM/LS-120 combo so I'm a bit surprised. Do you have a /sys/block/fd0 directory? If you don't perhaps hal should check this as well. Btw, the support for legacy floppy drives in sysfs isn't the best but someone is working on it http://freedesktop.org/pipermail/hal/2004-September/001000.html but this is not going to make FC3.
If you can open the device, you can do checks to see if it's actually attached.
comment 5: like open(2) returning ENODEV? Won't that spin up the drive, btw? Thanks, David
[leon@omnibook fd0]$ LANG=C ls -l /sys/block/fd0 total 0 -r--r--r-- 1 root root 4096 Sep 29 2004 dev drwxr-xr-x 3 root root 0 Sep 29 2004 queue -r--r--r-- 1 root root 4096 Sep 29 2004 range -r--r--r-- 1 root root 4096 Sep 29 2004 removable -r--r--r-- 1 root root 4096 Sep 29 2004 size -r--r--r-- 1 root root 4096 Sep 29 2004 stat
This laptop's bios is able to emulate legacy floppy drive if usb floppy is attached. It may be a reason. But updfstab somehow detects that drive is absent.
Leonid, thanks for the information. Notting: how does kudzu/updfstab test for this using /dev/fd0? I don't have the hardware to test so I want to play it safe and make hal do exactly the same thing. Thanks, David
I'm ready to do any tests with hal/updfstab on this laptop if it could help.
open doesn't necessarily spin up the drive. char path[32], name[32]; struct floppy_drive_struct ds; int x, fd, rc; for (x = 0; x < 3; x++) { snprintf(path, 31, "/dev/fd%d", x); fd = open(path, O_RDONLY|O_NONBLOCK); if (fd < 0) ... no drive here ... break; ioctl(fd, FDRESET, NULL); rc = ioctl(fd, FDGETDRVTYP, name); if (rc || !name || !strcmp(name, "(null)")) { .... no drive here ... close(fd); break; } rc = ioctl(fd, FDPOLLDRVSTAT, &ds); close(fd); if (rc) ... no drive here ... break; if (ds.track < 0) ... drive is not actually there ... else ... you have a drive }
Hi, Sorry for the lag. This should be fixed in hal-0.4.0-2 which is now available in Rawhide. This actually did happen with my new Thinkpad T41 and I've also tested it on a desktop system. Feel free to reopen this bug if it doesn't work for you. thanks, David
I've installed hal-0.4.0-3 - there is no entry for floppy in /etc/fstab even when laptop is docked :( floppy works if I mount it manually.
*** Bug 135976 has been marked as a duplicate of this bug. ***
OK, this is an easy fix. The default policy in /usr/share/hal/fdi/90defaultpolicy/storage-policy.fdi should include these three lines <match key="storage.bus" string="platform"> <merge key="storage.policy.should_mount" type="bool">true</merge> </match> after line 33 (near the match on "sata", "ide" and so on). Will build this into Rawhide today.
Indded, a fix from comment #15 works-for-me. There is one catch, though. If I boot with both a USB floppy and a regular floppy then the first is /media/floppy and the other one is /media/floppy1. If I will attach a USB floppy only after a machine was booted then this is the other way around. Where is this controlled? It seems that "built-in" devices should have precedence over those which may show up, or not, on some bus or they will be "jumping" around depending on how things were booted. An order in storage-policy.fdi does not seem to matter.
> Indded, a fix from comment #15 works-for-me. Nice, thanks for testing it. > There is one catch, though. If I boot with both a USB floppy and > a regular floppy then the first is /media/floppy and the other > one is /media/floppy1. If I will attach a USB floppy only after > a machine was booted then this is the other way around. > > Where is this controlled? It seems that "built-in" devices should > have precedence over those which may show up, or not, on some bus > or they will be "jumping" around depending on how things were > booted. > An order in storage-policy.fdi does not seem to matter. The default policy doesn't guarantee stable mount point names for optical drives or floppy drives, sorry. You should be able to match your USB floppy drive with a .fdi file in 95userpolicy though and set storage.policy.desired_mount_point_name to e.g. usbfloppy. You will, however, get stable mount point names for partitioned media when the label meets certain criteria (exists; being ASCII and not a fully qualified path; label not already occupied). Thanks, David
> You should be able to match > your USB floppy drive with a .fdi file in 95userpolicy though and > set storage.policy.desired_mount_point_name to e.g. usbfloppy. Ah, more "undocumented black magick". Neither 'man fstab-sync' nor http://freedesktop.org/~david/hal-0.2/spec/hal-spec.html mention anything about 'storage.policy' and even less about 'desired_mount_point_name'. Grepping through /usr/share/hal/fdi brings some examples, though. But looking at these I believe that if I will figure out what "match your USB floppy drive" may mean in the context then I probably need something like <merge key="storage.policy.desired_mount_point" type="string">usbfloppy</merge> and nothing with "_name". Definitely something for Aunt Tilly. :-)
> Ah, more "undocumented black magick". > Neither 'man fstab-sync' nor > http://freedesktop.org/~david/hal-0.2/spec/hal-spec.html mention > anything about 'storage.policy' and even less about > 'desired_mount_point_name'. Grepping through /usr/share/hal/fdi > brings some examples, though. Get the facts here: http://freedesktop.org/~david/hal-spec/hal-spec.html and I think I also gave you that link of fedora-test-list. Also try out hal-device-manager to get a picture of what is happening. > But looking at these I believe > that if I will figure out what "match your USB floppy drive" may > mean in the context then I probably need something like > > <merge key="storage.policy.desired_mount_point" > type="string">usbfloppy</merge> > You want to match on storage.bus and storage.drive_type before merging that property. > and nothing with "_name". Whatever - I was citing from memory. > Definitely something for Aunt Tilly. :-) Perhaps Aunt Tilly doesn't care about having stable mount point names. She simply clicks the icon named "External Floppy Drive" in computer:/// in Nautilus. David
> Get the facts here: > http://freedesktop.org/~david/hal-spec/hal-spec.html 'man fstab-sync' explicitely refers a reader to http://freedesktop.org/Software/hal and the only spec link under this url sends to http://freedesktop.org/~david/hal-0.2/spec/hal-spec.html > and I think I also gave you that link of fedora-test-list Possibly. Expecting that a system user will be trawling through archives of fedora-test-list for an unexpected morsel of information is hardly realistic or constructive. > Perhaps Aunt Tilly doesn't care about having stable mount point > names. Perhaps. If her nephew wrote her a script which does something important to her, and for which she got a new launcher or an icon to click upon and/or this is running from cron, she might care if that script happens to use that name. Contrary to what you may imagine this is a pretty frequent situation. Substitute "a small business outfit with no real expert around" for "Aunt Tilly". Not everybody "only clicks". If you will say that I can write that script in some other way then indeed _I_ can. But if it there for many years then it is not likely the the code will expect a floppy to move around. In case if you wonder if somebody writes scripts which depends on floppies then, regardless how strange that may sound, I actually did and it was a "business operation critical". No kidding.
This should be fixed in hal-0.4.0-4.
Re: comments #20 - #16 I think having the named mountpoints explicitly seperated by bus in default settings for floppies makes sense to me and is consistent i think with the fallback storage policy for "disks." For whatever reasons the fallback storage policy for disks is, the same reasons could be applied to other storage devices. usbfloppy for usb floppy devices seems like a reasonable default to me, similar to idedisk and usbdisk. I'd also have to wonder about if its worth seperating cdrecorders explicitly by bus as well. I'm not so sure AT cares either way, about what the specific mountpoints are. But there are certainly going to be lots of niche automation cases that will care about somewhat predictable mountpoints at boot for non-hotplugged devices. Hotpluggable buses like usb and firewire are a real pain in the ass in terms of predictability. I certaintly don't expect to the numerical ordering of usb devices to be predictable at boot. But I would much prefer having the devices on more "static" buses be isolated from the lottery inherent in usb device ordering. So what's the downside to seperating out floppy mountpoints by bus type? But this brings up a thought i had. Is there room here for a tool that can "freeze out" a specific fstab entry and mountpoint for a unique device and create a policy definition without the user having to build the xml by hand? Say i want my usbstick to have a specific fstab entry associated with a specific mountpoint name. Would it be possible to build a tool that i could run once i had my fstab entry configured and my mountpoint created that could turn my configured settings into a hal policy definition for that device? -jef
Using stuff like /media/usbfloppy and /media/floppy would violate FHS2.3, sorry (though I personally would appreciate it). Perhaps it would also be good to have some more examples in /usr/share/doc/hal-@VERSION@/conf? Btw, if you want stable mount point names for partitioned media you can just label the filesystems and ensure that the label is a) ASCII and b) doesn't specify an absolute path. Then fstab-sync will take the label and massage it by replacing non-digits and non-letters with _. For example, on my Powerbook running Fedora I have /media/Mac_OS_X_Disk which is added as an HFS+ partition. This, for me (but I wrote it so my judgement is probably impaired) should be clear from /usr/share/hal/fdi/90defaultpolicy/storage-policy.fdi I'd hope? Perhaps that file should start with a short textual presentation of the policy it contains? Cheers, David
While there is now an entry in fstab for the floppy (with pamconsole parameter??) still shows " no fstab entry" when one tries to mount floppy. Still nothing for the zip drive in fstab. Using kernel 624 and latest hal and udev.
> While there is now an entry in fstab for the floppy (with pamconsole > parameter??) still shows " no fstab entry" when one tries to mount > floppy. What exactly does this mean? What does the /etc/fstab look like? Thanks, David
Tried again; floppy now accessible in both KDE and Gnome (KDE was problem) fstab: # This file is edited by fstab-sync - see 'man fstab-sync' for details LABEL=/ / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 /dev/hda5 swap swap defaults 0 0 /dev/hda1 /mnt/windows vfat auto,umask=0 0 0 /dev/hdc /media/cdrecorder iso9660,udf pamconsole,ro,exec,noauto,managed 0 0 /dev/fd0 /media/floppy auto pamconsole,exec,noauto,managed 0 0
In comment #17 David Zeuthen wrote: > You should be able to match > your USB floppy drive with a .fdi file in 95userpolicy though and set > storage.policy.desired_mount_point_name to e.g. usbfloppy. so I decided to give that a try and added a file in 95userpolicy directory with the following contents: <?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- --> <deviceinfo version="0.2"> <device> <match key="info.product" string="USB Floppy Drive"> <merge key="storage.policy.desired_mount_point" type="string">usbfloppy</merge> </match> </device> </deviceinfo> If I guess (the only option) things correctly this should "match". 'hal-device-manager' indeed shows up for that USB floppy a new key "storage.policy.desired_mount_point" with a value "usbfloppy" so it seems that I "matched". But after /etc/fstab was redone by fstab-sync a mount point for this device is once again either /media/floppy or /media/floppy1, depending on circumstances. Do I miss something here or this is another bug? BTW, if I will load above into emacs trying to edit it then emacs goes into SGML-mode, like requested, but for this to be useful one needs to load DTD. There is /usr/share/hal/fdi/fdi.dtd but trying to validate that I get: cd /usr/share/hal/fdi/ nsgmls -s fdi.dtd nsgmls:fdi.dtd:5:2:E: "ELEMENT" declaration not allowed in prolog nsgmls:fdi.dtd:6:2:E: "ATTLIST" declaration not allowed in prolog nsgmls:fdi.dtd:10:2:E: "ELEMENT" declaration not allowed in prolog nsgmls:fdi.dtd:12:2:E: "ELEMENT" declaration not allowed in prolog nsgmls:fdi.dtd:13:2:E: "ATTLIST" declaration not allowed in prolog nsgmls:fdi.dtd:20:2:E: "ELEMENT" declaration not allowed in prolog nsgmls:fdi.dtd:21:2:E: "ATTLIST" declaration not allowed in prolog nsgmls:fdi.dtd:24:2:E: end of document in prolog Once again it looks that I miss something here.
OK, matching on info.product is not the best thing since it varies across different hardware and is generic; matching on storage.model, which assumes the same value but only for storage devices, would be better. Also, my Lacie USB Floppy Drive has storage.model set to "USB-FDU". But you can do this so it works on all USB floppy drives by matching on the storage.bus and storage.drive_type properties; does this .fdi file work you you? <?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- --> <!-- Use 'usbfloppy' for USB floppy drives --> <deviceinfo version="0.2"> <device> <match key="storage.bus" string="usb"> <match key="storage.drive_type" string="floppy"> <merge key="storage.policy.desired_mount_point" type="string">usbfloppy</merge> </match> </match> </device> </deviceinfo> It works for me; I'm getting this entry in /etc/fstab /dev/sda /media/usbfloppy auto pamconsole,fscontext=system_u:object_r:removable_t,exec,noauto,managed 0 0 Cheers, David
> does this .fdi file work you you? The one from a comment #28 indeed does work for me. Thanks! I understand that in general matching on info.product may be not the best way to do that. Still in that particular case I am experimenting with this is a unique key so one would think that this we would be good enough. This clearly is not the case. Even copying into my previous version <match key="storage.drive_type" string="floppy"> ... </match> does not help. Obviously something else is going on here which is not easy to fathom. In playing with the above make sure that there are no /media/floppy* entries before fstab updates or you may end up with something like /media/floppy2 for your regular floppy. A visible difference between the cases in 'hal-device-manager' display is that "storage.policy.desired_mount_point" moved down from a "USB Floppy Drive" level to that of "USB-FDU". It appears that this matters but why? Doesn't everybody finds a name 'hal-device-manager' exceedingly funny? It "manages" in the same sense as 'cat' manages a content of a file. And one more thing. Can we have examples, likely the best place in 'man fstab-sync', of a "manual" usage of that program? It is very far from clear what in that context "UDI" can be and and expansion to "Unique Device Identifier" still does not explain that much. It is not unthinkable that one would want to invoke 'fstab-sync' in some shell scripts, for example.
> > does this .fdi file work you you? > > The one from a comment #28 indeed does work for me. Thanks! Cool. > I understand that in general matching on info.product > may be not the best way to do that. Still in that particular case > I am experimenting with this is a unique key so one would think > that this we would be good enough. Are you sure about that? try attaching the output of lshal with your USB floppy drive plugged in and we'll see. > This clearly is not the case. > Even copying into my previous version > > <match key="storage.drive_type" string="floppy"> ... </match> > > does not help. Obviously something else is going on here which > is not easy to fathom. Let's see what lshal says. > In playing with the above make sure that there are no /media/floppy* > entries before fstab updates or you may end up with something like > /media/floppy2 for your regular floppy. fstab-sync --clean cleans all entries in /etc/fstab if they are not mounted. This is done when the hal daemon starts (as stated in the man page IIRC). Since the option 'noauto' is added practically all entries ever generated by fstab-sync is deleted on bootup since they are not mounted. Part of the bootstrap process for the hal daemon adds new entries. > A visible difference between the cases in 'hal-device-manager' > display is that "storage.policy.desired_mount_point" moved down > from a "USB Floppy Drive" level to that of "USB-FDU". It appears > that this matters but why? Need lshal output. > Doesn't everybody finds a name 'hal-device-manager' exceedingly > funny? It "manages" in the same sense as 'cat' manages a content > of a file. Certainly; that's why this (crappy; I know, cause I wrote it in like two days :-) program is not installed by default and it doesn't show up in any GUI. It is more or less unsupported. For FC4 we have plans to write a real kick-ass gnome-device-manager program that indeed lets you manage, configure and troubleshoot your hardware and even, perhaps, provide those nasty bubbles you know from other operating systems :-). But that is blue sky right. Nonetheless, h-d-m is very useful for learning about the vast amount of information that HAL exports as properties. Which is nice. And that is why the hal-gnome package still exists. > And one more thing. Can we have examples, likely the best place > in 'man fstab-sync', of a "manual" usage of that program? It is > very far from clear what in that context "UDI" can be and and > expansion to "Unique Device Identifier" still does not explain > that much. This is in the hal spec which will be included in hal-devel in due time (hopefully for FC3; once I figure out how to build it in Beehive :-). At that time the manual page for fstab-sync will point to that package and fs location of the spec. One thing to keep in mind is that fstab-sync is just a simple policy agent for modifying the /etc/fstab file; it is not totally unlikely this may go away one in favour of a policy mount wrapper that just takes a HAL UDI (then checks if it's ok to mount; creates the mount point; then mounts; all in one go). One argument for such a wrapper is that it is invoked in the users desktop session; hence we can popup dialogs for stuff like passworded media etc. This is also blue sky.. Unfortunately too much software depends on the /etc/fstab file and we would need to patch that software to ask HAL about the devices. Examples of this includes the GNOME and KDE desktops, Mozilla, OpenOffice.org, Java etc. etc. And that is a lot of work. > It is not unthinkable that one would want to invoke > 'fstab-sync' in some shell scripts, for example. I can't see at this point why this should ever ever be needed but, hey, it's your computer and you can write any shell script you want :-) Cheers, David
Created attachment 105534 [details] An output for lshal for a machine with a USB floppy > try attaching the output of lshal with your USB floppy drive plugged in > and we'll see. OK, if you want to see the whole thing. :-) 'lsusb' shows at this moment Bus 005 Device 001: ID 0000:0000 Bus 004 Device 002: ID 054c:002c Sony Corp. Bus 004 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 Bus 002 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000 with this "Sony Corp." beeing that "USB Floppy Drive" and the rest are hubs. So the machine is not crawling with USB devices after all. OTOH 'lshal' indeed reports two entries, with UDIs '/org/freedesktop/Hal/devices/usb_usb_device_54c_2c_501_-1_noserial_0' '/org/freedesktop/Hal/devices/usb_device_54c_2c_501_-1_noserial' where a string "USB Floppy Drive" occures. It is still clear that both refer to the same physical device and "info.product = 'USB Floppy Drive'" is unique to the second one. Why one of these is preferable to another is still to me a mystery. > > It is not unthinkable that one would want to invoke > > 'fstab-sync' in some shell scripts, for example. > I can't see at this point why this should ever ever be ... Me too at this moment but my crystal ball was sent for warranty repairs. Maybe I would wish for some device to temporary "disappear" for some reasons?
> It is still clear that both refer to the same physical device and > "info.product = 'USB Floppy Drive'" is unique to the second one. > > Why one of these is preferable to another is still to me a mystery. Go read the USB standard; basically it comes down to that you may have N>=1 interfaces for each USB device. It's gets fun when you consider that a USB device also have configurations which may add/remove/change interfaces depenedent on e.g. when it's buspowered or powered by itself. Add to this that the metal (e.g. the enclosure we humans see as the device) might expose several USB devices and perhaps even a USB hub and it's more funny. Such is life. Basically you are assuming that info.product is unique when it's not; where do you read that it should? The only thing the hal spec says is that it's something that can be used to represent the name of the device object. Perhaps you are confused about all the various devices exported by HAL, I know I am at some time even though I wrote this. The only really 'interesting' devices are those with ''Functional Properties'' like storage.* volume.* on them; the rest is just glue. Just glue. For instance, a hal device object representing a SCSI Host emulation software object deep in the kernel is just not interesting. But it is needed to glue the interesting parts together: the USB device (and USB Mass Storage Interface on that device) and the block device abstractions spawned from that one. Anyway, FWIW, info.product is a property made up in HAL such bus-dependent guesses on where from the metal it comes from. So for PCI devices it comes from the PCI product id that we translate via /usr/share/hwdata/pci.ids, for USB devices from the USB vendor ID and so on. This abstraction is useful, e.g. we reduce the 'switch-on-bus-and-take-either-usb.product-or-pci.product. And this is useful as we may introduce a new bus type at any point in time and then we don't want to recompile said programs that does their own switch. I hope this clarifies.
> Basically you are assuming that info.product is unique when it's not; > where do you read that it should? I only said that info.product is unique __on that particular installation__ and, so far, it does not "should"; it simply is. It appears that this is not good enough contrary to what one may naively expect. That is why I originally had some doubts what "match" may mean and it turns out that I was right in that. It is only natural that various things become "obvious" after you were developing them for a longer while; for the rest of us this still looks like a guessing game.
> > It is not unthinkable that one would want to invoke > > 'fstab-sync' in some shell scripts, for example. > I can't see at this point why this should ever ever be needed It came to my mind at least one natural scenario when you may want to use such script. Undoubtedly there will be more. Assume that we have a machine with multiple CD (or DVD) readers. Not so frequent in a desktop situation but very far from unheard of for data servers. It is quite likely that you want to keep consistent mount points for these devices and, for whatever reasons, you may not want to take out that farm from a 'hal' management. You may have, oh well, say a dozen of these. It seems that to ensure a consistent naming now and in the future, with all possible software changes which may affect a scan order, etc., etc., you may want to 'fstab-sync -r ...' all these devices on a startup and 'fstab-sync --add=$udi' them back following a fixed UDI list. If one could pass to 'fstab-sync' also as an argument a value for 'storage.policy.desired_mount_point', instead of editing files in /usr/share/hal/fdi/95userpolicy, that would be nice bonus. Think about some of these devices breaking which may require temporary or permanent rearrangements. Yes, yes, we know that "desired" does not mean "assured".