WSL - ssh "could not resolve hostname"

GoPiGo
,
#1

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:
https://stephenreescarter.net/wsl2-network-issues-and-win-10-fast-start-up/

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

Now on to running ROS via WSL…

/K

2 Likes
#2

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.

I ALWAYS set ALL my systems to COMPLETELY SHUT DOWN.

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

2 Likes
#3

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.

2 Likes
#4

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

1 Like
#5

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.

2 Likes
#6

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

2 Likes