Building landing wheels while in flight

[bmarkus]

Guys, really interesting topic. Just one thought. piCore has a roboust and well working update mechanism and tool set. Why not use it? Either we can add your components as standard tcz extensions to the repo or you can make your own online repo just with player components.  Maybe a private repo would fit better to your environment in case of custom kernel, but as RPi kernel is getting matured custom kernel can is not necessary. This would make life easier.

[mcdudeabides]

You had me at "make life easier".  I can search for making the tcz extensions and get some education.  How to do the private repo?  Hosting issues (space, bandwidth, etc.)?

PS - this may be OT, but is there a way with TC to boot a complete new instance one-time from a currently running instance without mucking up the existing cmdline.txt args?  I'm thinking something along the lines of "RPi GPU is loaded/initialized, I have a one-time kernel.img/initrd combo that I want to start with my own bootcode args (base, norestore, etc.), have my one-time bootlocal.sh do some specific things, then call for full reboot back to the initial starting point".  It's not as easy as just calling sbin/init again is it?

[bmarkus]

You had me at "make life easier".  I can search for making the tcz extensions and get some education.  How to do the private repo?  Hosting issues (space, bandwidth, etc.)?

Regarding extensions, see WIKI article http://wiki.tinycorelinux.net/wiki:creating_extensions

On repo, better to call it custom repo as private repo is discussed in the WIKI (obsolate BTW) with different goal. Such repo is a simple static WEB content with a specific directory structure. No PHP, no JAVA, ... It holds the tcz extensions with their support files like .info .list .md5.txt .tree .dep .zsync plus few repo support files holding tags, md5 and files provided by tcz's. Space depends on extensions but can't be a problem today for even the cheapest hosting site, bandwidth depends on users, update frequency, etc. But low.

[bmarkus]

PS - this may be OT, but is there a way with TC to boot a complete new instance one-time from a currently running instance without mucking up the existing cmdline.txt args?  I'm thinking something along the lines of "RPi GPU is loaded/initialized, I have a one-time kernel.img/initrd combo that I want to start with my own bootcode args (base, norestore, etc.), have my one-time bootlocal.sh do some specific things, then call for full reboot back to the initial starting point".  It's not as easy as just calling sbin/init again is it?

You can update all of your components on a running system, including adjusting initrd size in cmdline.txt keeping all of your sections but at the end you need a real physical reboot due to tcz's updated which are in use (loop mounted, see how extension update is done in TC) and kernel version change and changing RPi firmware. All can be scripted.

[mcdudeabides]

You can update all of your components on a running system, including adjusting initrd size in cmdline.txt keeping all of your sections but at the end you need a real physical reboot due to tcz's updated which are in use (loop mounted, see how extension update is done in TC) and kernel version change and changing RPi firmware. All can be scripted.

Thanks for quick reply and insight.  I was able to follow your logic and could manipulate startup as you describe when trying to puzzle out solution earlier.  I'm really looking for a way to revert failsafe if upgrade image hiccups (thinking as wifi,DACs, etc. become more intertwined, a good test image in lab could SNAFU in deployment).  Something along the lines of pseudo-logic:
1) start current image
2) download known-good image (a bare-bones, guaranteed to run, image)
3) download upgrade-image
4) save current image to revert-image
5) setup environment to boot known-good (can do so using your logic)
6) boot known-good with upgrade
7) perform upgrade-image
=== and this is where it gets tricky ====
boot once upgrade-image (don't change known-good startup)
9) if this boot is successful, change startup to always boot upgrade-image
otherwise reboot (probably power cycle) to known-good with auto revert to revert-image

This is probably a wish.  Most likely to do this would require puzzling out a custom bootloader that could make a decision branch on kernel/initrd combo to trigger.
 

[mcdudeabides]

Regarding extensions, see WIKI article http://wiki.tinycorelinux.net/wiki:creating_extensions

On repo, better to call it custom repo as private repo is discussed in the WIKI (obsolate BTW) with different goal. Such repo is a simple static WEB content with a specific directory structure. No PHP, no JAVA, ... It holds the tcz extensions with their support files like .info .list .md5.txt .tree .dep .zsync plus few repo support files holding tags, md5 and files provided by tcz's. Space depends on extensions but can't be a problem today for even the cheapest hosting site, bandwidth depends on users, update frequency, etc. But low.

Thanks for advice.  I'll defer to Steen on the approach he wants to pursue.  There is indeed elegance from the TCL world in using the extension system to provide all the builtin goodness of packages.  However there is a simplicity to the sourceforge SD card image approach.  The burn&boot masses have demonstrated ability.  It's kind of a chicken/egg dilemma.  There needs to be a working piCorePlayer image to be able to utilize the extension system for upgrades.  So far burning the SD card image seems to get the traction.  It's certainly worth puzzling over in my free time.

[bmarkus]

No chicken-egg paradigm. Simple .img is great to start system without complications nut once it is up and running you need a roboust and safe update mechanism. You can hide internals from users.

[mcdudeabides]

Hello again Bela.  Please forgive me if I'm being obtuse, but I am challenged in understanding how to apply the extensions concept.  If I were to put myself in Steen's shoes, then I would see piCorePlayer as the sum of the following parts:
1) the base TC kernel image (retrieved by direct download and burn)
2) the base support libraries (most likely the things found in a "full" Linux deploy, loaded by tcz- things like alsa, flac, ffmepeg, etc.)
3) support utilities (most likely things to extend Linux functionality, loaded by tcz- things like wireless, i2c tools, firmwares, etc.)
4) support applications (loaded by tcz, things like dropbear, perl, etc.)
5) third party applications (ready for ARM, not tcz packaged, requires custom integration - things like OliWeb, squeezelite)
5) end user support (the scripts, web pages, config stores that "are" piCorePlayer - custom created, integrated)

If I were the builder of the next flavor of the piCorePlayer image (assuming no kernel update), I could see the convenience of performing a tce-update (I guess this would have to be base norestore??) to refresh all the extensions.   The third party applications currently installed would be untouched.  Most likely I would then be making changes to the end user support environment (e.g. - troubleshooting new DAC shows new module and modprobe needed, base script modified).  I'm assuming at this point that all the changes for end user support would be packaged and become their own unique tcz? Is this package something that should be submitted to TC or is it in the "custom repo"?

Assuming the above, if I now try to think from the perspective of the end user.  I have a running instance of PiCorePlayer.  There is a button on the web page to "update" (assume no kernel update at this time).  Can I then call the tce-update and have it download and install the changes?  Is there a way in a running instance to drop all of the current extensions to allow a reload (could brute force all the LOOP devices)? I guess after this a reboot will be required.

I can see the application in going through minor iterations (e.g. 1.14a to 1.14b to 1.14c etc.) using tce-update.  I don't see it applying to kernel updates, or is that also something could work?

Forgive the ramblings, I had a quick window of time to ask the questions and wanted to get them out there.

[bmarkus]

Assuming the above, if I now try to think from the perspective of the end user.  I have a running instance of PiCorePlayer.  There is a button on the web page to "update" (assume no kernel update at this time).  Can I then call the tce-update and have it download and install the changes?  Is there a way in a running instance to drop all of the current extensions to allow a reload (could brute force all the LOOP devices)? I guess after this a reboot will be required.

You can run the tce-update script from the WEB application similarly as the factory GUi front-end does, check its source code. Update is placing new files to tce/optional/backup direcotry. It is checked by the system during startup and moves them to tce/optional before mounting them. You can pack your custom apps not in the main piCore repo to TCZ and submit to there. You can use a secondary repo also, just change the URL to your own online repo and do update in two steps. TC is a toolkit, you have a freedom to setup your system.

What is not covered yet is the base system update (kernel, initrd and firmware). It is in progress at my side. Hope to share in the near future for testing.

[mcdudeabides]

Thanks Bela.  I appreciate your tolerance for my continued education.  I've been looking inside the tce* scripts to attempt to grasp the concepts better.  Slowly it is sinking in.  Most of my puzzling in done offline with simulation in my laptop.  I'll need to find a way to set up in such a way that it can be exercised in isolation.

@Steen - To me, it seems there would be value in packing the OliWeb and Squeezelite applications for tcz install.  Squeezelite is in git already.  From scratching the surface, it looks like the tce tools provide for going all the way to source compile if needed (or just distribution/config of binary).  I have a sense that there may be some delay to the next iteration of piCorePlayer while exploring this philosophy.  It is not my intent to hinder progress.  To that extent, do you have advice on areas that would advance the project in which I could be useful?

[Paul_123]

Are you using the direct binary from triode for squeezelite, or do you have a self compiled version?   What are the compile flags?    Seems the extension route is the way to go.    It may be best to just plan this route.   If Bela is working on the kernel/base upgrade system, then perhaps that may be a better to use what he develops.

[mcdudeabides]

Are you using the direct binary from triode for squeezelite, or do you have a self compiled version?   What are the compile flags?    Seems the extension route is the way to go.    It may be best to just plan this route.   If Bela is working on the kernel/base upgrade system, then perhaps that may be a better to use what he develops.

Hello Paul.  You seem to have valuable experience and opinion in this area.  Consider me your willing student and let us use squeezelite as the tutorial.  Assuming that I have a clean install of piCore, with tcztools installed, what are the initial steps I should follow to start this process of developing an extension for squeezelite?

[Paul_123]

Hello Paul.  You seem to have valuable experience and opinion in this area.  Consider me your willing student and let us use squeezelite as the tutorial.  Assuming that I have a clean install of piCore, with tcztools installed, what are the initial steps I should follow to start this process of developing an extension for squeezelite?

The process of packing a extension is laid out in steens picore thread.    http://forum.tinycorelinux.net/index.php/topic,14634.msg89051.html#msg89051

That is for a kernel specific extension, but if you follow that as an example, extract an extension and look at the layout.   From that you can see how to create your own extension.

squeezelite itself is a single executable.   But it has dependencies to specific versions of libraries depending on who compliled it, so you will want to make sure to build a .dep file.    Dependencies can be an issue, for example.......libavcodec is one that is a big issue, as the dependencies for this on the tce repo are a mile long, when all we really want is this single library.   So we may want to consider including all of the required libraries in the squeezelite extension.   Or we can build each library into it's own extension and then just use a private Repo (I think the private Repo issue needs to be solved sooner, rather than later)

I use a version of squeezelite that I compiled on piCore, using the versions of libraries that are available on piCore.    My compile linker options are -DFFMPEG -DRESAMPLE   (I don't use -DDSD or -DVIS EXPORT)

[bmarkus]

Dependencies can be an issue, for example.......libavcodec is one that is a big issue, as the dependencies for this on the tce repo are a mile long, when all we really want is this single library.   

There is nothing against to add a minimal version of libavcodec to the official repo. squeezelite is also welcome in the repo as well as oliweb as a kind contibution to the piCore community

[mcdudeabides]

Thanks both for your advice. I will seek out Steen's posts that Paul indicated. Slowly I'm beginning to grasp the idea.

Sent from my Nexus 7 using Tapatalk