Repository navigation
mpremote errors on SAMD51 + ROMFS during rm -r :/ #19636
Description
Activity
samd21 passes
In the octoprobe teststand, there is as https://learn.adafruit.com/introducing-itsy-bitsy-m0 which is a samd21.
In this testrun https://reports.octoprobe.org/github_selfhosted_testrun_727/octoprobe_summary_report.html all tests running on 5f2a-ADA_ITSYBITSY_M0 passed.
- changed the title
[-]mpremote errors on SAMD51 during rm -r :/[/-][+]mpremote errors on SAMD51 + ROMFS during rm -r :/[/+]on Aug 18, 2026 - the error is triggered by having a non-empty ROMFS +
mpremote rm -r :/ - or any file in the romfs
mpremote rm -r :rom/utils.mpy
$ mpremote tree tree : :/ ├── main.py ├── no_boot.py └── rom ├── data.romfs ├── lib │ └── helper.mpy ├── myapp.mpy └── utils.mpy- while attempting to delete
/rom/data.romfsthe following error is triggered. - in turn this is not "properly translated" by
_convert_filesystem_error(), as it is not a file system error
The same happens on the REPL
MicroPython v1.29.0-preview.718.g2e3304a128 on 2026-08-16; Wio Terminal D51R with SAMD51P19A >>> import os >>> os.remove('/rom/data.romfs') Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: no such attribute >>>On fixing
Then the Q is if the fix should be in mpremote , or on ROMfs.
Best would be for VfsRom to implement remove, rmdir, mkdir, and rename stubs that raise OSError(MP_EROFS)
A mpremote fix would only mask this omission, and other tools would need a similar workaround.- the error is triggered by having a non-empty ROMFS +
Port, board and/or hardware
Wio Terminal D51R with SAMD51P19A
MicroPython version
1.28.0 , 1.29.0-preview
Reproduction
Expected behaviour
expected properly formatted error
mpremote: rm -r: cannot remove :/ Operation not permittedsame as :
Observed behaviour
Additional Information
File "<stdin>", line 2, in <module>is likely one of the mini-scriptlets that mpremote usesCode of Conduct
Yes, I agree