RfidResearchGroup/proxmark3
1
1
Fork 0
mirror of https://github.com/RfidResearchGroup/proxmark3.git synced 2024-09-20 15:26:13 +08:00
Code Issues Packages Projects Releases Wiki Activity

Minor update to WSL2 instructions

Browse source
This commit is contained in:
Henry Gabryjelski 2023-08-14 19:07:35 -07:00
parent 0b143e5bcd
commit c858d6fdc7
1 changed files with 8 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
doc/md/Installation_Instructions/Windows-WSL2-Installation-Instructions.md
View file

@ -156,27 +156,18 @@ However, it may be necessary to give the `udev` service a kind reminder:
## Inform udev that it really, really should work
The following workaround appears to work to get udev to apply the permissions
appropriately. Note that this may need to be run again, such as when the WSL2
distributions have been restarted. I don't know why ... but it's a small hiccup.
As of August 2023, the following needs to be done anytime the WSL2 subsystem
has been restarted (e.g., host machine reboot, first WSL2 console window, etc.).
Otherwise, it appears that `udev` service will not see the arrival of devices,
and therefore won't modify permissions on `/dev/ttyACM*` devices.
```sh
sudo udevadm trigger --action=change
```
General instructions suggested to use `sudo udevadm control --reload-rules`. However,
this may simply result in the following cryptic error message:
```sh
$ sudo udevadm control --reload-rules
[sudo] password for root:
Failed to send reload request: No such file or directory
```
_Note that the following should **NOT** be required:_
After this is run once, `udev` appears to work correctly (at least until the
host machine reboots or the last WSL console window is closed for a while).
One workaround is to simply ensure you keep at least one WSL2 console open.
```sh
sudo service udev restart
sudo udevadm trigger --action=change
```
## Verify Device Exists