Bugzilla – Bug 1226214
Non-removable drives being flagged as removable in "/sys/class/block/sd*/removable"
Last modified: 2024-06-17 13:22:56 UTC
This issue arose following Tumbleweed update 20240521 -> 20240605 (some snapshots skipped, so unable to be exact on which update may have caused this.) There have been *no* changes made to the hardware or bios configuration of this machine. Initially I thought there was a problem with KDE's "Disks & Devices" (Device Notifier), which is where I first noticed non-removable drives appearing as removable. However that was not the case. Physically this machine has 2 ssd drives: sda and sdb, and 1 hdd: sdc (all connected by SATA directly to the motherboard). "lsblk" shows these as removable: paul@Orion-15:~$ sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 1 55.9G 0 disk ├─sda1 8:1 1 48G 0 part / └─sda2 8:2 1 4G 0 part [SWAP] sdb 8:16 1 119.2G 0 disk └─sdb1 8:17 1 112G 0 part /home sdc 8:32 1 232.9G 0 disk ├─sdc1 8:33 1 32G 0 part ├─sdc2 8:34 1 192G 0 part └─sdc3 8:35 1 8.9G 0 part sr0 11:0 1 1024M 0 rom paul@Orion-15:~$ and looking at the relevant "/sys/class/block/sd*/removable" they are set to "1" That was using Kernel 6.9.3-1-default, I only retain kernel-1 and the issue still exists with 6.9.1. I have subsequently updated to TW 20240607 and the issue is still present. If I boot this machine using a Leap 15.5 live USB and then issue the lsblk command the 3 non removable drives (sda, sdb, and sdc) are shown with the correct removable flag, ie "0", non-removable. linux@localhost:~> sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS loop0 7:0 0 814.1M 1 loop /run/overlay/squashfs_container loop1 7:1 0 4.8G 1 loop /run/overlay/rootfsbase sda 8:0 0 55.9G 0 disk ├─sda1 8:1 0 48G 0 part └─sda2 8:2 0 4G 0 part sdb 8:16 0 119.2G 0 disk └─sdb1 8:17 0 112G 0 part sdc 8:32 0 232.9G 0 disk ├─sdc1 8:33 0 32G 0 part ├─sdc2 8:34 0 192G 0 part └─sdc3 8:35 0 8.9G 0 part sdd 8:48 1 57.7G 0 disk ├─sdd1 8:49 1 927.5M 0 part /run/overlay/live ├─sdd2 8:50 1 20M 0 part └─sdd3 8:51 1 56.8G 0 part /run/overlay/overlayfs sr0 11:0 1 1024M 0 rom linux@localhost:~>
Could you verify that 6.8.x kernel works as expected? It can be still found in OBS history repo http://donwload.opensuse.org/history/
(In reply to Takashi Iwai from comment #1) > Could you verify that 6.8.x kernel works as expected? It can be still found > in OBS history repo > http://donwload.opensuse.org/history/ All correct with 6.8.9-1-default paul@Orion-15:~$ uname -a Linux Orion-15.openSUSE 6.8.9-1-default #1 SMP PREEMPT_DYNAMIC Fri May 10 08:51:14 UTC 2024 (d3445e0) x86_64 x86_64 x86_64 GNU/Linux paul@Orion-15:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 55.9G 0 disk ├─sda1 8:1 0 48G 0 part / └─sda2 8:2 0 4G 0 part [SWAP] sdb 8:16 0 119.2G 0 disk └─sdb1 8:17 0 112G 0 part /home sdc 8:32 0 232.9G 0 disk ├─sdc1 8:33 0 32G 0 part ├─sdc2 8:34 0 192G 0 part └─sdc3 8:35 0 8.9G 0 part sdd 8:48 1 0B 0 disk sde 8:64 1 0B 0 disk sdf 8:80 1 0B 0 disk sdg 8:96 1 0B 0 disk sr0 11:0 1 1024M 0 rom
OK, then could you verify the behavior with the latest 6.10-rc kernel in OBS Kernel:HEAD repo, too? http://download.opensuse.org/repositories/Kernel:/HEAD/standard/
(In reply to Takashi Iwai from comment #3) > OK, then could you verify the behavior with the latest 6.10-rc kernel in OBS > Kernel:HEAD repo, too? > http://download.opensuse.org/repositories/Kernel:/HEAD/standard/ Unfortunately that has the same behavior as 6.9.* - Non-removable drives shown as removable. paul@Orion-15:~$ uname -a Linux Orion-15.openSUSE 6.10.0-rc3-1.g751e4fb-default #1 SMP PREEMPT_DYNAMIC Sun Jun 9 21:35:03 UTC 2024 (751e4fb) x86_64 x86_64 x86_64 GNU/Linux paul@Orion-15:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 1 0B 0 disk sdb 8:16 1 0B 0 disk sdc 8:32 1 0B 0 disk sdd 8:48 1 0B 0 disk sde 8:64 1 55.9G 0 disk ├─sde1 8:65 1 48G 0 part / └─sde2 8:66 1 4G 0 part [SWAP] sdf 8:80 1 119.2G 0 disk └─sdf1 8:81 1 112G 0 part /home sdg 8:96 1 232.9G 0 disk ├─sdg1 8:97 1 32G 0 part ├─sdg2 8:98 1 192G 0 part └─sdg3 8:99 1 8.9G 0 part sr0 11:0 1 1024M 0 rom lsblk also seems to list these in a different order: sda,b,c, and d are an external card reader. The 3 non removable drives are now sde,f, and g.
OK, it means that it's an upstream regression that is still present in the latest development. It was introduced between 6.8 and 6.9. Tossed to storage team. Meanwhile, Paul, could you report this to kernel regression? https://docs.kernel.org/process/handling-regressions.html
(In reply to Takashi Iwai from comment #5) > > Meanwhile, Paul, could you report this to kernel regression? > https://docs.kernel.org/process/handling-regressions.html After following a couple of linked documents: https://docs.kernel.org/admin-guide/reporting-regressions.html https://docs.kernel.org/admin-guide/reporting-issues.html Sorry, but unfortunately that's getting above my ability levels...
Fixed by commit a6a75edc8669a4f030546c7390808ef0cc034742 (ata: libata-scsi: Set the RMB bit only for removable media devices)
(In reply to Hannes Reinecke from comment #7) > Fixed by commit a6a75edc8669a4f030546c7390808ef0cc034742 (ata: libata-scsi: > Set the RMB bit only for removable media devices) Thanks! It's in 6.10-rc4. I backported to stable branch for TW kernel and sent a PR now. It'll be included in the next update (likely together with 6.9.6 update).
Thanks, appreciated... by myself and I'm sure many other folk. :)