WSL - ssh "could not resolve hostname"

After the recent conversation about WSL (Windows Subsystem for Linux) I decided to look at what I could shift to run on Finmark from my Windows desktop instead of the Linux laptop I usually use. I see posts that people run the CLI version of ROS on WSL - I haven’t tried that yet. And with the linux GUI coming, I also see that folks are running applications like RVIZ using WSL. But I decided to start simple and just ssh in to my GoPiGo3 to launch ROS locally on the robot. That should work fine for simple programs where I’m not running a navigation stack remotely. I think.

I immediately ran into the problem that I couldn’t ssh into my robot - I’d get a “could not resolve hostname” error when I tried (running Ubuntu 20.04). Some googling found that this issue goes back years, and a lot of somewhat arcane solutions were suggested. However it turned out to be a really easy fix. It just involves turning off “fast start-up”. The steps are listed here:

I wanted to post this here in case others have this problem.

Now on to running ROS via WSL…



I avoid Windows’ “fast startup” like the plague it is as it’s not a “true” startup, but rather is a form of hibernation and, (as far as I have ever known), Windows has never handled restarting from hibernation well.


This way a shutdown and restart clears out any cruft and starts fresh.


Windows isn’t the only system to implement a “fast startup” type of startup process which usually begins with a system that is - at least - partially running already, is then suspended, and has its state saved in a kind of a hibernation file.

On restart the system is restarted to some minimal point and then the state of the suspended system is restored.  From a purely software point of view, it’s like “unwinding the stack” and restoring the state of a piece of software before it was interrupted.  And, (in theory), “unwinding the stack” should restore everything to the way it was before.

The problem here is that a computer system isn’t just software.  The system contains hardware - complicated hardware - that can’t simply be “folded up and put away in a drawer” like clean bed sheets.

Preserving a particular hardware context, (which can include status registers, shift registers, stack values within the hardware, the content of any internal cache, the state of the hardware’s internal state-machine, and a whole host of other things), isn’t easy.  This internal state of the hardware isn’t transparent to the outside world, nor can it be - think SPECTRE, MELTDOWN, and a whole host of ransomware attacks which used hardware snooping into a system’s internal state to compromise a system.

As a consequence, I have never been satisfied with the way “fast start” works, be it Windows, Ubuntu and it’s derivatives, or whatever else, so I have always recommended a complete and total shutdown.

If a rapid startup is important, I recommend investing in a good SSD instead of the “fast-start” startup process.


I had never actually thought about the details at that level - makes sense.

1 Like

In medicine, there’s a saying: “You have to think like the disease to recognize the symptoms”, and I guess that’s why I’m (somewhat) good at hardware - I can “think like the hardware”, which allows a lot of stuff to make sense.

That’s one of my problems with software. . . .

Even a complex piece of hardware does not have a potentially unbounded state.  If you are “here” within a particular piece of hardware’s operation, the number of places you can go from there is limited.  It might be large, but it’s still limited and can be modeled.  In essence, a hardware device can be represented by a finite state machine.  The state machine might be LARGE, and the number of potential next-states can be huge, but it is not unlimited.

Software doesn’t have this limitation.

If you imagine yourself, (mentally), as being inside a piece of software, the number of possible places you can legally go from where you are right now rapidly approaches infinity - there is no finite number of states.  The only real limitations are battery life, or exhausting a finite hardware resource like RAM or storage.

That is why, (for me at least), writing software is so difficult:  The number of possible solutions rapidly expands to near-infinity and becomes massively overwhelming.

The struggle for me is discovering how to limit the problem’s scope without eliminating valid solutions at the same time.


I’m actually in medicine and can’t say I’ve heard that one :slight_smile: . But the point is well taken.