"Clean" image of GoPiGo O/S 3.0.1 - Enjoy! (and please test!)

GoPiGo OS, DexterOS and Bloxter
1

Updated to new V3 release of these files.

As noted in the following posting:
https://forum.dexterindustries.com/t/possible-file-system-issue-with-gopigo-os-3-0-n/8680

I discovered a potential issue - severity unknown - with the current GoPiGo O/S images, including the 3.0.1 image.

The problem was that - when tested using certain types of microSD card adapters, (microSD USB “dongles”) - an e2fsck, (partition filesystem integrity check), would fail with reports of a corrupted directory.  Other kinds of card readers would scan the filesystem without significant errors.

Though this never seemed to fail on the Raspberry Pi itself, to me this was disturbing since I could not tell if, or when, this problem might manifest itself.  Perhaps some of the flaky, one-off, bizarre issues that were occasionally reported were caused by this?  Then again, maybe not?

IMHO, the only real solution was a re-packaged GoPiGo O/S 3.0.1 with a corrected filesystem.  To that end, I have done exactly that - I have extracted the files from the original image’s root filesystem, re-created a cleanly formatted partition, and replaced all the files and data.

After testing and re-packaging, I am making the corrected image available for public consumption.

The V3 image was released because if a severe bug I discovered in the expand-on-first-boot script that could destroy other partitions on the same media.

If you are interested in the technical details of the repackaging of this image, they can be found here:
https://forum.dexterindustries.com/t/possible-file-system-issue-with-gopigo-os-3-0-n/8680/9

The image has been re-packaged as a self-expanding image, (i.e.  It will auto-expand to fill the entire media on first boot), and it has been reduced to the smallest size image possible.

I have uploaded the image, (and a checksums file), to MediaFire:

Viz.:
The README file for the V3 release
https://www.mediafire.com/file/wn5xgai742axmgb/GoPiGoOS_3.0.1-corrected_V3_README.txt/file

The V3 image file (zipped)
https://www.mediafire.com/file/dm2tdlwaem4ivs7/GoPiGoOS3.0.1_V3.img.zip/file

The V3 SHA-1 and SHA-256 checksum file:
https://www.mediafire.com/file/6wjcjqtmj7wz7mj/GoPiGoOS_3.0.1-corrected_V3.img_checksums.txt/file

They are released for public consumption under the same licenses and conditions as the original image.

Please try them and report any discrepancies to this thread.

Thanks in advance for your assistance.

2 Likes
2

Update:

There is now a Version-2 of the corrected GoPiGo O/S 3.0.1 image file I previously uploaded.

Due to a (gulp! :flushed:) silly/stupid mistake on my part, I decided to re-build and re-create the image file.

  • What went wrong?
    • Somehow or other, I inadvertently copied a bunch of hidden files from the pi user’s home directory to the root of the filesystem.
       
    • Because the default behavior of the file manager is to NOT show “hidden” files, I did not notice this when I packaged the original image file.
       
  • Does this cause a problem?
    • No.  Those files are never referenced or used by the system - in essence, it is “litter” in the root filesystem.
       
  • I have already flashed this to a SD card and I am using it.  Does this mean I have to start all over again?
    • No.  These files are text files in the root file system.
      You can:
      • Choose to ignore them.
        – or –
      • Remove them manually.
         
  • If these files aren’t a problem, why are you creating a new version?
    • Answer:  My pride.  I don’t like having bad work circulating.
       
    • It gave me an opportunity to remove additional cruft to make the download image even smaller and faster.
       
    • Anyone who wants to download the images in the future doesn’t have to download and install the extra stuff - they start clean.
       
  • Are there any other changes, aside from “cleaning up the trash”?
    • Yes.  Since I had to jump through all the hoops required to repackage and re-shrink everything all over again, I decided to do some additional cleanup before packaging the image to make the image even smaller so it downloads faster.
       
    • What I changed:
      • I cleaned up the package manager cache.
        This is a standard “maintenance” operation that you can do yourself by running sudo apt-get clean.  This removed almost 500 megs of historical package downloads that do not need to be preserved.
         
        NOTE:  This DOES NOT actually un-install packages, it just removes the package file container that the package was in after it has been installed - sort of like throwing out the box after you unpack the new monitor or game system.
         
      • I cleaned up a lot of old, (and I mean OLD), log files created while the image was being built.  Once you start the system on your own robot, it will create a whole series of new log-files that are relevant to YOUR system, not the developer’s.
         
    • The result is a savings of 500 megs, (or perhaps more, I didn’t count that closely), ultimately reducing the uncompressed image size by almost a full gigabyte.
       
    • I also updated the checksums file to include checksums for the downloaded ZIP file and the internal image file too.
       

Here are the checksums:

 

Here is the README file:
(formatting changed to display correctly within this posting)

Updated download links are in the first posting.

2 Likes
3

Update:

There is now a Version-3 of the corrected GoPiGo O/S 3.0.1 image file I previously uploaded.

The download links are at the bottom of the first message in this thread.

I discovered a significant bug in the “re-expand on first boot” script that has the potential to entirely destroy a setup if there are other partitions on the media aside from “boot” and “rootfs”

  • What went wrong?
    • The “expand on first boot” script I was using has a severe flaw that can cause it to destroy the files on a device if it is not the only operating system or set of partitions on the device.

Prior to booting the image on my multi-boot SSD for the first time:

GParted_SDD
GParted_SDD1068×562 85.4 KB

 

After booting that particular partition pair, (partitions 5 and 8):

Crashed_Partitons
Crashed_Partitons790×540 55 KB

 
Obviously a Bad Thing.

  • Initial tests using an individual SD card did NOT disclose this issue.  It is only after I integrated the image into my multi-boot SSD drive that this bug disclosed itself.  I immediately withdrew the image and made it unavailable for download.

  • Does this cause a problem?

    • Only if you are using a device with more than the default two partitions on it, and you then add this to that media.
       

  • I have already flashed this to a SD card and I am using it. Does this mean I have to start all over again?

    • No.  If you have downloaded this image to an SD card, all by itself, and have booted it at least once, you are OK.
       

  • Why are you creating a new version?

    • The image itself is potentially dangerous if you try to install it in some way other than flashing it to an SD card with only that image on it.

    • I cannot assume that this image won’t be used in a more advanced way - it already clobbered one of my own 500Gb drives! - so I am creating a new image without that script - and using the “built-in” Raspberry Pi expansion script that has thousands and thousands of users and downloads.

    • Additionally, I created an article explaining how to use the built-in partition expansion script to do the same thing safely.

  • Are there any other changes?

    • Yes.I did a slight bit of additional cleanup that was missed in the original image.

    • I also updated the checksums file for the V3 image and zip file.

Here are the checksums:

And here is the updated README:

2 Likes