Debian upgrade now automounts pyboard read-only!?!

[keithostertag]

I hadn't used my pyboard in awhile, and when I plugged it in the other day it was automounted as read-only!

Code: Select all

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)

I finally determined that, evidently, this started happening after I had upgraded my Debian (Cinnamon) OS from Buster to Bullseye last week or so. I checked by plugging the pyboard into another system I have which is running an older version of Debian and it automounts rw as it should.

I have a different pyboard made by Sanmuchina v1.0 which automounts properly as rw, so I am not certain there isn't something else going on as well.

I suppose I could attempt to write an entry to my Debian's /etc/fstab file to correct this, but I am not sure that is the proper way of fixing the problem. I'm also not certain of the proper fstab entry that would be correct to use.

Ideas?

Is there some config on the pyboard itself which tells a host system how it wants to be mounted?

I have the MicroPython v1.9.3-240-ga275cb0f on 2018-01-11; PYBv1.1 with STM32F405RG, running a current firmware.

[keithostertag]

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

[pythoncoder]

What does your udev rule look like? (in /etc/udev/rules.d/) This can force readonly mode. Mode 666 should be read/write.

[keithostertag]

Hi Peter-

The only rule I have in /etc/udev/rules.d is libsane.rules.

I have attempted to remount the pyboard and the mount command reports that it gets remounted rw but in fact it does not:

Code: Select all

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

But then when I attempt to write to it:

Code: Select all

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

Also, can't chmod on a ro system:

Code: Select all

keith@ada:/etc/udev/rules.d$ sudo chmod 666 /media/keith/PYBFLASH/
chmod: changing permissions of '/media/keith/PYBFLASH/': Read-only file system

[scruss]

anything relevant in dmesg output? I've had really corrupted USB mass storage devices appear read-only before

[keithostertag]

Well... I had not thought to check that, here's what I get when I plug the pyboard in:

Code: Select all

keith@ada:~$ sudo dmesg|tail
[10164.207577] sd 12:0:0:0: [sdh] No Caching mode page found
[10164.207585] sd 12:0:0:0: [sdh] Assuming drive cache: write through
[10164.243639]  sdh: sdh1
[10164.286932] sd 12:0:0:0: [sdh] Attached SCSI removable disk
[10164.459592] FAT-fs (sdh1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[10164.625129] FAT-fs (sdh1): error, fat_get_cluster: invalid cluster chain (i_pos 40)
[10164.625133] FAT-fs (sdh1): Filesystem has been set read-only
[10164.625136] FAT-fs (sdh1): error, fat_get_cluster: invalid cluster chain (i_pos 40)
[10164.625948] FAT-fs (sdh1): error, fat_get_cluster: invalid cluster chain (i_pos 40)
[10165.214475] FAT-fs (sdh1): error, fat_get_cluster: invalid cluster chain (i_pos 40)

Any ideas on how to fix that? Can I run fsck on the pyboard?

I have not been able to reset to factory settings following the directions... I press and hold the USR switch then press and release the RST switch and I get a steady red light. If I hold both the USR and RST switch down I get the blue orange and green LEDs lit steady until I release the RST switch.

Edit: Also, I can plug this pyboard into a different system (older Debian) and it mounts as it should (rw) and I can create files on it there.

[scruss]

I've never tried it, but this looks like a reasonable method: best practice for erasing /flash after updating firmware - MicroPython Forum. You might want to upgrade the firmware, as yours looks rather old.

For better file consistency, maybe disable MSC mode in boot.py and access the filesystem via Thonny / rshell / mpremote
(for reasons why: USB MSC mass storage mode as devel tool)

[keithostertag]

@scruss - thanks for those links, more food for thought. I've been playing around with finding a comfortable working method and inadvertently corrupted the pyboard filesystem.

I'm going to make a guess: the new Debian evidently automatically mounts the pyboard ro due to the corruption, while the older Debian does not. Both systems showed the need to run fsck on the pyboard (after I looked at dmesg ), but the newer Debian version goes one step further and auto mounts it ro. So the issue was not related to a change in udev rules or similar.

I was uncertain how to properly mount the pyboard rw on the newer Debian system, so... I plugged the pyboard into the older Debian system where it automounted it rw as per normal, unmounted it, then ran fsck on the pyboard with these parameters and results:

Code: Select all

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 all is well

I was hesitant at first and unsure whether I could safely run fsck on the pyboard.

Thank you Peter and scruss for helping me out with this!