Bug 2303813 - With >= 6.10.10 kernel, gnome-disks is partly nonfunctional (originally broken in 6.10.3 and fixed in 6.10.5)
Summary: With >= 6.10.10 kernel, gnome-disks is partly nonfunctional (originally broke...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 40
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-08-09 02:01 UTC by Andre Robatino
Modified: 2024-09-28 22:18 UTC (History)
21 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-08-26 19:09:06 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Andre Robatino 2024-08-09 02:01:26 UTC
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

Comment 1 Andre Robatino 2024-08-09 16:07:33 UTC
I tried running gnome-disks from the command line after su'ing to root with "su -" but the result is the same.

Comment 2 Andre Robatino 2024-08-10 02:43:02 UTC
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.

Comment 3 Andre Robatino 2024-08-14 20:59:19 UTC
Same behavior in my 41 Branched guest. Changing Version to 41.

gnome-disk-utility-46.0-2.fc41.x86_64

Comment 4 Andre Robatino 2024-08-14 21:12:54 UTC
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."

Comment 5 Andre Robatino 2024-08-15 01:52:41 UTC
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.

Comment 6 Andre Robatino 2024-08-15 03:35:40 UTC
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).

Comment 7 Andre Robatino 2024-08-15 22:22:36 UTC
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.

Comment 8 isgospodinov 2024-08-16 12:28:48 UTC
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!

Comment 9 isgospodinov 2024-08-16 13:43:23 UTC
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./

Comment 10 Adam Williamson 2024-08-19 16:33:48 UTC
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!

Comment 11 Adam Williamson 2024-08-19 16:52:38 UTC
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.

Comment 12 Andre Robatino 2024-08-19 18:05:13 UTC
(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.

Comment 13 František Zatloukal 2024-08-19 20:39:38 UTC
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

Comment 14 Andre Robatino 2024-08-24 02:22:11 UTC
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.

Comment 15 Adam Williamson 2024-08-25 15:20:44 UTC
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...

Comment 16 Andre Robatino 2024-08-25 15:35:05 UTC
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.

Comment 17 Adam Williamson 2024-08-26 16:06:07 UTC
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.

Comment 18 František Zatloukal 2024-08-26 18:15:15 UTC
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

Comment 19 Andre Robatino 2024-08-26 18:46:13 UTC
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.

Comment 20 Adam Williamson 2024-08-26 19:09:06 UTC
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.

Comment 21 Andre Robatino 2024-08-26 19:28:56 UTC
My two desktops (from around 2008 and 2009) have a standard HDD, my laptop (from around 2014) has a SSD.

Comment 22 Andre Robatino 2024-09-18 05:15:18 UTC
This bug has reappeared in F40 with the 6.10.10-200.fc40.x86_64 kernel. Have not checked F41 yet.

Comment 23 Andre Robatino 2024-09-19 04:17:05 UTC
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.)

Comment 24 Andre Robatino 2024-09-25 18:15:02 UTC
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.

Comment 25 Andre Robatino 2024-09-28 22:18:20 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.