Project

General

Profile

Actions

Fix #10

closed

Error at automounting drives

Added by Khaled Malhal Abbas 6 days ago. Updated 6 days ago.

Status:
Resolved
Priority:
Normal
Start date:
11/28/2025
Due date:
% Done:

100%

Estimated time:
4:00 h

Description

Context:

The SPS monitor device has udev rules located in /etc/udev/rules.d/10-usb-detect.rules that are executed when a new device is detected, more specifically the ones with name sd* and mmcblk*. These rules basically mount these devices into /mnt/usb-drive when a sd* is detected and into /mnt/sd-card when a mmcblk* device is detected. Here are the rules specified:

ACTION=="add", KERNEL=="sd?[0-9]", SUBSYSTEM=="block", RUN+="/usr/local/bin/add.sh" 
ACTION=="add", KERNEL=="mmcblk*", SUBSYSTEM=="block", RUN+="/usr/local/bin/add.sh" 
ACTION=="remove", SUBSYSTEM=="block", RUN+="/usr/local/bin/remove.sh" 

Problem:

The automounting does not work. This automount is needed for the software running in the monitors to update the set of messages for the SPS.

Actions #1

Updated by Khaled Malhal Abbas 6 days ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Using kernel messages, by redirecting debug messages to /dev/kmsg, it was validated that the rules were being executed when a device was being added. In fact, it was possible to see that, after mounting the device into /mnt/usb-drive and checking the return value of the execution of the command mount, via the same script, we could list the contents of the USB drive and even write in it. Although, after the execution of the rule, the mount doesn't take effect.

Apparently, the udev wouldn't make the mount persistent because it doesn't work on the root's userspace. It would seem that the rules' is executed on the RAM instead of the persistent file system. As quoted by the systemd-udevd service developers in https://www.freedesktop.org/wiki/Software/systemd/RootStorageDaemons/:

As a result, we hereby clarify that we do not support storage technology setups where the storage daemons are being run from the storage it maintains itself. In other words: a storage daemon backing the root file system cannot be stored on the root file system itself.

What we do support instead is that these storage daemons are started from the initramfs, stay running all the time during normal operation and are terminated only after we returned control back to the initramfs and by the initramfs. [...]

Solution:

An implemented and tested solution was to modify the options of the systemd-udevd service, by adding the following contents in the file /etc/systemd/system/systemd-udevd.service.d/override.conf:

[Service]
# For Ubuntu >20.04
#MountFlags=shared
# For Ubtuntu <=20.04
PrivateMounts=no

To make these changes take effect, reload the services and then restart the systemd-udevd service. Or, a reboot of the system will do:

# systemctl daemon-reload
# service systemd-udevd --full-restart
Source of the solutions:

Observations:

There is a script that is responsible to do the full installation of the software and system setup made by us. We have noticed that by NOT upgrading the packages, the problem doesn't seem to show up. We believe that this feature (not a bug) was added in a package later on. We haven't found out which package(s) is(are) responsible.

Actions

Also available in: Atom PDF