[SOLVED] Upgrade from Buster to Bulleye now auto mounts my Micropython pyboard as read-only!

keithostertag · 06-05-2022, 09:54 PM

A few weeks ago I finally upgraded my Debian system from Buster to Bulleye. I am running Debian with the Cinnamon DE.

The upgrade went fine.

However, I find that when I plug in my Micropython pyboard (v1.1) (via USB) it now automounts read-only! This is not good and did not happen before the upgrade.

If I plug in my pyboard to an older Debian system I have it automounts correctly (as rw), so I am pretty sure the upgrade changed something that makes it automount ro.

I tried modifying /etc/udisks2/udisks2.conf but that did not work, perhaps I did that wrong? Here is the two lines line I added:

Code:

[/dev/disk/by-uuid/2821-0000]
vfat_defaults=uid=$UID,rw

My pyboard's UUID is 2821-0000

I also looked at /lib/udev/rules.d/80-udisks2.rules and /lib/udev/rules.d/99-systemd.rules but they did not contain anything I understood as relevant... I really do not understand this stuff well enough.

IF I could simply add an entry to my /etc/fstab file that would be great, but I am not certain how to properly write that entry. My pyboad has always automounted properly (rw) with no added entries in /etc/fstab or any other config file.

Can someone suggest how to fix this problem?

Code:

keith@ada:~$ cat /etc/debian_version 
11.3
keith@ada:~$ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"

Code:

keith@ada:~$ mount
/dev/sdh1 on /media/keith/PYBFLASH type vfat (ro,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

Code:

keith@ada:~$ sudo blkid
/dev/sdh1: SEC_TYPE="msdos" LABEL="PYBFLASH" UUID="2821-0000" BLOCK_SIZE="512" TYPE="vfat"

Code:

keith@ada:~$ ls -ahl /dev/sdh1
brw-rw---- 1 root disk 8, 113 Jun  5 21:56 /dev/sdh1

jailbait · 06-05-2022, 10:36 PM

Quote:

Originally Posted by keithostertag

I tried modifying /etc/udisks2/udisks2.conf but that did not work, perhaps I did that wrong? Here is the two lines line I added:

Code:

[/dev/disk/by-uuid/2821-0000]
vfat_defaults=uid=$UID,rw

My pyboard's UUID is 2821-0000

Code:

keith@ada:~$ mount
/dev/sdh1 on /media/keith/PYBFLASH type vfat (ro,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

Code:

keith@ada:~$ sudo blkid
/dev/sdh1: SEC_TYPE="msdos" LABEL="PYBFLASH" UUID="2821-0000" BLOCK_SIZE="512" TYPE="vfat"

Code:

keith@ada:~$ ls -ahl /dev/sdh1
brw-rw---- 1 root disk 8, 113 Jun  5 21:56 /dev/sdh1

When you are creating a new system the user ids are numbers which are assigned starting at 1000 in a first come first numbered order. If you have created your users in a different order in buster and bullseye then you could be in the situation that the user id number used on the hard drive files is assigned to different user names on the two systems. That could explain what caused your problem.

keithostertag · 06-05-2022, 10:56 PM

I should add- if I plug in a regular USB thumbdrive it automounts normally as rw.

ondoho · 06-05-2022, 11:51 PM

Can you (manually) remount the pyboard rw?

keithostertag · 06-06-2022, 08:22 AM

I cannot seem to remount the pyboard rw, despite the mount report saying different:

Code:

keith@ada:~$ cat /proc/mounts|grep PYBFLASH
/dev/sdh1 /media/keith/PYBFLASH vfat ro,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro 0 0

keith@ada:~$ sudo mount -o remount,rw /media/keith/PYBFLASH/

keith@ada:~$ cat /proc/mounts|grep PYBFLASH
/dev/sdh1 /media/keith/PYBFLASH vfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro 0 0

The above appears to remount the pyboard, but then:

Code:

keith@ada:~$ touch /media/keith/PYBFLASH/test.txt
touch: cannot touch '/media/keith/PYBFLASH/test.txt': Read-only file system

How can I determine which udev rule is being applied?

Debian6to11 · 06-06-2022, 10:17 AM

Maybe I'm wrong, but shouldn't /dev/sdh1 belong to the user and not root?

keithostertag · 06-06-2022, 11:19 AM

You are correct, and what is that group "disk 8" ?

Debian6to11 · 06-06-2022, 12:52 PM

No idea, but it should be listed under /etc/group. Maybe a group formed for those devices?
You can change the groups using the "chgrp" command but that device is not a disk which I am more familiar with. In essence I do not know if that is a correct approach (changing the group, which can give you read/write permissions).

michaelk · 06-06-2022, 01:04 PM

Quote:

Originally Posted by Debian6to11

Maybe I'm wrong, but shouldn't /dev/sdh1 belong to the user and not root?

No, root is correct.

Code:

brw-rw---- 1 root disk 8, 0 Jun  5 09:11 /dev/sda
brw-rw---- 1 root disk 8, 1 Jun  5 09:11 /dev/sda1
brw-rw---- 1 root disk 8, 2 Jun  5 09:11 /dev/sda2

Root is the owner and disk is the group name. Devices are given a major, minor number based on its type. The 8 is major with 8 and 65 being assigned to SCSI devices i.e. /dev/sdx. The minor is associated with the partition number.

There must be something specific with the pyboard, the kernel version and how it is being recognized.

Debian6to11 · 06-06-2022, 01:52 PM

@ michaelk , you are correct.

Code:

aris@hb8DebianS:~$ ls -l /dev/sda1
brw-rw---- 1 root disk 8, 1 May 24 17:34 /dev/sda1

I had a problem about two weeks ago with the device listed above. Somehow, without any input of mine (quite sure), the ownership of the partition was taken by user and group root.
This is the fix I used

Code:

aris@hb8DebianS:~$ sudo chgrp aris /media/aris/Seagate2Tc
aris@hb8DebianS:~$ sudo chown -Rv aris /media/aris/Seagate2Tc
aris@hb8DebianS:~$ sudo chmod -Rv 755 /media/aris/Seagate2Tc

Which returned these values

Code:

aris@hb8DebianS:~$ ls -l /media/aris/Seagate2Tc/
total 44
drwxr-xr-x  3 aris aris  4096 May 10 22:03 aris.hp2Debian
drwxr-xr-x  7 aris aris  4096 May 15 08:22 Clonezilla
drwxr-xr-x 13 aris aris  4096 May 13 12:24 Hardware
drwxr-xr-x  6 aris aris  4096 May 11 01:40 ISO.0
drwx------  2 aris root 16384 Mar 24 20:34 lost+found
drwxrwxrwx  5 aris aris  4096 May 16 16:47 WindowsImageBackup
drwxrwxrwx 10 aris aris  4096 Jan  2 21:03 WindowsLocal_2021

I am not sure whether this can be applied to the situation described here as I do not know what the device "/dev/sdh1 on /media/keith/PYBFLASH" is. If it is flash memory it could work.

ondoho · 06-06-2022, 01:54 PM

Quote:

Originally Posted by keithostertag

I cannot seem to remount the pyboard rw, despite the mount report saying different:

Maybe this has some bearing on it:

Code:

errors=remount-ro

In other words, maybe there are filesystem errors? Have you checked?

keithostertag · 06-06-2022, 02:24 PM

Yes, I guess so!

Someone on the micropython forum (elsewhere) hinted I should check dmesg... and sure enough I had inadvertently corrupted the filesystem by disconnecting while it was still mounted. The new Debian version automounted it ro due to the corruption, while my older Debian system did not, hence my confusion.

I could not figure out how to properly mount the pyboard rw on my newer Debian system so I plugged it into my old system and ran fsck on it...

Code:

keith@e4300 ~ $ sudo fsck.vfat -a -v -V -t -p /dev/sdc1
fsck.fat 3.0.28 (2015-05-16)
Checking we can access the last sector of the filesystem
0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
Automatically removing dirty bit.
Boot sector contents:
System ID "MSDOS5.0"
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
       512 bytes per cluster
         1 reserved sector
First FAT starts at byte 512 (sector 1)
         1 FATs, 12 bit entries
       512 bytes per FAT (= 1 sectors)
Root directory starts at byte 1024 (sector 2)
       512 root directory entries
Data area starts at byte 17408 (sector 34)
       190 data clusters (97280 bytes)
63 sectors/track, 255 heads
       256 hidden sectors
       224 sectors total
Starting check/repair pass.
/main.py
  Contains a free cluster (116). Assuming EOF.
/main.py
  File size is 603 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
Checking for bad clusters.
Reclaiming unconnected clusters.
Starting verification pass.
Checking for unused clusters.
Performing changes.
/dev/sdc1: 23 files, 118/190 clusters

Now when I plug my pyboard into my newer Debian system it automounts properly as rw, and all is well :-)

Thank you for all your help!

Keith