Leaving everything else the same, going back to hal-0.5.8.1 (plus patches from bug #9321 and bug #9385) fixes the problem. HAL now correctly reports /dev/hda1 being mounted on / again.

[zlatko@disclosure]:~$ lshal -l -u '/org/freedesktop/Hal/devices/volume_uuid_fba07673_06a6_4b48_9853_47aa25febc40'
udi = '/org/freedesktop/Hal/devices/volume_uuid_fba07673_06a6_4b48_9853_47aa25febc40'
  volume.unmount.valid_options = {'lazy'} (string list)
  volume.mount.valid_options = {'ro', 'sync', 'dirsync', 'noatime', 'nodiratime', 'noexec', 'quiet', 'remount', 'exec', 'data='} (string list)
  org.freedesktop.Hal.Device.Volume.method_execpaths = {'hal-storage-mount', 'hal-storage-unmount', 'hal-storage-eject'} (string list)
  org.freedesktop.Hal.Device.Volume.method_argnames = {'mount_point fstype extra_options', 'extra_options', 'extra_options'} (string list)
  org.freedesktop.Hal.Device.Volume.method_signatures = {'ssas', 'as', 'as'} (string list)
  org.freedesktop.Hal.Device.Volume.method_names = {'Mount', 'Unmount', 'Eject'} (string list)
  info.interfaces = {'org.freedesktop.Hal.Device.Volume'} (string list)
  volume.ignore = false  (bool)
  info.udi = '/org/freedesktop/Hal/devices/volume_uuid_fba07673_06a6_4b48_9853_47aa25febc40'  (string)
  volume.partition.flags = {'boot'} (string list)
  volume.partition.uuid = ''  (string)
  volume.partition.label = ''  (string)
  volume.partition.type = '0x83'  (string)
  volume.partition.scheme = 'mbr'  (string)
  info.product = 'Volume (ext3)'  (string)
  volume.partition.media_size = 120060444672  (0x1bf4290000)  (uint64)
  volume.partition.start = 32256  (0x7e00)  (uint64)
  volume.size = 246726144  (0xeb4be00)  (uint64)
  volume.num_blocks = 481887  (0x75a5f)  (int)
  volume.block_size = 512  (0x200)  (int)
  volume.partition.number = 1  (0x1)  (int)
  info.capabilities = {'volume', 'block'} (string list)
  info.category = 'volume'  (string)
  volume.is_partition = true  (bool)
  volume.is_disc = false  (bool)
  volume.linux.is_device_mapper = false  (bool)
  volume.is_mounted_read_only = false  (bool)
  volume.is_mounted = true  (bool)
  volume.mount_point = '/'  (string)
  volume.label = ''  (string)
  volume.uuid = 'fba07673-06a6-4b48-9853-47aa25febc40'  (string)
  volume.fsversion = '1.0'  (string)
  volume.fsusage = 'filesystem'  (string)
  volume.fstype = 'ext3'  (string)
  storage.model = ''  (string)
  block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_S00UJ10X303477'  (string)
  block.is_volume = true  (bool)
  block.minor = 1  (0x1)  (int)
  block.major = 3  (0x3)  (int)
  block.device = '/dev/hda1'  (string)
  linux.hotplug_type = 3  (0x3)  (int)
  info.parent = '/org/freedesktop/Hal/devices/storage_serial_S00UJ10X303477'  (string)
  linux.sysfs_path_device = '/sys/block/hda/hda1'  (string)
  linux.sysfs_path = '/sys/block/hda/hda1'  (string)

FWIW, I had switched to the GIT version after Danny's comment on bug #9321, and kept it at that since then. I've gone back to 0.5.8.1 + patches now, but I can move back to GIT again if necessary to help you with further debugging.

Looks like this is fixed already. Closing.

Reopening - hal-0.5.9.rc1 (04/Mar/07, same day as your comment) still shows the exact same behavior. If you think it has been fixed in a later GIT version, please let me know.

I'm not sure this is a HAL bug at all. Please let me know what distro + distro version you are using. Also please attach the contents of /proc/mounts.

Version info: Slackware-11.0, linux-2.6.20.2, udev-097, hal-0.5.9.rc1 (udev from Slackware, kernel and hal self-compiled).

[zlatko@disclosure]:~$ cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,data=writeback 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
tmpfs /dev tmpfs rw 0 0
devpts /dev/pts devpts rw 0 0
none /proc/bus/usb usbfs rw 0 0
/dev/hda3 /usr ext3 rw,data=writeback 0 0
/dev/hda5 /var ext3 rw,data=writeback 0 0
/dev/hda6 /opt ext3 rw,data=writeback 0 0
/dev/hda7 /home ext3 rw,data=writeback 0 0
/dev/hda8 /tmp ext3 rw,data=writeback 0 0
/dev/hda9 /usr/local ext3 rw,data=writeback 0 0
nfsd /proc/fs/nfs nfsd rw 0 0
automount(pid27794) /mnt/auto/nfs/airframe autofs rw,fd=5,pgrp=27794,timeout=60,minproto=2,maxproto=3,indirect 0 0
automount(pid27785) /mnt/auto/misc autofs rw,fd=5,pgrp=27785,timeout=60,minproto=2,maxproto=3,indirect 0 0
none /sys/fs/fuse/connections fusectl rw 0 0
[zlatko@disclosure]:~$ mount | grep hda1
/dev/hda1 on / type ext3 (rw,data=writeback)


[zlatko@disclosure]:~$ grep hda1 /etc/fstab
/dev/hda1   /               ext3       defaults,data=writeback         0   1


[zlatko@disclosure]:~$ grep hda1 /etc/mtab
/dev/hda1 / ext3 rw,data=writeback 0 0


[zlatko@disclosure]:~$ grep hda1 /proc/mounts


[zlatko@disclosure]:~$ grep " / " /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,data=writeback 0 0


The problem seems to be that /dev/hda1 doesn't show up anywhere in /proc/mounts. As I said, hal-0.5.8.1 didn't have this problem, so I guess something has been changed in the way hal parses /proc/mounts.

What is the output of 'ls -l /dev/root'? Thanks.

[zlatko@disclosure]:~$ ls -l /dev/root
ls: /dev/root: No such file or directory

Hmmm ... if this is indeed the root of the problem (bad pun intended ;-), then how come earlier versions of hal still detected the correct mount point just fine? AFAICT, /dev/root never existed on my system, neither as a symlink, nor as a plain block-major-4-0 device file (both of which seem to be possible variants according to /usr/src/linux/Documentation/devices.txt).

(In reply to comment #7)
> [zlatko@disclosure]:~$ ls -l /dev/root
> ls: /dev/root: No such file or directory
> 
> Hmmm ... if this is indeed the root of the problem (bad pun intended ;-),

Yup. It's a distro problem.

> then
> how come earlier versions of hal still detected the correct mount point just
> fine? AFAICT, /dev/root never existed on my system, neither as a symlink, nor
> as a plain block-major-4-0 device file (both of which seem to be possible
> variants according to /usr/src/linux/Documentation/devices.txt).

Earlier versions of HAL were broken in this regard.

Okay, I see. So, in order to fix the problem on my side, which of the two possible variants does hal prefer/expect - a symlink or a real block device (or is either one fine)? I'm thinking of either adding a udev rule to create the symlink (KERNEL=="hda1", SYMLINK+="root"), or adding it statically with 'mknod /lib/udev/devices/root b 4 0'.

(In reply to comment #9)
> Okay, I see. So, in order to fix the problem on my side, which of the two
> possible variants does hal prefer/expect - a symlink or a real block device (or
> is either one fine)? 

Either should be fine.

> I'm thinking of either adding a udev rule to create the
> symlink (KERNEL=="hda1", SYMLINK+="root"), or adding it statically with 'mknod
> /lib/udev/devices/root b 4 0'.

Manually adding rules to a single system to fix the distro bug seems not to be a forward looking solution. If it was me, I'd just complain to the OS vendor; the fix is really simple - all that need to happens is that the initramfs (who mounts rootfs) needs to create /dev/root and then after root is mounted it should 'mount --move /dev/ /sysroot/dev' before transitioning into rootfs on /sysroot.

Of course, there's a gazillion ways to do this, depends on your distro vendor. I'm not sure Slackware really cares much about HAL, most of the user bugs reported stems from Slackware users be it either things like this or ancient glibc versions. Asking Slackware to care more would be nice :-). Thanks.

I agree - but then again, Slackware doesn't even ship its own HAL package, so I doubt that this will be a high priority fix. ;-) Anyway, thanks for your help!