I received the ClockworkPi as a holiday gift, and assembled it last week.
The assembly was largely seamless, with two exceptions:
The screen cable is very difficult to determine which way to put it in, and perhaps took the longest. The instructions should be revised with much more detail on this part.
The extra 5 key thing should be included in the main instructions. I had to almost disassemble the assembled device to install this part, which was time consuming as it is hard to get all the cables, those rubber things, and such, in place and hold it together to fasten the top and bottom together.
It did operate on first USB plug-in, and correctly. I immediately went to the settings and reviewed everything, set up WiFi, and did a check for update. It had an update (df170b7 in the confirmation screen), so I installed it.
And… That was the end of my Gameshell. From then on, it would boot only into a “Loading” screen. This apparently means I need to download and re-flash the 16GB microSD card, which I will do in due course, but is entirely disappointing and an unacceptable “first run” experience. I wanted to relate the experience so that the developers can test what I did and fix the “first run of death.”
The version I had at receipt was:
Launcher: stable 1.25
Kernel: Linux 5.2.0-rc4-clockworkpi-cpi3-00001-gac0d4e (and it runs off the screeen)
Another question: How do I tell if this is the v3.1 CPU? Mine says:
I think that could be due to the recent update of launcher alone with OS v0.5 image. Your gameshell probably came with OS v0.4 image. I had the same problem a few days ago. You need to revert the launcher to older version, for example, the ebe816b commit in Dec 4 (https://github.com/clockworkpi/launcher/commits/master?after=18c1b186af6383c7c99ca88335182e996112b554+34) before the new feature of warehouse was introduced.
To do that, first you need to be able to SSH into your gameshell. (How to transfer files with TinyCloud through SSH) Did you by any chance opened TinyCloud before the launcher update and note down the IP address? If you did, you can SSH into your gameshell by typing in command line of you computer: ssh cpi@[ip address of your gameshell] and type in password, which is cpi.
After that you can set up git and pull the old version from github. I will explain to you what to do next in details if you can do SSH. If not, I guess you need to reflash the SD card. (Unless there is a way to get the IP address of your gameshell)
as it say some update could break things, that’s sad but that’s the point, now two possibilities,
try repair your system
reflash it from scratch
easiest way is the reflash, not just repair it will also introduce a fresher system based on latest debian, you could also choice the recently ported arch linux
at this point yet you will need touch a little bit command line by time to time depending on latest state & evolution…
After I posted this, I did download the v0.5 image from another topic in this forum, as well as the balenaEtcher (although I could just as well use “dd”) and flashed the microSD. Just now, I reassembled the unit and powered it on, and it booted twice (not sure why, but assume it is related to the auto-expand functionality in the release notes) and eventually put me into the GUI. It now shows:
Kernel Linux 5.3.6-clockworkpi-cpi3
Launcher: stable 1.25
OS Image: V0.5
Setting up the WiFi, I note it shows each of my access points (all using the same SSID, but with different BSSIDs of course) as separate networks.
Now, as to the first launch experience:
I personally find it unacceptable to have a self-update function that is not fail safe in this day and age. The update needs to either work, or fail, atomically, and leave the system in a known good (unchanged, or functional upgrade) state. Now that it is known (and Kirais explained it was known), the update needs to be staged, so that state A (the version I had, 0.4) will update to an intermediate state B that works, which can be updated to the final state C (0.5 that I now have). I don’t know anything about how this system works - I just got it after all - but having to reflash, or pray that you have SSH access, is not really a good idea. There will be kids and novices using this device. I almost got two or three so my kids could use them too, and they would not be able to use them after a failed update. I realize this is a device aimed at hackers probably, but even then having an update that leaves a system unusable should just simply not happen. I realize not every eventuality can be taken care of, but certainly a stock 0.4 should be able to update to 0.5 safely and should have been extensively tested before 0.5 was released. Just my opinion.
Cheers
(PS: Yes, I can get the IP address of my Gameshell from my WLAN admin, and yes, I can SSH and do anything necessary at the command line. I have been running Linux for almost 28 years, yes, since 0.0X in early 1992.)
Re: The 3.1 board, if it has a mini hdmi port, you’ve got the 3.1.
That’s the easiest way to confirm. Otherwise, you can confirm by making sure you have 1GB of ram.
whatever you do don’t try to change theme in v0.5, i had a nightmare it just crashes system and you have to reflash it a couple of times. losing everything i’d got running. it gets better but i felt like just binning mine.
I have mame, gb, gba and 1 ps1 game running. still trying.
There was a recent launcher update fix for that.
In future, instead of having to reflash, if it does that, just delete the ~/.gameshell_skin file, or edit it to point to the default theme. I hope this post gets to you in time!
That said,I actually had problems with the OP-1 theme in a customised OS based on 0.5. On the release version, I just deleted it to avoid users having problems.
I actually never bothered checking the logs to see exactly why it hangs.
Did anyone check?
I think @PiNYC stumbled into a huge usability fail that I’ll probably add to the getting started wiki. The “Update Launcher” function is very specifically tied to…well…updating the Launcher. Because of the release process, this updated him to the latest launcher and caused problems since the OS was still on 0.4.
Short term, there should be some warnings about checking for updates to the gameshell OS FIRST before updating the launcher. Edit: I’ve added a note in the Danger Zone section of the Up and Running wiki
Long term, there needs to be an improvement to the release process. The launcher itself isn’t versioned, and that can create problems for compatability and version drift with the GameShell OS versioning.
Unfortunately, I think @PiNYC’s response is correct, this is still a relatively “hacker” product and requires a level of technical understanding, and comfort with bricking the device.
Perhaps even a similar process to Android phones, where you need to click on something 7 times to confirm you want to enter developer mode can release some locks on things like that.
Re: the launcher update, perhaps changing the git checkout to be version specific would help with versioning errors. I think I mentioned a very similar remedy to someone else’s problem in another thread. Ie, it seems to be a common thing.
Getting back into the cadence of using Releases will help with versioning and give some guidance on how the Update Launcher function could work in the future. Imagine if each minor version of the OS is tied to a major version of the Launcher. For example, what if GameShell 0.5 is tied to GameShell Launcher 2.x.x? That kind of logic can be implemented into the launcher itself to prevent this kind of mismatch in the future
…p.s. i also empathize with the team here though. It looks like there’s only a handful of engineers on the GameShell dev team and I’m sure they have their hands full.
I should have shared it on the forum so that CPI staff could have time to fix it…
! I have no idea about Linux. 