Most are mounted (as expected) at /run/media/.*
but my secondary data drive is mounted at /tmp/os-probes-50mounted-tests.qrfQBc suddenly:
…Any idea why? I ask because "/tmp/os-probes-50mounted-tests" - Google Suche solely returns
none of which are of much use to me except that they all appear to reference GRUB, so is this perhaps relevant to
I wiped nvme3n1 by recreating its GPT partition and ran systemctl reboot. It fixed the GRUB issue, but now I can’t boot.
I’m getting the same as
Except that I’ve not had a successful boot yet, regardless of whether I use Ctrl+Alt+Delete or not.
[IMG_20231021_085418]
Usually the system boots quickly enough that I can’t see the boot log if I were to want to. It did once progress just pass this to Virtual Console Setup, but it hung regardless.
Remounting it with Dolphin fixed the issue (temporarily?):
https://bugs.kde.org/show_bug.cgi?id=476027
Have you tried again since then? I think the system may be remembering where this was mounted, and may attempt to mount at the same place.
Spurious mounts by udisks2 can be annoying. Infamous host erlangen has several external disks added to fstab. This warrants stability and reliability:
#-----------------------------------------------------------------------------------------------------------
UUID=68BA-53B2 /GARMIN vfat user,noauto 0 0
UUID=0267-906F /GARMIN-KART vfat user,noauto 0 0
LABEL=FR735 /FR735 vfat user,noauto 0 0
#-----------------------------------------------------------------------------------------------------------
UUID=2260f160-cc05-47cc-9893-cc32c050177d /HDD btrfs user,noauto 0 0
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344 /Btrbk btrfs subvolid=5,noauto 0 0
UUID=8a723ba5-c46f-45df-b708-0cf9c541da27 /Backup btrfs subvolid=5,noauto 0 0
UUID=47e6d9ee-e910-4ea4-8c8f-7ac75f49a4d3 /Crucial btrfs subvolid=5,noauto 0 0
erlangen:~ #
2 Likes
Apologies, @nrickert – the “temporarily?” was because I hadn’t yet tested enough to conclude anything. However, it indeed appears to have remediated the issue. I have no idea what might have caused it.
Yeah, @karlmistelberger , mine only has mount points for my primary SSD:
UUID=579fa64f-308b-4c25-a716-74ec679512e7 / btrfs defaults 0 0
UUID=579fa64f-308b-4c25-a716-74ec679512e7 /var btrfs subvol=/@/var 0 0
UUID=579fa64f-308b-4c25-a716-74ec679512e7 /usr/local btrfs subvol=/@/usr/local 0 0
UUID=579fa64f-308b-4c25-a716-74ec679512e7 /srv btrfs subvol=/@/srv 0 0
UUID=579fa64f-308b-4c25-a716-74ec679512e7 /root btrfs subvol=/@/root 0 0
UUID=579fa64f-308b-4c25-a716-74ec679512e7 /opt btrfs subvol=/@/opt 0 0
UUID=579fa64f-308b-4c25-a716-74ec679512e7 /home btrfs subvol=/@/home 0 0
UUID=579fa64f-308b-4c25-a716-74ec679512e7 /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0
UUID=579fa64f-308b-4c25-a716-74ec679512e7 /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0
UUID=579fa64f-308b-4c25-a716-74ec679512e7 /.snapshots btrfs subvol=/@/.snapshots 0 0
UUID=12AC-35DE /boot/efi vfat utf8 0 2
I expected that kcm_whatever
would have added those drives to /etc/fstab, but obviously it does things differently. Thanks for the advice. I’ll do if it recurrs without a proper obvious fix.
Thanks for the feedback. Automounting through KDE device notifier is shaky. I attached the FR735 daily since 2015 . KDE automounter frequently changed behaviour or failed completely. It’s PITA.
I now switched the Forerunner to kernel automounting, which is rock solid and never failed in the past years:
erlangen:~ # grep /FR735 /etc/fstab
LABEL=FR735 /FR735 vfat user,noauto 0 0
erlangen:~ #
Create and enable service:
erlangen:~ # systemctl cat FR735.automount
# /etc/systemd/system/FR735.automount
[Automount]
Where=/FR735
TimeoutIdleSec=10s
[Install]
RequiredBy=remote-fs.target
erlangen:~ # systemctl enable --now FR735.automount
erlangen:~ #
Upon attaching the running watch FR735.service readily copies Forerunner activities to the local disk:
erlangen:~ # systemctl cat FR735.service
# /etc/systemd/system/FR735.service
[Unit]
Description=Get FR735 Activities
Requires=FR735.mount
After=FR735.mount
[Service]
ExecStart=/usr/bin/rsync -av /FR735/ /home/karl/Forerunner/
[Install]
WantedBy=FR735.mount
# /etc/systemd/system/service.d/toplevel-override.conf
[Unit]
OnFailure=failure-notification@%n
erlangen:~ #
erlangen:~ # journalctl -b -u 'FR735.*'
Oct 25 07:07:27 erlangen systemd[1]: Started Get FR735 Activities.
Oct 25 07:07:27 erlangen rsync[1527]: sending incremental file list
Oct 25 07:07:29 erlangen rsync[1527]: sent 4,910 bytes received 49 bytes 1,983.60 bytes/sec
Oct 25 07:07:29 erlangen rsync[1527]: total size is 7,104,790 speedup is 1,432.71
Oct 25 07:07:29 erlangen systemd[1]: FR735.service: Deactivated successfully.
Oct 25 07:07:45 erlangen systemd[1]: Unmounting /FR735...
Oct 25 07:07:45 erlangen systemd[1]: FR735.mount: Deactivated successfully.
Oct 25 07:07:45 erlangen systemd[1]: Unmounted /FR735.
erlangen:~ #
1 Like
Thanks, lots. I’ll definitely follow this eventually.
@karlmistelberger , if ever you try the automount KCM again, would you file a bug report if the behaviour persists? I expect you could actually provide the information necessary for a fix, whereas I wouldn’t know where to start.
The KDE automounter uses kernel path names which can change randomly. It’s broken. They need to fix it.
Currently I use entries in /etc/fstab for frequently attached devices. I check “System Settings > Removable Storage > Removable Devices > Automatically mount removable media that have never been mounted before”. No kernel automounting used for these devices. That works reliably. No spurious mounts occur on infamous host erlangen.
1 Like
mchnz
November 1, 2023, 8:55pm
9
The randomness has probably gotten worse since the TW kernel was changed to load sd-mod as a module. For straight forward desktops, the previous level of stability can be restored, see Bug 1216070 - Assignment of /dev/sd* has altered dramatically comment #33 for a fix which is in the process of delivered in TW.
For Leap there see comment #29 of the same bug report.
There was also a forum thread on the topic
mchnz
November 1, 2023, 9:25pm
10
The fix for bug 1216070 has been released in snapshot 20231031:
==== suse-module-tools ====
Version update (16.0.37 -> 16.0.38)
Subpackages: suse-module-tools-scriptlets
- Update to version 16.0.38:
* modprobe.d: use softdep to load sd_mod and sg (boo#1216070)
How does that relate to mounture at /tmp? That discussion appears to pertain solely to /dev.
mchnz
November 4, 2023, 2:36am
12
It relates to:
If KDE is expecting to find /dev/sd[abc…] to be a fixed mapping to specific drives, then shuffling that mapping may cause weird things to happen.
However, from what I’ve read in this thread, it’s hard to say whether this plays any part in this issue. I guess it would be up to you to sniff around and see if a change in the /dev/sd* drive mappings yields any clues to your issue.
If the problem went away or changed after booting into the “fix” snapshot 20231031, then that might indicate that the /dev/sd* mappings are related in some way.
1 Like
@mchnz , mere remounture fixed it. God knows why.
mchnz:
However, from what I’ve read in this thread, it’s hard to say whether this plays any part in this issue. I guess it would be up to you to sniff around and see if a change in the /dev/sd* drive mappings yields any clues to your issue
The general section works fine with the following:
karl@3400g:~> grep -A3 'General' ~/.config/kded_device_automounterrc
[General]
AutomountEnabled=true
AutomountOnPlugin=true
AutomountUnknownDevices=true
karl@3400g:~>
The device sections are a terrible mess:
karl@3400g:~> grep Device ~/.config/kded_device_automounterrc
[Devices][/org/freedesktop/UDisks2/block_devices/nvme0n1p1]
[Devices][/org/freedesktop/UDisks2/block_devices/nvme0n1p2]
[Devices][/org/freedesktop/UDisks2/block_devices/sda1]
[Devices][/org/freedesktop/UDisks2/block_devices/sda2]
[Devices][/org/freedesktop/UDisks2/block_devices/sda3]
[Devices][/org/freedesktop/UDisks2/block_devices/sda4]
[Devices][/org/freedesktop/UDisks2/block_devices/sda5]
[Devices][/org/freedesktop/UDisks2/block_devices/sda6]
[Devices][/org/freedesktop/UDisks2/block_devices/sda7]
[Devices][/org/freedesktop/UDisks2/block_devices/sda9]
[Devices][/org/freedesktop/UDisks2/block_devices/sdb1]
[Devices][/org/freedesktop/UDisks2/block_devices/sdb2]
[Devices][/org/freedesktop/UDisks2/block_devices/sdc]
[Devices][/org/freedesktop/UDisks2/block_devices/sdc1]
[Devices][/org/freedesktop/UDisks2/block_devices/sdc2]
[Devices][/org/freedesktop/UDisks2/block_devices/sdc3]
[Devices][/org/freedesktop/UDisks2/block_devices/sdc4]
[Devices][/org/freedesktop/UDisks2/block_devices/sdc5]
[Devices][/org/freedesktop/UDisks2/block_devices/sdc6]
[Devices][/org/freedesktop/UDisks2/block_devices/sdc7]
[Devices][/org/freedesktop/UDisks2/block_devices/sdc9]
[Devices][/org/freedesktop/UDisks2/block_devices/sdd]
[Devices][/org/freedesktop/UDisks2/block_devices/sdd1]
[Devices][/org/freedesktop/UDisks2/block_devices/sde]
[Devices][/org/freedesktop/UDisks2/block_devices/sde1]
[Devices][/org/freedesktop/UDisks2/block_devices/sdf]
[Devices][/org/freedesktop/UDisks2/block_devices/sdf1]
[Devices][/org/freedesktop/UDisks2/block_devices/sdg]
karl@3400g:~>
I don’t bother.
On the other hand the Linux Kernel Monkey did an excellent job with udev and its on demand mounting. Some tailored output provides everything needed:
3400g:~ # lsb
MODEL LABEL SIZE FSTYPE PATH UUID
Samsung SSD 850 EVO 250GB 232.9G /dev/sda
850EVO250GB 100M vfat /dev/sda1 404C-1EC8
TW-test 30G btrfs /dev/sda2 f991e6d5-fbb3-4f8a-8c5c-04b24c6495a1
Leap154 40G btrfs /dev/sda3 337219d4-b3bd-43d2-9cd3-45f8f53269bd
Fedora 29.3G btrfs /dev/sda4 95a1cc9a-3a30-455d-b3bc-764202e94522
Manjaro 27.9G ext4 /dev/sda5 172e21e3-9964-4708-9651-e6c52906c58e
Kubuntu 29.3G ext4 /dev/sda6 8226cbe9-6836-47a9-a5cd-9dfa223b51fa
29.3G ext4 /dev/sda7 8dd05b5d-31af-4af2-9970-55fadeb988d2
16M /dev/sda8
46.9G ntfs /dev/sda9 065437EB5437DBDD
Samsung SSD 850 EVO 500GB 465.8G /dev/sdb
850EVO500GB 100M vfat /dev/sdb1 7739-823F
Albums 465.7G btrfs /dev/sdb2 10726d74-53da-41e8-a3ed-7af130722783
STORAGE DEVICE 30.2G /dev/sdc
DMC-TZ71 30.2G vfat /dev/sdc1 0518-01CC
SSD8 3.6T /dev/sdd
Crucial 3.6T btrfs /dev/sdd1 47e6d9ee-e910-4ea4-8c8f-7ac75f49a4d3
ST8000VN004-2M2101 7.3T /dev/sde
Seagate 7.3T btrfs /dev/sde1 2260f160-cc05-47cc-9893-cc32c050177d
Samsung SSD 950 PRO 512GB 476.9G /dev/nvme0n1
950PRO 100M vfat /dev/nvme0n1p1 6DEC-64F9
Tumbleweed 476.8G btrfs /dev/nvme0n1p2 e7ad401f-4f60-42ff-a07e-f54372bc1dbc
3400g:~ #
KDE automounts go by default to directory /media with the labels used as mountpoints unless defined differently in /etc/fstab.
3400g:~ # df -h /media/DMC-TZ71/
Filesystem Size Used Avail Use% Mounted on
/dev/sdc1 31G 12G 19G 38% /media/DMC-TZ71
3400g:~ #
KDE System Settings > Removable Storage > Removable Devices needs a redesign based on UUIDs and labels.
1 Like
