@Paul and Steen-
I agree with moving forward with some mechanism for upgrading without having to remove the SD card. I do think that given the unique case that is piCorePlayer there is a way to accommodate upgrades with current session running shell script logic. If there are serious architecture shifts for Tiny Core (or any dependent packages), then the upgrade process would become more disruptive (up to the point of full SD card rewrite). There may need to be some deliberate change for the approach of someone starting new versus someone upgrading from prior start. I would also anticipate a challenge in enabling/supporting the wide range of DAC cards. Eventually there will be conflicts that prevent providing protocol stacks for all known DACs. This would almost trigger a "TCE-like" environment where there are unique "packages" to load for the different DACs. In any regard, I would be willing to volunteer efforts along the line of providing upgrades to the degree that we can control it.
I agree that this will be a constant struggle to support all the new DACs that will be developed. However, for the near future I can't see that it will be possible to build "DAC packages". As it is now these new DACs require changes in the kernel and support for new DACs are added from time to time via a new kernel and modules.
For each major update of piCorePlayer I have build a new kernel and modules (in order to support more hardware and improve stability), so for piCorePlayer I think we often still need to supply our own kernel.img and module.gz. From time to time we are in sync with the official piCore development of bmarkus and sometime we are in front.
So we need to be able to download our own kernel.img and module.gz.
Therefore, we also need to be able to create and download the Kernel specific tcz packages (Alsa and wifi).
I am also (quite selfishly) thinking of other embedded projects that would benefit from a remote upgrade approach. The benefit of Tiny Core is that it is efficient, frugal and very embedded-friendly. The downside is that it rapidly evolves and the upgrade method is now targeted to providing a new system image on a vanilla startup. Thinking back to my process control days on Modcomp and Honeywell trigger a desire for a more robust deployment approach..
I'm not sure I completely understand.
But maybe piCorePlayer is not a good model for developing a generic in situ update system for piCore. The problem with piCorePlayer is that it often use its own kernel and module, therefore, the update system will be different compared to a system build on vanilla piCore and its modules.
Do you think it possible to include at least the "boot once" logic? The goal being that a new image can be booted once, and if there is no way to confirm a positive execution (through user confirmation or script logic), then on power cycle the last "known good" image will be reconstituted and provide a recovery avenue? The most elegant approach would provide the means at bootload (maybe like the berryboot VNC - and all it's hairy dependencies). Perhaps there is something less elegant that will get most of the functionality.
In any event, I am willing to invest time in whatever approach is considered most viable and desired.
This sound good. However, I have no idea how to make it work.
Steen - this is really your creation. Do you have any guidance?
Sorry - no, I think that I'm the one who knows the least when it comes to linux and programming.