Linux + File system mounting

While building+installing the new firmware, I again had my Linux system go into a state where it refused to remount the BP file system.
When I installed the new firmware, (i.e. types $ and copied the firmware onto the file system), this error occurred - after the new firmware was installed and the RPi rebooted itself.

[ 9332.863386] usb 1-6: USB disconnect, device number 43
[ 9333.071303] FAT-fs (sda1): unable to read boot sector to mark fs as dirty

So it seems this is a RPi issue - not a BusPirate issue.
When it reconnected, the Linux log said

[ 9336.179356] sd 0:0:0:0: [sda] Attached SCSI removable disk
[ 9338.618719] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

BTW I tried several things to be able to remount the file system:

  • Unplugging and replugging the BP
  • fsck /dev/sda1
  • mount /dev/sda1 /mnt; umount /mnt
  • sync; sync; sync
  • restarting udevadm

Eventually the automount started working again. I think it was a timeout. But for 10 minutes or so, the BP file system wasnā€™t mounting.

And hereā€™s another thing I noticed. After it auto-remounted (and the system reported the file system was dirty), I umounted the file system, ran fsck, and fixed the file system. When I unplugged and replugged the BP, the system log said the file system was STILL uncleanly unmounted. But this time it did not auto-mount the file system.

1 Like

I run into that once in a while after the ā€˜$ā€™ command. For me, I disconnect the USB cable and restart udev. That works 100% of the time for me. The key, for me anyway, is to have the USB cable disconnected when restarting udev.

Ubuntu 22.04.4.

1 Like

Thanks! Iā€™ll try that. (I thought I did. Heh.)

2 Likes

Yeahā€¦ Totally agree itā€™s an rPI thing.

Itā€™s weird; Iā€™ll be developing something and iteratively write-build-flash-test. Itā€™ll be fine for days, then suddenly start not mounting. :person_shrugging:

1 Like

Occasionally Windows doesnā€™t like the jump to bootloader either. The drive just wonā€™t mount automatically. It comes back immediately with a re-plug though. Wonder if this is similar. We could try to explicitly kill the USB connection and add a delay when jumping.

1 Like

That might be a simple solution; I like that.

What happens is after the RPi gets new firmware, it disconnects the file system. The RPi developers said they added a delay, but this problem still happens. Apparently here is no standard way for an attached file system to indicate to the OS that itā€™s disconnecting.

1 Like

You are right.
And there is no way to force an OS to send a command within a given period.

Taken together, there is no minimum time in which firmware can delay, and be sure that a host will ā€œseeā€ a media change. It follows that media change notifications cannot be relied upon as occurring prior to a reboot of the firmware.

Instead, the correct thing for a device firmware is to ALWAYS initialize with a few errors pending:

  • BUS RESET
  • Possibly mode pages may have changed
  • and of course Media may have changed

Of course, none of those errors should occur for SCSIOP_INQUIRY ā€¦ itā€™s a special case command where errors should be avoided whenever possible (e.g., except for bus noise causes CRC errors or the like).

1 Like

As someone who has a few too many boards from Adafruit, Iā€™ve seen similar issues while updating firmware on various bits of hw.

Being a linux user, I generally try to make sure my external device filesystems are unmounted before disconnecting them. The same rule applies to microcontrollers - especially given that they disconnect themselves when they automatically reboot.

When you apply a firmware update to a self-rebooting device like this, the update wonā€™t actually be written until a sync is performed - either by the OS, manually, or on umount. To that end, Iā€™ve generally found the best policy when updating one of these devices is to immediately umount after sending the firmware to minimize the possibility of fs corruption: cp -av firmware.uf2 /mnt ; umount /mnt (or whatever your mount point is). Obviously, this wonā€™t work if youā€™re dragging-and-dropping firmware to the target board in an X/VNC/Wayland session, so I generally recommend using the shell for this process.

The umount will force a sync, writing the copied data to the device, and then immediately unmount the fs as the device reboots. So far, Iā€™ve had that work well for me, though I canā€™t say if thereā€™s additional timing issues there or not.

2 Likes

Ah. Iā€™ll add that to the next revision of the BusPirate.sh script!

3 Likes