When running kernel-6.10.3-200.fc40 (currently going to stable), the last 5 entries in the gnome-disks menu (starting with "SMART Data & Self-Tests...") are grayed out. When running 6.9.12, only the last 2 entries are grayed out, as expected. The "smartctl -a /dev/sda" command shows the information which is now inaccessible to gnome-disks. Reproducible: Always
I tried running gnome-disks from the command line after su'ing to root with "su -" but the result is the same.
Checked on 3 machines with clean F40 x86_64 Workstation installs, the result is the same. Pretty much the only thing they have in common is that they're all old BIOS-only machines.
Same behavior in my 41 Branched guest. Changing Version to 41. gnome-disk-utility-46.0-2.fc41.x86_64
Proposing as 41 Final Blocker according to https://www.fedoraproject.org/wiki/Fedora_41_Final_Release_Criteria#Default_application_functionality : "Additionally, for Fedora Workstation on the x86_64 architecture, all applications installed by default which can be launched from the Activities menu must meet this requirement."
The current F41 kernel is 6.11.0-0.rc3.30.fc41. As mentioned above, in F40 this last worked with the last stable 6.9 kernel (6.9.12) and failed with the first stable 6.10 kernel (6.10.3) and is still broken in F41 with its 6.11 kernel.
Just noticed that if I plug a portable HDD into my F40 box, I get the SMART data for it from gnome-disks. Just not the internal HDD from any of my machines (and an internal SSD from a laptop).
Just noticed that with the portable HDD, though I get the SMART data using gnome-disks, I do NOT get it from smartctl -a. With the internal drives, that's reversed, I get the SMART data from smartctl -a but not gnome-disks.
In response to the invitation of mr.Robatino There really seems to be some problem that is not fatal to system. Using DBus I loop through all available blok devices to check access to them. Participating devices are: 1) usb flash drive 2) sata sdd connectet via usb 3) sata hdd connectet via usb 4) sata nvme connectet via usb 5) sata ssd 6) sata hdd 7) nvme 8) dvd/cd kernel 6.10.4 blok_device : /dev/sdc name : PCIe SSD ata drive accsess : 0 nvme drive accsess : 0 blok_device : /dev/sdb name : WDC WD5000AAKX-22ERMA0 ata drive accsess : 0 nvme drive accsess : 0 blok_device : /dev/sda name : Samsung SSD 850 PRO 256GB ata drive accsess : 0 nvme drive accsess : 0 blok_device : /dev/sdf name : DataTraveler 3.0 ata drive accsess : 0 nvme drive accsess : 0 blok_device : /dev/nvme0n1 name : TEAM TM8FP6256G ata drive accsess : 0 nvme drive accsess : 0x2911b880 blok_device : /dev/sde name : Samsung SSD 840 EVO 120GB ata drive accsess : 0 nvme drive accsess : 0 blok_device : /dev/sdd name : ST1000DM003-1CH162 ata drive accsess : 0x2903a4b0 nvme drive accsess : 0 blok_device : /dev/sr0 name : TSSTcorp CDDVDW SH-224BB ata drive accsess : 0 nvme drive accsess : 0 After rebooting to load the kernel 6.10.5(after Revert "ata: libata-scsi: Honor the D_SENSE bit for CK_COND=1 and no error") (Niklas Cassel)) blok_device : /dev/sdc name : DataTraveler 3.0 ata drive accsess : 0 nvme drive accsess : 0 : USB blok_device : /dev/sdb name : WDC WD5000AAKX-22ERMA0 ata drive accsess : 0x19b7cc70 nvme drive accsess : 0 : SATA HDD blok_device : /dev/sda name : Samsung SSD 850 PRO 256GB ata drive accsess : 0x19b68ad0 nvme drive accsess : 0 : SATA SSD blok_device : /dev/nvme0n1 name : TEAM TM8FP6256G ata drive accsess : 0 nvme drive accsess : 0x19a8f890 : NVME blok_device : /dev/sdf name : Samsung SSD 840 EVO 120GB ata drive accsess : 0 nvme drive accsess : 0 : USB SATA SSD blok_device : /dev/sde name : ST1000DM003-1CH162 ata drive accsess : 0x19b8da40 nvme drive accsess : 0 : USB SATA HDD blok_device : /dev/sdd name : PCIe SSD ata drive accsess : 0 nvme drive accsess : 0 : USB NVME blok_device : /dev/sr0 name : TSSTcorp CDDVDW SH-224BB ata drive accsess : 0x19b926e0 nvme drive accsess : 0 : DVD/CD Best regards!
I did not express myself clearly enough, there was a problem with the support of the ata device, but it was fixed in 6.10.5 For usb flash drive and for sata over usb this is normal - there is no support for them from a long time. Also ,NVME support was been added recently but there is no problem with it. /under these conditions, it is normal for NVME over usb to have no support./
Andre, can you confirm if you still see this with kernel-6.10.6-200.fc40 or kernel-6.10.5-200.fc40 (from updates-testing)? Thanks!
Per jforbes this is a known issue that's corrected in 6.10.5 and 6.11 rc4. However, newer 6.11 kernels also have a journal issue that breaks podman and thus are gated from Rawhide ATM; we need to work that out to get a newer build into F41 that will fix this.
(In reply to Andre Robatino from comment #7) > Just noticed that with the portable HDD, though I get the SMART data using > gnome-disks, I do NOT get it from smartctl -a. With the internal drives, > that's reversed, I get the SMART data from smartctl -a but not gnome-disks. Ignore this comment, I was using the wrong smartctl syntax on the portable HDD, smartctl works fine even with 6.10.4 when used correctly. So far I've tested 6.10.5 on F40 and the gnome-disks problem is fixed there. Will test the currently building kernel-6.11.0-0.rc4.37.fc41 on F41 when it gets into the branched compose tomorrow.
Discussed during the 2024-08-19 blocker review meeting: [1] The decision to classify this bug wasn't made: "This seems like a borderline case, and may be fixed by newer kernels. For now we'll punt it for further testing with newer kernel builds." [1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-08-19/f41-blocker-review.2024-08-19-15.59.log.html
kernel-6.11.0-0.rc4.38.fc41.x86_64 is in the latest compose. However, I'm using a VirtualBox guest and when running rc4, gnome-disks reports "SMART is not supported" (in rc3 the output looked the same as in F40 with a 6.10.3 or 6.10.4 kernel). So it seems that someone running bare metal or at least a different type of guest will have to test this in F41 (but it's a trivial test, just see if gnome-disks shows the SMART info again). Sorry.
can you test with a live boot? I can check it works for me now, but I don't know if I was affected before; it would be best to test on the hardware we know was affected. If you can't, I guess I can try booting an older kernel to see if I can reproduce, then seeing if it's still there with a newer one if so...
For me, the behavior appeared to be exactly the same in F41 with the rc3 kernel as in F40 with 6.10.3 or 6.10.4. So anyone with bare metal F41 should be able to reproduce with the original 6.11.0-0.rc3.30.fc41 kernel. I'm not sure what the normal behavior with VirtualBox is supposed to be since I normally never bother to run gnome-disks in a branched or rawhide guest, only on the host. I only checked it this time since I saw it was broken in F40 bare metal.
I tried testing this on my system, but the menu items are greyed out for me even with rc5 and 6.10.6. I didn't get time yet to check if it works with 6.9 for me.
Discussed during the 2024-08-26 blocker review meeting: [1] The decision to classify this bug wasn't made: "We're still not really clear on the contours of this or whether it's already fixed, due to differing hardware and lack of input from the reporter." [1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-08-26/f41-blocker-review.2024-08-26-16.00.log.html
I didn't think my input would be necessary, since I thought at least half of the people at the meeting would be running 41 on bare metal with the rc4 kernel or later, and could just bring up gnome-disks and look at it. Anyway, I downloaded Fedora-Workstation-Live-x86_64-41-20240824.n.0.iso, with the rc4 kernel, and ran it live on all 3 of my machines (all old and BIOS-only), and gnome-disks appears to work normally on all of them. So this appears fixed, assuming the behavior is the same on newer hardware.
Andre: the problem is that the nature of the disks you have attached also matters. For instance, after the meeting I checked and found that even with kernel 6.9, the relevant menu items are all greyed out on my system. So I could not confirm this one either way. Thanks for re-testing. Let's call this fixed.
My two desktops (from around 2008 and 2009) have a standard HDD, my laptop (from around 2014) has a SSD.
This bug has reappeared in F40 with the 6.10.10-200.fc40.x86_64 kernel. Have not checked F41 yet.
In F41 VirtualBox guest, running kernel-6.11.0-63.fc41.x86_64, gnome-disks says "SMART is not supported" which I believe is the normal error message, so appears F41 is not affected. (But would be good if a kernel dev could confirm that this regression is limited to the F40 kernel.)
Still broken with 6.10.11. This time it appears to be hardware dependent, but for each machine/drive the behavior is the same with 6.10.10 and 6.10.11. I have 2 desktops with 2TB HDDs where gnome-disks doesn't show the SMART info for the internal HDD. However, on my laptop with a SSD, gnome-disks does show the SMART info for the internal SSD. In any of the 3 machines, if I plug in my 1TB portable HDD, gnome-disks shows the SMART info for that drive. Since it's hardware-dependent, I can't be sure if this affects F41, so it would be nice to get a response from one of the kernel devs as to whether this problem is known and which kernels it affects.
I downloaded Fedora-Workstation-Live-x86_64-41-20240928.n.0.iso (with the 6.11.0-63.fc41.x86_64 kernel) and tested it with all of the above hardware, and none of it is affected. So hopefully this is limited to 6.10.