Installation of additional IPK-packages after flashing

[Patrick B.]

Hi,

Our system is based on Conduits running a slightly customized base image and several ipk-packages created outside Yocto/OpenEmbedded and bitbake.

We have ipk-packages which are site dependent, i.e. configuration files describing the site-setup are generated and put in an ipk-file which is installed on the conduit. (For example the network-configuration and thus access to the internet).

We would like to handle the case where we need to update the rootfs and the kernel image. This will be done via the standard mechanisms (by putting files into /var/volatile/flash-upgrade).

Is there are mechanism already present in Yocto or mLinux which allows installing ipk-files stored in /var/volatile as well, right after flashing or during the first boot?

If not, what would be the correct way to implement this?

Thank you in advance.

—
Patrick.

[Jeff Hatch]

Patrick,

There isn’t anything that would automatically install .ipk files after an install of a new rootfs. You would probably have to create an init script that looks for files in a specific place and installs them if they are there and then deletes them so that they don’t get installed over and over again every time you reboot.

Jeff

[Patrick B.]

What specific place could that be? Is there a partition which survives reflashing of the rootfs?

Where can I hook into the flashing process? Flashing is done when the conduit is shutting down. I could put the IPK-files into the volatile-dir and after flashing move them onto the new rootfs where the script will install the files on the next reboot.

[Jeff Hatch]

Patrick,

There are not a lot of ways to get this to happen on the mlinux without more customization to your base image. You would need to include the init script in the image. To persist the .ipk files you can use an SD Card or you could put them in /var/config (/dev/mtdblock6) if there is enough room in that partition. I think that /var/config persists through the flashing process.

Jeff

[Patrick B.]

Thank you Jeff for your feedback. We are opting for using /var/config. It is 8MB only, but this is enough for the moment for our needs.

Side-question: what is /var/oem used for? On my installation it is empty.

I’m preparing a script which will install the IPK-files found there during the very first boot after flashing. I saw that there are already things done during the very first boot after flashing. Could you point me to the place in the mlinux-git-tree where the scripts are to be placed? Ideally I’d put the script into my user-layer and automagically my script is called during the first boot. What do you think?

[Jeff Hatch]

Patrick,

The /var/oem is not used for anything on the mLinux model. It is used for custom customer configurations on the AEP model.

Your proposal for the how to get the script into your image sounds reasonable. Most of the init scripts reside in different directories pertaining to their feature bitbake recipe. For example, the reset-handler init script resides in layers/meta-mlinux/recipes-core/multitech/reset-handler. You’ll need a recipe similar to the reset-handler_1.0.bb that declares an INITSCRIPT_NAME and the corresponding INITSCRIPT_PARAMS that specify the update-rc.d options so that the script gets installed in the correct run level(s), etc.

Jeff

[Patrick B.]

Jeff,

thank you for your feedback, it’s highly appreciated.

One last question, is there are way to figure out whether a boot is the very first boot after having flashed the rootfs? I haven’t found a generic way how this is done when searching for Yocto and this on Google.

Hmm, I could simply create a file in the rootfs once my script has run and check whether the file exists or not in the beginning of the script.

—
Patrick.

[Jeff Hatch]

Patrick,

On the AEP Conduit there is support for running ‘post-upgrade’ scripts. The ‘post-upgrade’ script checks for a file that was created in /var/config called upgrade_occurred. If the file exists, the post-upgrade script runs whatever scripts are in /opt/upgrade. After running the scripts it deletes the upgrade_occurred file in /var/config, and won’t run again unless upgrade_occurred gets created again.

You can do the same type of thing with an init script and ipk files.

Jeff

[Patrick B.]

Hi Jeff,

thanks again for your help. We chose to add a script (in the flavor the reset-handler) which is run at each boot. It checks whether a file exists on the rootfs-partition. If the file does not exists it assumes the very first boot after an rootfs-upgrade and creates the file and does what it has to do in regards to the ipk-files. IPK files are stored in /var/config.

Doing it like this we can add features and fix bugs in this scripts and they take effect with the very next upgrade of the rootfs-image.

Thanks again for your help.

—
Patrick.

[Author]

Posts