Thought GoPiGo3 Dave might have fried my Pi4...Thank Goodness For GoPiGo OS

I’ve been flashing and configuring Ubuntu 20.04.1 LTS Server (64-bit) headless, like 10 times, over the last two days. All of a sudden - no can connect via WiFi. This was looking like perhaps the WiFi was blown.

I decided to try GoPiGo OS. It boots up, announces “WiFi ID”, and I can connect to it and do all the GoPiGo OS stuff:

  • Use Bloxter to set servo 1 to 90 deg (for 1 sec)
  • Drive and see camera output
  • ? (Help) ->Check Vital Signs:
    • Don’t know if I should be worried about Raspberry Pi: NOT_FOUND_b03115
      I’m hoping someone didn’t program a “Pi4 2GB” into the lookup table for RPi type

Although I can perform the “Connect To WiFi” operation, the OS claims it could not connect and goes back to Green.

At least using GoPiGo OS, I can see my Pi4 is OK.

Have to try rebooting the WiFi router.


  • rebooting router does not work,
  • rebooting Mac desktop does not fix it
  • arp -d x.x.x.x does not fix it

and totally not understandable:

  • when I use Carl to ping x.x.x.x (in an ssh from my Mac to Carl),
    Carl’s ping outputs:
    From [Mac IP] icmp_seq=1 Destination Host Unreachable

How is the Mac even involved in a ping from Carl through the router to Dave?


SOLVED - Sort of…

I went into the router and changed the reserved IP address for the Pi4’s WiFi MAC address/hostname Pi4BE32 to DHCP, and rebooted the Pi4 with the ROS2HH hostname Ubuntu Server and the router actually connected with the new hostname and new DHCP IP address.

I found a post on about ssh/vnc eventually resulting in
loss of connection and [IP] at (incomplete) on en1 ifscope [ethernet]
like I have been seeing. They stated I should:

Hopefully that will prevent this from happening again.


Did you remember to disable IPv6?


Before the first boot:

=== Disable ipv6

nano cmdline.txt
ctrl-e to end of line
add ipv6.disable=1
ctrl-x y

Last night and today, so far, all is working as expected and I am making progress.


Don’t forget to disable it within the network configuration screens too. I don’t know if system IPv6 settings override and/or replace the boot-time settings or not, so I always set both.

My assumption/suspicion is that after boot is complete, (and any DHCP/BOOTP messages have been received), the control over networking (and IPv6) is transferred to the running O/S.

Of course, I could be wrong, but I don’t trust it.


That’s one of the issues on the plate - headless so I don’t have “screens” to help.

I’ve been really banging my head against the desk trying to get a VNC desktop configured, always making two steps forward followed by one step backwards and a head spinning trip around the Internet trying solutions that worked for “not exactly the same” configurations.

At the moment, I have a very sweet VNC LxQt desktop (with “panel” that does not crash) available if I start the TigerVNC server at the command-line, but nothing when started as a service. Weird hurdle that I don’t find has happened to anyone before…. It probably is some group permission thing but not really understanding Linux is something 20 years of using and “developing on” could not solve.


Hmm, just saw this. It’s a constant battle to keep abreast of the number of Pi variants out there. All Pi4 2g are not the same…

But first, which GoPiGo OS did you try? Was it 3.0.3?


My notes say v3.0.3 June 20,2022


Sure enough, 3 new versions of the Pi4 have come out since GoPiGo OS 3.0.3

V1.5 for 2G, 4G and 8G boards.


Is it the firmware update process that needs to know what processor it is running on?


The firmware definitely needs to know that, as flashing is a different process on a Pi4.
And then BrickPi (using the same library) needs to know Pi2 vs Pi3/4 because the serial communications got changed.
GoPiGo OS also needs to know Pi2 vs Pi3/4 in order to offer the access point.