VS Code OSS doesn't recognise udev rules

mogplus8 · April 23, 2020, 1:33am

This has just started happening in the last couple of days, not sure why. Whenever I try to upload a program (even a basic blinky) I get the warning about installing udev rules. I have (re)installed them. Lots of times. Both with the “curl” command shown in the documentation, and by downloading the file and manually copying it to /etc/udev/rules.d.
VS Code OSS and Platformio have been working up until a couple of days ago. To double check I’ve also tried it on my “secondary” install of Mint 19.3 on another partition (as my daily drive is a bit of a mess and I thought I must have screwed something up) that is relatively clean, and had the same problem. I also tried it with the MS version of VS Code (on my “clean” install) and had the same error message appear.
What do I have to do to get PIO to recognise my udev rules?
Thanks,

BTW I don’t know if it’s related, but VS Code OSS now fails to find my Due on /dev/ttyACM0, even if I specify upload_port = /dev/ttyACM0 in the platformio.ini. However the MS version of VS code does find it (without upload_port specified) and successfully uploads the program.

EDIT for the record both versions of VS code failed to upload to a STM32F401RE Nucleo board, and both showed the missing udev file error message.
MS VS Code could upload a simple blinky to my Arduino Mega2560 board, but VS Code OSS could not. Again both versions gave me the udev rules missing warning.

maxgerhardt · April 23, 2020, 9:28am

The code says

github.com

platformio/platformio-core/blob/3a27fbc883cdcd12c241dafcf9d512c214c10813/platformio/fs.py#L89-L110


      
          if "linux" not in get_systype():
              return None
          installed_rules = [
              "/etc/udev/rules.d/99-platformio-udev.rules",
              "/lib/udev/rules.d/99-platformio-udev.rules",
          ]
          if not any(os.path.isfile(p) for p in installed_rules):
              raise exception.MissedUdevRules
          
          
origin_path = os.path.realpath(
              os.path.join(get_source_dir(), "..", "scripts", "99-platformio-udev.rules")
          )
          if not os.path.isfile(origin_path):
              return None
          
          
origin_rules = _rules_to_set(origin_path)
          for rules_path in installed_rules:
              if not os.path.isfile(rules_path):
                  continue
              current_rules = _rules_to_set(rules_path)

This file has been truncated. show original

So either of these files have to exist (otherwise “Missing udev” exception) and it has to match the content provided in the core (otherwise “Outdated” exception).

What exactly is the error message?

mogplus8 · April 23, 2020, 2:40pm

Hi @maxgerhardt. This is what I get. In case you can’t read it in the screenshot the text of themessage is:
Warning! Please install `99-platformio-udev.rules`. Mode details: https://docs.platformio.org/en/latest/faq.html#platformio-udev-rules
I think it’s supposed to be “More details”, not “Mode details” but that’s just me being pedantic.

Here is where my udev rules are

and my Due really is plugged into /dev/ttyACM0

I downloaded and reinstalled the udev rules today, so hopefully it is the latest version (from the website mentioned in the error message)

Thanks for your help.

maxgerhardt · April 23, 2020, 2:50pm

Can you just open a terminal, and do

python3 -c "import os; print(os.path.isfile('/etc/udev/rules.d/99-platformio-udev.rules'))"

Does that give True or False?

mogplus8 · April 24, 2020, 3:45am

@maxgerhardt It gives “True”.

maxgerhardt · April 24, 2020, 8:53am

Weird, I don’t see how that line should fail then.

You tried updating to the most recent development version of PlatformIO (pio upgrade --dev)?
What version of Python are you running? Python 3.8 might cause problems, while 3.7 does not. (python3 --version)
Linux Mint is running on bare-metal and not in a VM?

mogplus8 · April 25, 2020, 3:43am

Hi Max,
Python version is 3.6.9
Mint is running on bare metal (both versions).
I hadn’t tried upgrading PIO to the dev version, bu I have now. Same result.
I’ll try it on my other Mint, and Manjaro, which I have in another partition. I’ve also got Fedora Silverblue in yet another partition, so maybe I’ll give that a crack as well.

EDIT On my clean Mint 19.3, Python is V3.6.9.
with VS Code OSS: Upgraded PIO to --dev, problem persist (in fact both. Still get the udev problem, and it can’t find my Due on /dev/ttyACM0 with or without the upload_port specified). Same problems with my Mega2560.
With VS Code MS version (flatpak): For mega2560, still get the udev missing message, but it does upload to the board successfully.
For my Due, I still get the udev missing message, and it also will not upload to my Due, the error is “No device found on ttyACM0”.
For my STM32F401RE board, I get the udev missing message and I can’t upload to it. This time the message is “Failed to init device”. (at least it found the port). I also got a message saying stddef.h missing. I found one buried deep in the platformio libraries, and added a build_flags = -I/home/ian/.platformio/packages/toolchain-gccarmnoneeabi/lib/gcc/arm-none-eabi/9.2.1/include, which solved that particular problem, but not the others.

I’ll try Manjaro next.
:-\ Ian

EDIT 2
On Manjaro:
Upload to Due works. No udev message.
Upload to Mega2560 works. No udev message.
Upload to STM32F401RE does not work. Error message is “Failed to init device”. No udev message.
Python3 is, believe it or not, V3.8.2! Maybe I should upgrade Python on my Mint installs…
Ian

EDIT 3
Thought I’d sussed it for a minute. Realised that Code-OSS was a flatpak and maybe MS VS Code wasn’t. I have to go back and check. I’m sitting here in Fedora Silverblue, which is driven by flatpaks (sort of) and both versions of VS code (OSS and MS) are flatpaks. So they should both not work, right? Well, yes and no. Both versions give me the udev missing error, which I suspect may be related to the flatpak not being given access to the directory(ies) where the udev rules reside. The OSS version also cannot find the Due, whereas the MS version can and successfully uploads the program. I thought it would need information from the udev rules to be able to do that, but apparently not.
I’ll go back and recheck what’s flatpak ans what isn’t.

EDIT 4
Back in primary Mint. both versions of VS Code are flatpaks. My next experiment is to download and install the .deb version of MS VS Code from the website.

My suspicions are vindicated. The .deb version does find the udev rules, and successfully uploads a program. I suspect a flatpak problem…
I don’t know if there is a non-flatpak version of Code-OSS, but I suspect not. I looked, but could only find an AppImage, that did not work. Anyway I’m giving up for now. At lest MS VS Code works, so I’ll stick with that for now.

mogplus8 · April 29, 2020, 5:34am

@maxgerhardt, finally solved at least part of my problem, the inability of VSCode OSS to find my device. It is a flatpak fix as I suspected. All that is required is to issue the command

flatpak override --device=all com.visualstudio.code.oss

in a terminal, and VSCode OSS can now find the device. This was reported on 29 October last year, but the flatpak manifest for VS Code has clearly not been updated.

Still getting the udev missing message though, but now the program uploads, and works. Maybe there’s another flatpak overrided to give it access to udev.

EDIT Not looking good… Set Udev rules through AppImage / Flatpak · Issue #435 · Nitrokey/nitrokey-app · GitHub

maxgerhardt · April 29, 2020, 8:39am

It’s still magic to me how a flatpack version fails to see /etc/udev/rules.d/* files and in your test, the native .deb packaged version works without problem. But that’s at least one problem solved. Seems like I never experienced the problem because I installed MS VSCode in the .deb version, too…

mogplus8 · April 30, 2020, 1:34am

@maxgerhardt I’m no expert, but I have spent many fruitless hours trying to make a flatpak version of another pretty obscure app that I use a fair bit. From my limited understanding of containers, which a flatpak basically is, they are completely self contained. Except when they need to access other parts of the system, and then the container has to be given express permission to access those elements. So if a flatpak requires access to a particular library to work, and the library exists, unless the flatpak has been specifically given permission to access that library, for the flatpak the library doesn’t exist.

Having said that the app I was trying to flatpak (opentx companion if it’s of interest) needs to be able to read from and write to a microcontroller based device (a model radio control transmitter) plugged in via usb port, and I just could not get it to talk to the device. Irritatingly it would work in test mode, using the flatpak “run” command, but once it was installed as a container, it just would not talk to the usb port.

I’ve given up on that project now. I was using Fedora Silverblue as I was interested in the concept of an immutable OS. But it’s still too beta for anybody other than techhead gurus who know Linux inside out and back to front, as my dear old Mum used to say. And I’m not one of them.

The thing that bothers me most though, is that I can’t be the only person on the planet using VS Code OSS flatpak. There must be thousands of us out there, but I have not seen any other discussion on the net about this issue. So is it just me, or am I being paranoid? <<twilight zone theme music>>

Ian