Doing a complete upgrade, (allowing everything to upgrade), on GoPiGo O/S causes the GoPiGo functionality to stop working.
- It cannot find the GoPiGo hardware
- It cannot detect the robot.
- And as a consequence, nothing else GoPiGo related works.
Note that I am using the term “complete upgrade” deliberately, as running a “full” upgrade may, and can, do additional version related upgrades that are outside the scope of my research. By “complete” upgrade, I mean running
apt-get upgrade and allowing it to install all the upgrades it suggests without modification.
You can restore limited functionality by running
sudo pigpiod, but that only restores a small subset of the robot’s functions.
My initial research showed that doing the upgrade, but “holding back” the pigpio, pigpio-tools, and pigpiod updates does not cause the robot to fail.
Also, after a complete upgrade, the logs show errors that pigpiod cannot bind to port 8888
Subsequent research has been confusing as sometimes the upgrade is completely successful and everything works without exception - but other times the upgrade fails with a loss of GoPiGo functionality as noted above.
Current research shows the following possible suspects:
- The pgpio tools and libraries themselves.
- The updated rpicamera libraries - especially if you accept the “maintainer’s version” of the rpicamera config file.
- This is the current focus of my investigation at the present time.
- Note that these libraries do not include the new libcamera libraries from Bullseye.
- IPv6 related issues.
- Power throttling issues.
- Something else, as yet undiscovered.
Additionally, it should be noted that the original “as shipped” image for GoPiGo O/S 3.0.1 is not correctly packaged and the root partition within the image is truncated at the end of the partition. Since it is not possible to know exactly where individual parts of the data are stored within the original media, there is the possibility that something important was lost.
I cannot prove that this is true, but the possibility of data corruption cannot be ignored either.
I do not consider this a likely cause for the issue being described, especially as a subsequent e2fsck does not disclose any issues immediately after the filesystem has been re-expanded and rebooted. As a consequence, I am assuming the image is not damaged, however it would be better if the original image were not truncated.
I have discovered that I can create a failing installation by updating a freshly built SD card image, though I have trouble duplicating this when I update an installation on my SSD.
It should be noted that the SD card installation is generated by “flashing” the as-shipped image using Etcher. However the SSD installation is done by rsync’ing a complete image from a SD card after it has booted and re-expanded the partition(s), and rebooted again. I do not yet know the significance of this difference, if any. To help clear this up, I have asked Nicole to re-package the pristine GPGOS 3.0.1 image with partitions that are not truncated. This way, I can rsync directly from the image file without having to re-create it.
Research is continuing. . . .
Any ideas or contributions would be appreciated.