My original post said it was a kernel issue, so no idea why it was logged against konsole.
I've changed it. ** Package changed: konsole (Ubuntu) => linux-hwe-6.5 (Ubuntu) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-hwe-6.5 in Ubuntu. https://bugs.launchpad.net/bugs/1998543 Title: fstrim no longer working on some external USB enclosures Status in linux-hwe-6.5 package in Ubuntu: Confirmed Bug description: Having upgraded from Jammy to Kinetic I now find that fstrim no longer works on SSD drives in some external USB enclosures. The issue is caused by the provisioning_mode status for these now being set to disabled, whereas previously they were set to unmap. Oddly(?) this only occurs on hot-plugging. I have two of these "permanently" plugged in to one system (so there at boot time) and these still show up as unmap. But if I plug in a third enclosure (same chipset, same SSD model, same SSD firmware version as the second one) it shows up as disabled. ========== root@benuc:~# lsusb Bus 002 Device 003: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS578 SATA 6Gb/s Bus 002 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS578 SATA 6Gb/s Bus 002 Device 004: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS578 SATA 6Gb/s Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 8087:0aaa Intel Corp. Bluetooth 9460/9560 Jefferson Peak (JfP) Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@benuc:~# cd /sys/ /sys root@benuc:/sys# find -name provisioning_mode ./devices/pci0000:00/0000:00:17.0/ata2/host1/target1:0:0/1:0:0:0/scsi_disk/1:0:0:0/provisioning_mode ./devices/pci0000:00/0000:00:17.0/ata3/host2/target2:0:0/2:0:0:0/scsi_disk/2:0:0:0/provisioning_mode ./devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0/host3/target3:0:0/3:0:0:0/scsi_disk/3:0:0:0/provisioning_mode ./devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4:1.0/host4/target4:0:0/4:0:0:0/scsi_disk/4:0:0:0/provisioning_mode ./devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/host5/target5:0:0/5:0:0:0/scsi_disk/5:0:0:0/provisioning_mode root@benuc:/sys# cat ./devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0/host3/target3:0:0/3:0:0:0/scsi_disk/3:0:0:0/provisioning_mode unmap root@benuc:/sys# cat ./devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4:1.0/host4/target4:0:0/4:0:0:0/scsi_disk/4:0:0:0/provisioning_mode unmap root@benuc:/sys# cat ./devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/host5/target5:0:0/5:0:0:0/scsi_disk/5:0:0:0/provisioning_mode disabled ========== (Ignore the ata entries - those are internal drives). If I reboot the system using the old, kept Jammy kernel (5.15.0-52-generic) the hot-plug shows up as unmap again. It's the 5.19.0-2?-generic Kinetic kernels which seem to be causing the problem. I do have a workaround of providing my own udev rule: ACTION=="add|change", ATTRS{idVendor}=="152d", ATTRS{idProduct}=="0578", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap" which is something I've had to do anyway for some other ASMedia chipsets which do work, but don't get set to unmap by default - 174c:55aa and 174c:235c. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-hwe-6.5/+bug/1998543/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
