SOLVED: After update, USB-pendrive won't automount

dynosaw · 2024-05-30 06:56:09

My 64-bit (Intel chip set) Arch installation was updated (pacman -Syu) on
25 May 2024, after which the system will not automount any USB connected
storage device. Desktop is Cinnamon. Hardware is from January 2023.

Following symptoms found so far:
1) The desktop icon "Computer" finds the drive and will mount it manually;
Once mounted files can be accessed in the usual way.
2) systemctl-list-units finds active ".services":
dbus-broker, dbus-socket, udisks2

Where do I start to look for a cause/remedy?
All help welcome.
Dynosaw.
--

Last edited by dynosaw (2024-06-02 12:06:55)

dynosaw · 2024-05-31 08:36:20

One additional fact, I ommitted to mention.
A USB-pendrive IS detected and automounted
IF it has been encrypted woth Gnome-Disk.
Dynosaw

V1del · 2024-05-31 12:15:55

If the update included a kernel, your old kernel modules will not exist and modules that aren't yet loaded can't be loaded (because they got replaced with the newer kernel modules) reboot into the new kernel. Generally speaking the versions in

pacman -Q linux
uname -a

need to match.

seth · 2024-05-31 13:17:17

1) The desktop icon "Computer" finds the drive and will mount it manually;
Once mounted files can be accessed in the usual way.

Sounds like an invert of https://bbs.archlinux.org/viewtopic.php?id=295958

Please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

after plugging in the drive.

dynosaw · 2024-05-31 19:36:47

V1del and Seth.
Thanks for responding to my call for help.
Before I send a 1400-plus lines dump of journalctl -b, there is yet another new development:
Automount does not work with a pendrive with msdos partition table and ext4 format;
This pendrive can be mounted manually, so it must be OK?.
But auto-mount does work with a different USB-pendrive with an msdos partition table and formattted FAT32;
And I have no explanation for this.

For V1del: pacman -Q linux-lts and uname -a agree: linux version is 6.6.31-2-lts
(for the record, kernel linux 6.9.1.arch1-2 is also on the SSD but it is not the preferred opSys on boot-up.)

I have dumped journalctl -b four times to text files, as follows:
1) Cold start, no USB drive > BOOT-1.txt
2) Then insert USB drive (FAT32 format) and dump again > MOUNT1.txt
POWER OFF
3) Cold start, no USB drive > BOOT-1.txt
4) Then insert USB drive (ext4 format) and dump again > MOUNT2.txt
From these two "difference" files made i.e. extracting the last 20 or so lines after inserting
the pendrive in the USB port:
DIFF1.txt and DIFF2.txt
These files are not the same. DIFF1.txt confirms a mount; DIFF2.txt does not.

Seth, will the text of the DIFF files be sufficient or do you really need the
whole dump? I don't understand the command for the full text.

Thanks in advance
Dynosaw

seth · 2024-05-31 19:53:47

I can tell you whether the tails of the journals (please don't post a diff where one has to reconstruct what's actually going on in either case and fill the gaps with frog DNA) when I see them.

dynosaw · 2024-06-02 12:06:17

After much searching and reading, I think I've solved the problem.
Thanks Seth for your posting which spurred me on to look further.

The cause appears to lie in a udev rule file found in the file
/usr/lib/udev/rules.d/64-ext4.rules
which appears to block automount of ext3/ext4 files and some others.

The remedy I selected was (as sudo) to copy the above file to
/etc/udev/rules.d/ and edit the copy. Specifically:
Delete the text |ext3|ext4 from the active line
SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ext2|ext3|ext4|ext4dev|jbd", ENV{UDISKS_AUTO}="0"

I noted here that the original file in /usr/lib/udev/.... may be overwritten by the
next upgrade. whereas the file in /etc/udev/rules.d, which has precedence, will
not be overwritten.
Again thanks to all those who responded.
Dynosaw.
--

seth · 2024-06-02 12:18:02

Where does that even come from?

pacman -Qo  /usr/lib/udev/rules.d/64-ext4.rules

dynosaw · 2024-06-02 15:42:37

Sorry Seth, I don't understand the question. The package in question
will most likely be udev.

But one afterthought. In the preamble to the active code in the file
64-ext4.rules is a statement that the rule is intended to prevent
"evil maid" attacks. The edits described above will partially undo
that protection. My machine is a domestic PC, I am the only user,
and all the hot-plug devices I use are mine and I know their history.
For me the risk is acceptable. For others, different circumstances
may pertain and they may decide to accept the restriction about
which I complained.
Dynosaw.
--

Scimmia · 2024-06-02 15:45:00

The question is straightforward and they gave you the way to find out.

FTR, it's from e2fsprogs

seth · 2024-06-02 16:09:48

For context, https://git.kernel.org/pub/scm/fs/ext2/ … 15fbb3b98a
It's probably not advisable to file a bug about this

Arch Linux

#1 2024-05-30 06:56:09

SOLVED: After update, USB-pendrive won't automount

#2 2024-05-31 08:36:20

Re: SOLVED: After update, USB-pendrive won't automount

#3 2024-05-31 12:15:55

Re: SOLVED: After update, USB-pendrive won't automount

#4 2024-05-31 13:17:17

Re: SOLVED: After update, USB-pendrive won't automount

#5 2024-05-31 19:36:47

Re: SOLVED: After update, USB-pendrive won't automount

#6 2024-05-31 19:53:47

Re: SOLVED: After update, USB-pendrive won't automount

#7 2024-06-02 12:06:17

Re: SOLVED: After update, USB-pendrive won't automount

#8 2024-06-02 12:18:02

Re: SOLVED: After update, USB-pendrive won't automount

#9 2024-06-02 15:42:37

Re: SOLVED: After update, USB-pendrive won't automount

#10 2024-06-02 15:45:00

Re: SOLVED: After update, USB-pendrive won't automount

#11 2024-06-02 16:09:48

Re: SOLVED: After update, USB-pendrive won't automount

Board footer