When inserting a USB flash key, sometimes hal does not create fstab entry.
This is load dependent. It only happens on older of my laptops. To reproduce,
I have to run Mozilla and do something to make a load; simultaneously insert
hald --verbose==yes yields wildly varying failure scenarios.
Sometimes it says "Ignoring hotplug event: no parent".
Sometimes everything seems good but hald does not
match 20-storage-add-selinux.fdi and 90-fstab-sync.fdi
Sometimes it works
/var/log/messages shows usb-storage complaining READ CAPACITY failing
with key/ASC/ASCQ == 6/28/0, which should be retried by SCSI stack.
This bug may be a dup (same root cause) of bug 157703, but for two things:
* 157703 deals with RHEL, so we need an extra bug to track,
* 157703 has different hald --verbose=yes output.
Adding David Zeuten to cc: as our HAL man.
Basic experiments were done with:
Linux version 2.6.12-rc4-nip (zaitcev@niphredil) (gcc version 4.0.0 20050512
(Red Hat 4.0.0-5)) #3 SMP Sat May 21 09:04:42 PDT 2005
Created attachment 114676 [details]
hald verbose, failed
This log has two types of failure (separate events)
"Ignoring hotplug event - no parent" and
not matching 90-fstab-sync.fdi
Created attachment 114677 [details]
hald verbose, succeded
This log is from the same kernel, without reboot, only running without X
to prevent battstat applet and gamin from stealing CPU cycles.
To be clear, Fedora kernel does exactly the same, only the poor 500MHz P6
is not fast enough to ever support hald --verbose=yes successfuly.
It only hotplugs correctly if hald is run with --daemon=yes
(and only sometimes).
[zaitcev@niphredil ~]$ cat /proc/version
Linux version 2.6.11-1.1323_FC4 (firstname.lastname@example.org) (gcc version
4.0.0 20050518 (Red Hat 4.0.0-7)) #1 Thu May 19 03:20:21 EDT 2005
[zaitcev@niphredil ~]$ cat /proc/cmdline
[zaitcev@niphredil ~]$ rpm -q hal
This looks rather strange - the output from comment 3 (with the failure) looks a
little bit like it's caused by the issue filed in bug 156167 as there are
hotplug events with sequence numbers 1070, 1072 and then 1071 processed in that
order. This looks wrong, are you using /sbin/udevsend as the hotplug
It's not exactly the same issue as in bug 156167 though but I think the root
cause is the same (timing, the sysfs event may fire too early) as hal is
complaining that there is no device symlink in /sys/block/sda/ and thus rejects
to probe for file systems etc.
Can you reproduce this with an earlier kernel than 2.6.12-rc3 or with the patch
from http://lkml.org/lkml/2005/5/19/146 ?
Btw, this is most likely different from bug 157703 as hal 0.5.x is very
different from hal 0.4.x (due to internal architectural changes) - the key
differences in 0.5.x are
a) we punt the hotplug event reordering to udev (thus requiring /sbin/udevsend
instead of /sbin/hotplug as the hotplug multiplexor) since udev needs to do this
anyway. In 0.4.x hald reorders the hotplug events itself.
b) much of the work is split into multiple hald processes so hald isn't put in
state D when bugs in e.g. usb-storage surfaces (in 0.5.x this is done by the
/sbin/udevsend is used (it's a stock Rawhide userland for FC4T2+).
I tested the Kai's patch and it appears to fix the problem.
Modified in 2.6.11-1.1340.
Kei's patch, just in case lkml.org dies:
@@ -248,6 +248,7 @@ int device_add(struct device *dev)
if ((error = kobject_add(&dev->kobj)))
+ kobject_hotplug(&dev->kobj, KOBJ_ADD);
if ((error = device_pm_add(dev)))
if ((error = bus_add_device(dev)))
@@ -260,14 +261,13 @@ int device_add(struct device *dev)
/* notify platform of device entry */
- kobject_hotplug(&dev->kobj, KOBJ_ADD);
+ kobject_hotplug(&dev->kobj, KOBJ_REMOVE);
Mass update of -test bugs to update version to fc4.
(Please retest on final release, and report results if you have not already done
Mass update to all FC4 bugs:
An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (220.127.116.11). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.
Please retest with this update, and update this bug if necessary.
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.
This is a mass-update to all currently open kernel bugs.
A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.
Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.
This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.
Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.
If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.
Closing per previous comment.