SUMMARY KSysGuard 5.18.5 (version not in version list above) in openSUSE Leap 15.3 assumes device names such as /dev/nvme1n1p7 have a permanent device number (major:minor) and only offers to monitor dm devices by their number, e.g. /dev/dm-3, even though the device nodes created by openSUSE vary between restarts, e.g. * with 2 NVMe SSDs, the device minor assigned to them is sometimes swapped * if a partition is added or removed from the first NVMe SSD, the device minors for the partitions of the second NVMe SSD are incremented or decremented by 1 * LUKS crypt devices are allocated /dev/dm-* devices in unpredictable order, presumably because all are set up with the same iter-time, leaving it to tiny timing differences in which order the devices are set up STEPS TO REPRODUCE 1. Set up a system with multiple NVMe SSDs and multiple encrypted filesystems (my setup is described further below) 2. Add sensors to the KDE System Monitor for the backing devices of each filesystem, for the full path from the direct device(s), over the dm crypt devices to partitions and SSDs/HDDs. 3. Reboot every day and observe sensors 4. Add or remove a partition on the first SSD and continue step 3 OBSERVED RESULT * Sensors for the NVMe drives sometimes report "error" as the minor device number no longer matches. * Sensors for dm devices are useless if organised on tabs for individual filesystems as the the order op dm device numbers are random. Only a tab with all dm devices in numerical order is somewhat useful. * Sensors for partitions on the 2nd SSD permanently report "error" as the minor device number no longer matches. EXPECTED RESULT The sensor browser for block devices should first branch into selection based on any of minor:major, device name, device mapper alias, /dev/disk/by-id etc. and only store one device selector with the sheet, e.g. the name /dev/mapper/cr_home. On startup of ksysguard (or more often), the major:minor device number currently associated with this name is determined and used for obtaining sensor data (presumable from /proc/diskstats). SOFTWARE/OS VERSIONS Linux/KDE Plasma: openSUSE Leap 15.3 default KDE installation KDE Plasma Version: 20181130-lp153.2-8 KDE Frameworks Version: KDE Frameworks 5.76.0 Qt Version: Qt 5.12.7 (built against 5.12.7) ADDITIONAL INFORMATION * Asus B550-Pro mainboard with 2 NVMe SSDs and 2 HDDs * / and more via btrfs subvolumes, btrfs on LVM on LUKS on /dev/md0p1 on md RAID1 on /dev/nvme0n1p5 + /dev/nvme1n1p1 (set up with yast installer) * 2x swap on 2x LUKS with volatile random key on SSDs * /home with separate btrfs, btrfs on 2x LUKS on NVMe SSD partitions identified with /dev/disk/by-id/nvme-... in /etc/crypttab (manual setup) * /scratch with separate btrfs, btrfs on 2x bcache on 4x LUKS on SSDs and HDDs (manual setup; yast would insist on putting LUKS on top of bcache, leaking information on the size and frequency of access of cached objects) * iter-time of all 9 LUKS containers manually reduced to avoid time outs during startup WORKAROUND Write a script / systemd service that updates the files in /home/*/share/ksysguard/ on login or startup before ksysguard loads these configuration files.
ksysguard is no longer maintained, in Plasma 6 there is the Plasma system monitor for this task. If your issue still happens with the Plasma 6 replacement, please re-open and we can move this bug to the new product, thanks!