Embedded Linux – Dev tip – Use Multiple images

Embedded Linux – Dev tip -Use Multiple images – Preamble

First off, using multiple Linux images while developing a system, or systems is already a good idea. Sometimes, you might not know when, something catastrophic may happen – And if you only have one image to work with . . . well, you have to start over again. How you start over again can be mitigated. Not only that, but perhaps you have a need, or want to compile natively. When using an i386 / x64 system( PC ), this is not usually a problem. With embedded Linux systems however, sometimes this can be a problem. For multiple reasons, but an important reason for me – Would be storage space. When developing software for a platform, and doing the compiling natively. You’re going to need to pull in, and install many packages. Most, or perhaps all of these packages will not need be installed on the final image, in order for the application in question to function. With this in mind, it may be prudent to keep at least two images. One production image, and one development image. Perhaps even more, when or if the occasion arises.

To be sure, there are other things to consider when developing an embedded Linux system. But for this one article I would like to just focus on the subject at hand. So let us just assume for arguments sake that we’re limited to 1 or more sdcards, and that we do have access to an x86 / x86-64 Linux system. One that perhaps can not be used as a cross compile system. Or perhaps, we’re unable to cross compile – For one reason or another.

Starting off fresh

Ok, so now that we’ve put ourselves into this “impossible situation”, how do we get out of it ? We first start off by creating an sdcard image with all the bare minimum tools / utilities we need, or want installed to it. These tools / utilities would be required, needed, or just wanted on the final image. Packages like ntpdate, fake-hwclock, cpufrequtils, whatever. Small, useful tools / utilities, that are not, or not necessarily related to the development of our application(s). But may be required in the final production image. Once this image is completed, we then remove the sdcard media from the embedded hardware, and place it into our desktop “development machine”, and create a rootfs backup using tar. Using tar to create a backup has the advantage of only archiving the needed file / directory structure. Instead of creating a byte for byte copy of an entire block device, or partition( dd ). Which could be considerably larger, in comparison to actual disk space used.

Identify sdcard

Here, I just happen to know that /dev/sdb/ is my sdcard. This is also a dual partition layout for a Beaglebone black image. An image which I built probably . . . about a year ago. Based on a 3.8.13-bone47 kernel. Anyway, sdb1 is a FAT partition containing MLO, uboot.img, and uEnv.txt. sdb2 is where the rootfs exists. Next, we need to mount /dev/sdb2/ in order to create a backup.

mount the root file system
change working directory to mount point, and check contents
Create backup using tar

It is important to note that the period ( “.” ) at the end of this last command is required. Also, we *must* cd into this mount point, before starting the backup. If you chose to mount the sdcard in a different directory ( mount point ), that is fine. Just make sure you cd into it before executing the backup. At this point, congratulations are in order. As you’ve just completed a backup of your rootfs. It was not that hard was it ?

Once you’ve completed the backup above. You can put the sdcard back into your embedded Linux system( Beaglebone black for me ), and boot from it. Once booted, and running. Install all development packages needed, and then you may wish to make an image of this too. Basically, giving you two images. Backing up the development image may at first seem like an unnecessarily step. But if you plan on doing any future development, for a different project. It sure would be handy to have a development image ready to use. Would it not ?

After your project application is finished. Simply move or copy all the required files to your desktop development system, in preparation to copy over to the production image you made previously. To move the files to the desktop dev. system, you have several options. Basically though, it’s one of two ways. Remotely, or physically. Again, there is more than one option, for each way. Remotely, you could use sshfs, or another remote utility. Physically, you would place the sdcard back int the desktop dev machine, and use cp, mv, or even tar for complex file / directory structures. There is also at least one more option that I can think of off the top of my head. Building a *deb file package, which then could be installed via dpkg. This is useful if your application(s) are large, complex, and perhaps have dependencies that you may, or may not be aware of. I’ve always used the utility checkinstall, but I’ve been told that make can be made to do the same. I’ve only ever used checkinstall personally, so could not say from hands on experience.

Anyway, with all that information to consider, and assuming you’ve chosen, and executed a means to store your project files off somewhere safe. It’s time to restore the production image we made previously. This step is actually fairly easy, and I’ve roughly covered it in another post. A couple of these steps will look very familiar. With the sdcard inserted into the desktop dev system . . .

Identify sdcard
mount the root file system

After this step, there is no need to cd into the mount point directory.

Restore previously created rootfs

That, as “they” say – Is that(“Them?!”). Not too hard was it ? To be sure, this technique is actually useful for more than this one scenario. Using a variation, this same technique can be used on an nfs rootfs. How is this useful you may wonder ? Well largely it is the same. Except for the obvious of course. But using an nfs rootfs can be very handy for many reasons. First, no worries about constantly writing to flash media. Compiling, random file changes, etc. Second, you can keep multiple development images, production images, for every conceivable situation. Provided you have enough storage space to accommodate such a situation. last, but not least. Changes ( depending ) can be made on the fly, and live. This really depends on what / how you change. There is a good chance if you change any system required files live. That the system in question will lock up after a short bit. If you’re just changing files, directories, etc in the home directory. Chances are very good you’ll not have to worry about the system locking up. There is also much more to like about such a situation. I’ll leave it up to you, the reader. To explore. Before going however, I would like to mention one thing. If you did not “get” the reference to “them!?” I made above. Go forth, and watch “The Chronicles of Riddick”. You’ve probably earned it. . . Happy Beagling !

Embedded Linux – Dev tip – Use Multiple images