Description of problem: The SMART tool incorrectly displays SMART attributes of e.g. SSD disks. Version-Release number of selected component (if applicable): gnome-disk-utility-3.10.0-3.fc20.x86_64 How reproducible: every time Steps to Reproduce: 1. run gnome-disks 2. select a SSD disk, select SMART Data & Self Tests from the top-left ops menu 3. observe the SMART attributes in the new SMART Data & Self Tests window Actual results: 170 available-reserved-space 173 attribute-173 174 attribute-174 181 program-fail-count-total 183 runtime-bad-block-total 189 high-fly-writes 202 ta-increase-count 206 flying-height Expected results: 170 Grown_Failing_Block_Ct 173 Wear_Leveling_Count 174 Unexpect_Power_Loss_Ct 181 Non4k_Aligned_Access 183 SATA_Iface_Downshift 189 Factory_Bad_Block_Ct 202 Perc_Rated_Life_Used 206 Write_Error_Rate
The symptoms are the same as a libatasmart bug https://bugzilla.redhat.com/show_bug.cgi?id=1103179 I thought gnome-disks uses libatasmart, but ldd doesn't show it among the shared libraries---maybe it's linked statically. Does it link statically or share code? Anyway, the SMART attributes are unfortunately not standardized and the other SMART software, smartmontools, have a whole mechanism to report manufacturer/model specific parameter assignment. I am not sure whether it's better to duplicate it in libatasmart and/or gnome-disks, or rip out the current code and use smartmontools.
gnome-disk-utility uses udisks2 via D-Bus, which in turn depends on libatasmart. For feature requests, it is probably better to file a bug report upstream: https://bugs.freedesktop.org/enter_bug.cgi?product=udisks
Yes, udisks links libatasmart dynamically: $ ldd /usr/lib/udisks2/udisksd | grep atasmart libatasmart.so.4 => /usr/lib64/libatasmart.so.4 (0x0000003000800000)
This is not really a feature request---I consider this a bug in libatasmart and all tools using it. Originally, when I filed the libatasmart bug report https://bugzilla.redhat.com/show_bug.cgi?id=1103179 I only knew it from skdump tool. Since there is a a correctly functioning alternative, smartctl, and libatasmart development has been stagnant since 2012, I asked libatasmart author Lennart Potterling whether he feels that continuous development is worth the trouble. I understand that he's a busy guy, with systemd and pulseaudio and whatnot, so I wasn't surprised that he doesn't have the bandwidth to continue working on libatasmart. However, skdump is not the only user of this lib: repoquery --whatrequires libatasmart reports that it is used in kde-partitionmanager and udisks/udisks2 as well. I'll file at freedesktop.org as well. Again, the issue is whether to improve SMART parameter handling in libatasmart or retarget udisks/kde-partitionmanger to use smartctl.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
*** This bug has been marked as a duplicate of bug 1103179 ***