Created attachment 440109 [details]
Output of skdump for /dev/sda

Output of skdump which is part of libatasmart is correct, thus, the bug is likely to be in udisks. Current version: udisks-1.0.1-4.fc14.x86_64.

Please attach the output of 'udisks --dump'

Created attachment 453403 [details]
Output of 'udisks --dump'

Please attach the output of

 udevadm info -q all -n /dev/sda

and

 strace /lib/udev/udisks-probe-ata-smart /dev/sda

Run both as root please.

Created attachment 453510 [details]
Output of 'udevadm info -q all -n /dev/sda'

Created attachment 453511 [details]
Output of 'strace /lib/udev/udisks-probe-ata-smart /dev/sda'

Weird. Try doing

 echo change > /sys/block/sda/uevent

and then attach 'udevadm info -q all -n /dev/sda' again... Also please check if the SMART data shows up now. Thanks.

Also please attach the output of 'mount' - I suspect you may have /usr on a separate filesystem?

Created attachment 453517 [details]
Output of 'udevadm info -q all -n /dev/sda'

After executing 'echo change > /sys/block/sda/uevent', an additional value is listed, namely

E: UDISKS_ATA_SMART_IS_AVAILABLE=1

$ mount
/dev/mapper/VolGroup00-LogVol00 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
/dev/sda2 on /boot type ext4 (rw)
/dev/mapper/VolGroup00-LogVol02 on /home type ext4 (rw)
/dev/mapper/VolGroup00-LogVol01 on /usr type ext4 (rw)
tmpfs on /tmp type tmpfs (rw,rootcontext="system_u:object_r:tmp_t:s0")
tmpfs on /var/tmp type tmpfs (rw,rootcontext="system_u:object_r:tmp_t:s0")
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
gvfs-fuse-daemon on /home/fedora/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=fedora)

After executing 'echo change > /sys/block/sda/uevent',  'udisks --dump' reports a different result for /dev/sda, too, namely

ATA SMART:                 Data not collected

instead of

ATA SMART:                 not available

(In reply to comment #12)
> After executing 'echo change > /sys/block/sda/uevent',  'udisks --dump' reports
> a different result for /dev/sda, too, namely
> 
> ATA SMART:                 Data not collected
> 
> instead of
> 
> ATA SMART:                 not available

Restarting the udisks daemon should show the data (killall udisks-daemon; sleep 5; udisks --show-info /dev/sda). Waiting 30 minutes should also do the trick.

(In reply to comment #11)
> $ mount
> /dev/mapper/VolGroup00-LogVol00 on / type ext4 (rw)
> proc on /proc type proc (rw)
> sysfs on /sys type sysfs (rw)
> devpts on /dev/pts type devpts (rw,gid=5,mode=620)
> tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
> /dev/sda2 on /boot type ext4 (rw)
> /dev/mapper/VolGroup00-LogVol02 on /home type ext4 (rw)
> /dev/mapper/VolGroup00-LogVol01 on /usr type ext4 (rw)

Yeah, you have /usr on a different fs than what / is on. That's exactly why things doesn't work. I don't know what the Fedora policy is here - but note that I'm not terribly interested in fixing such bugs - in my view it's a defect that the OS allows you to do that. But that may just be my view - I don't know what the Fedora policy is here.

(And, FWIW, I'm not terribly interested in discussing whether /usr on a separate FS is a good idea or not. I'm simply not going to reply to any of that because if I do I'm sure it will turn into some kind of holy discussion.)

(In reply to comment #14)
> (And, FWIW, I'm not terribly interested in discussing whether /usr on a
> separate FS is a good idea or not. I'm simply not going to reply to any of that
> because if I do I'm sure it will turn into some kind of holy discussion.)

This reply reminds me of the dangers of alcohol abuse at work ..

(In reply to comment #15)
> (In reply to comment #14)
> > (And, FWIW, I'm not terribly interested in discussing whether /usr on a
> > separate FS is a good idea or not. I'm simply not going to reply to any of that
> > because if I do I'm sure it will turn into some kind of holy discussion.)
> 
> This reply reminds me of the dangers of alcohol abuse at work ..

For the record, I take offense to abusive comments like that. Not only is it unprofessional, I'm also pretty sure that it violates some kind of Fedora code of conduct. Good luck.

As a result of related bug 626007, /usr will be removed from available mount points in anaconda-15.3-1.fc14.

Made my day. I'll send link to this ticket to my friends.

Is it possible to get some explanation on why it does it not work if /usr is on different fs than / since we need to document that behaviour somewhere ( wiki release notes )?

Also will it not work if other directory's are not on the same fs as / or does this only apply to /usr

Historically, /usr on a seperate spindle dates from days of yore whne disks were smal, expensive and performance bottlenecks. Sometime taoday /usr is ona seperate FS due to administrative preferences for space management and performance tuning.

It is not a "holy" sort of issue (like editor choice) but a real concern.  Don't bury your head in the sand on this one.

As David has mention he has no interest in participating in partition layout discussion regardless if they are historical or not which quite frankly is understandable since everyone seem to think their partition layout is the best one and discussion like that rarely reach some kind of conscious however he simply could have mentioned that the problem is this. 

udisks uses libatasmart and libatasmart lives in /usr/lib and udisks uses it from a udev hook utility which lives in /lib/udev  hence if you boot with seperate /usr this hook utility won't find libatasmart and thus it will not work.

As always I'm pretty sure patches are welcome since this is not high on the maintainer(s) list to fix.

(In reply to comment #17)
> As a result of related bug 626007, /usr will be removed from available mount
> points in anaconda-15.3-1.fc14.

Could you point to where this decision was debated so far or to any data about what fraction of the existing userbase mount /usr separately?  A decision like this to break with long-standing convention deserves wide debate to ensure it carries the majority of the community with it and it does not cause a disproportionately adverse impact on any important subset of the Fedora user base IMHO.

(IOW I fail to see how choosing not to fix the udisks bug here leads to some flexibility being removed from anaconda!)

He's probably referring to build anaconda-15.3-1.fc15 

Changelog * Mon Oct 18 2010 Chris Lumens <clumens> - 15.3-1
- Don't recommend /usr as a mount point anymore (#643640). (clumens

So you might need to check the anaconda list for that discussion.

Anyway this particular bug can simply be fixed by moving libatasmart to /lib.
(thou in the long run it does not resolve the underlying issue in general )

Ah, that says "recommend", not quite the same thing as preventing its use implied by comment #17.  I've no objection to recommending it no longer, I only object to withdrawing support for it.

I'm with G.Wolfe, and especially Jóhann and Alasdair on this one. RH always used to be /designed/ to have / on a separate filesystem from /usr (e.g. so it could be mounted read-only by thin clients). Therefore, anything needed for booting had to live on /. If libatasmart is now needed for boot, it should now live in /.

With no discussion or warning, the deprecation of a separate /usr (for full functionality, at least) appears to me to be ignorant of history and actual usage.

I agree, deprecation of a separate /usr without warning is not the way to go.  Moreover, this makes upgrading a pre-F14 system with a separate /usr to F14 less than straightforward.

I use the following workaround to get the S.M.A.R.T. info back in the gnome-disk-utility:
  # echo change > /sys/block/sda/uevent
  # udisks --ata-smart-refresh /dev/sda