I’m doing all this under Windows 10, wsl2. I’ve managed to build the firmware but can’t burn it. Because of the oddities of how wsl2 accesses block devices (via p9) I gave up trying to write direct to the device. If I can just create the firmware image, that’s easy enough to get onto the SD card.
The mix burn help suggests I can create such an image, via mix burn --device <filename>, but that nets this error:
Start-Process : This command cannot be run due to the error: The system cannot find the file specified.
At line:1 char:1
+ Start-Process fwup -Verb runAs -Wait -ArgumentList "-a -i \\wsl$\Ubun ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Start-Process], InvalidOperationException
+ FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand
That’s obviously powershell output, so I thought as all I’m trying to do here is write to a file it might be simpler to use the linux fwup (which I also have installed). So I removed the windows fwup.exe from my path, and now I get:
❯ mix burn --device ./image.img
==> nerves
==> sensor_hub
Nerves environment
MIX_TARGET: rpi0
MIX_ENV: dev
** (Mix) fwup.exe is required by the Nerves tooling.
Please see https://hexdocs.pm/nerves/installation.html for installation
instructions.
Can I force mix burn to allow me to use the linux fwup so I can just write to a local filesystem image?
I managed to force use of the linux fwup utility - a quick trawl through the nerves source revealed I could trick the mix task out of knowing I’m on wsl by touching a /.dockerenv. So I created and built the image (which boots fine so all good now ).
Two questions for future reference:
Should I have been able to use mix burn to burn directly to the SD card? To get access to the latter at all from wsl I had to mount it (with -t drvfs). But I didn’t know what device to proffer to mix burn.
Is it expected that writing instead to a file image would also fail under wsl?
I installed fwup.exe via chocolatey and then running mix burn from ubuntu wsl2 opens an elevated cmd.exe window and I see the following in bash:
juan:~/.../elixir/nerves_livebook (main *%=)$
mix burn
==> nerves
==> nerves_livebook
Nerves environment
MIX_TARGET: rpi0
MIX_ENV: dev
'\\wsl$\Ubuntu\home\juan\code\elixir\nerves_livebook'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
Use 14.84 GiB memory card found at \\.\PhysicalDrive1? [Yn]
FYI chocolatey ensures it’s in you windows path and windows adds it to wsl2 path & mount
juan:~/.../elixir/nerves_livebook (main *%=)$
which fwup.exe
/mnt/c/ProgramData/chocolatey/bin/fwup.exe
Thanks. I assume then it’s something to do with the chocolatey install (or lack thereof in my case). I did have fwup.exe available in both windows & wsl paths, but set that up myself after a manual download. I avoid chocolatey/scoop/winget etc (I don’t want to maintain parallel toolsets, and keep all dev work exclusively within wsl).
Oh well. Perhaps something to dig into at some stage. At least I do have a working nerves image for now, though it has taken far longer than I expected.
I remember also banging my head around this issue and just decided to take the plunge with chocolatey as a last resort which worked. Also agree about having to juggle multiple tools but in this case this was the easiest way that let me just get on with it.
I think the main issue is that you can’t have direct access to the usb subsystem from wsl2, but I don’t know why we both had a hard time with the manual exe install.
Perhaps with some more time I’d revisit the subject and try to solve the issue once and for all using the manual way, and write a post about it for others.
That’s the crucial aspect I think. My manually installed win32 fwup.exe does auto-detect my SD card if I run it from an elevated windows command line. So there must be something amiss in the way it’s called from elixir. I might dig further, but now I have a booting nerves image I’m impatient to get it doing something!
Me too for now (thanks though for the pointer). I think nerves’ approach of getting native Windows to handle this is fine (WSL is a bit of a moving target). But in this particular case it’s getting something wrong when invoking a non-chocolatey install of fwup.exe. I think, anyway - I only have a very shallow grasp of the moving parts here.
Btw, do you ssh into your nerves device from a wsl shell, or from powershell/cmd? If the former, what do you do about mdns not bridging the network gap? Thus far I’ve had to ping nerves.local from powershell to get the IP, then just ssh to the latter in a wsl/zsh shell. It’s a bit irritating. Maybe I should just set up a static dhcp lease for the pi, & add an entry to /etc/hosts. But if there’s a neater solution I’d be interested.
Ok this is embarrassing - mix burndoes work perfectly well with a manually-installed fwup.exe after all. I had a quick look at the chocolatey package - it doesn’t do anything substantially different from just plopping the .exe in the path, so I realised I must have done something daft. Which indeed I had - I had put fwup.exe in a directory that used to be on the path on my machine, but was no longer.
