I’m not sure if this is a flatpak problem, a Code-OSS problem, a PlatformIO problem, or an OS problem. I know it occurs on multiple OSes that I’ve tried (Manjaro and Mint as well as SB), so not a Silverblue problem per se, but as SB relies so heavily on flatpaks I thought I’d ask here. If anyone can direct me to the correct forum to ask this question then please do. I’ve tried Platformio, they were not able to help. Tried Mint but no response there yet. Couldn’t find anything relating to code-OSS.
I use Code-OSS with the PlatformIO plugin a fair bit to program my Arduino (and other) micro boards. However in the last few days I’ve run into a problem. Neither VS Code (official version) flatpak nor Code-OSS (open source version) flatpak are able to read /etc/udev/rules.d. Also Code-OSS has not been able to find my board, even though it is plugged in and specified correctly to Code (I checked many times). MS VS Code can find the board and successfully uploads the program, even though it has not read the udev rules.
I have found a fix for Code-OSS not finding the board. This command
entered in a terminal fixes the problem and Code-OSS successfully uploads to the board. However I have not been able to find a way to enable either of them to access the udev rules. I’m not entirely sure how important this is, given that the program still successfully uploads to the board.
Is there a fix? Or should I just be ignoring the error (it’s only a warning from PlatformIO saying I haven’t installed the udev rules for it) ?
I have installed the rules, it’s just a matter of copying the file to the udev directory, /etc/udev/rules.d.
According to my limited understanding they help the system to determine what kind of device has been plugged into a usb slot. There’s lots of them. Have a look at /lib/udev/rules.d.There are many examples there. The user defined udev rules are in /etc/udev/rules.d. If you’ve ever installed anything that needs udev rules they will most likely be in this library.
It may be a meaningless error, its quite possible PlatformIO is just trying to “confirm” that rules exist by reading /etc/udev but since its denied access to that directory assumes that rules don’t exist.
You can provide an override for filesystem thusly:
You may need to fiddle around with that filesystem option to provide the exact path needed. Also I added the ro option for read-only as I assume it doesn’t need to write to that directory.
I’m aware of what udev rules are, though they can be used for more than just altering file permissions.
It seems like these merely offer rw permissions for every single board supported, as well as ignoring a port for ModemManager.
I think @u297b is spot on regarding the cause of the warning.
@kon14, apologies, I didn’t mean to offend. @u297b thanks for you suggestion. I tried it but unfortunately it made no difference. I tried it with /etc/udev as you suggested, and also with /etc/udev/rules.d and /etc, but I still get the same warning message. I also tried it without the :ro, although as you noted it should not need write access to that folder, but the warning message persists.
No offense taken.
Perhaps if you could provide the exact warning string paired with the steps to reproduce it (more importantly, just when does it pop up) we could find out whether it’s actually important or a false alarm stemming from lack of read access to some path in host.
hit the “compile and upload” button
Here is the output
> Executing task: platformio run --target upload <
Processing megaatmega2560 (platform: atmelavr; board: megaatmega2560; framework: arduino)
-------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/atmelavr/megaatmega2560.html
PLATFORM: Atmel AVR 2.0.0 > Arduino Mega or Mega 2560 ATmega2560 (Mega 2560)
HARDWARE: ATMEGA2560 16MHz, 8KB RAM, 248KB Flash
PACKAGES:
- framework-arduino-avr 5.0.0
- tool-avrdude 1.60300.190424 (6.3.0)
- toolchain-atmelavr 1.50400.190710 (5.4.0)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 10 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Checking size .pio/build/megaatmega2560/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM: [ ] 0.1% (used 9 bytes from 8192 bytes)
Flash: [ ] 0.6% (used 1546 bytes from 253952 bytes)
Configuring upload protocol...
AVAILABLE: wiring
CURRENT: upload_protocol = wiring
Looking for upload port...
Warning! Please install `99-platformio-udev.rules`.
Mode details: https://docs.platformio.org/en/latest/faq.html#platformio-udev-rules
Auto-detected: /dev/ttyACM0
Uploading .pio/build/megaatmega2560/firmware.hex
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e9801 (probably m2560)
avrdude: reading input file ".pio/build/megaatmega2560/firmware.hex"
avrdude: writing flash (1546 bytes):
Writing | ################################################## | 100% 0.29s
avrdude: 1546 bytes of flash written
avrdude: verifying flash memory against .pio/build/megaatmega2560/firmware.hex:
avrdude: load data flash data from input file .pio/build/megaatmega2560/firmware.hex:
avrdude: input file .pio/build/megaatmega2560/firmware.hex contains 1546 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.23s
avrdude: verifying ...
avrdude: 1546 bytes of flash verified
avrdude: safemode: Fuses OK (E:FD, H:D8, L:FF)
avrdude done. Thank you.
============================================== [SUCCESS] Took 2.15 seconds ==============================================
Terminal will be reused by tasks, press any key to close it.
The upload is successful and the program runs, even without the udev rules.
@u297b, the above result was with the permissions for /etc/udev, /etc/udev/rules.d, and /etc/udev/rules.d/99-platformio-udev.rules all set to read/write for all levels (I did it with nautilus rather than command line). They were originally read/write for root, and read only for group root, and everybody else. So looks like not a permissions issue.
This is my udev file
So I cloned their github repo and used grep to look for the above warning string, which led me to the declaration of an exception class, which I then traced back to an fs check raising that exception:
if not any(os.path.isfile(p) for p in installed_rules):
raise exception.MissedUdevRules
So it’s indeed nothing to be worried about.
I’d try and push a PR for this upstream, though I don’t believe there’s any clean way to gather such information from inside a Flatpak environment just yet.
Now that I come to think of it, checking whether their own udev rules file exists is kind of hacky solution as well.
