Update Linux system from running system

We would like to do a linux update from a running system.

My thoughts about implementing this process:

  1. Download tar.bz2 from Server / Load via USB
  2. Extract and write to sd card (update.sh -o /mountpoint)
  3. Save database to sdcard
  4. Instruct u-boot to flash the eMMC with the image from the sdcard and reset the env vars
  5. Reboot
  6. Flashing
  7. Booting

My only problem is, I’m sure how to do step nr. 4.

As far as I know there is the tool fw_setenv to set env vars from a running system. And there is the env var bootcmd, which is executed at startup, right? What value is needed for bootcmd to initiate the update?

is it just run setupdate && run update && env default -a && saveenv && boot?

Unfortunately, if using our regular legacy update scripts there will be a reset at the end of the update. So the issue will be that after the run update step it will always reset before doing the env default -a && saveenv. Your proposed solution as given above will therefor update-loop (;-p). However, once you remove the reset from that script your proposed solution should work quite nicely.

You are talking about “legacy update scripts”. What would be the non-legacy version to update the linux system?

And is there a way to modifiy the flash_blk.scr from our layer, like as a patch? Because I don’t want to have any changes in the toradex layers directly

You are talking about “legacy update scripts”. What would be the non-legacy version to update the Linux system?

That would be the Toradex Easy Installer. However, currently, that is only meant for initial deployment and not really for any later update.

And is there a way to modify the flash_blk.scr from our layer, like as a patch? Because I don’t want to have any changes in the Toradex layers directly.

Yes, you would go about it by bbappending resp. image recipe and deploying your own version before ./mk-u-boot-scripts.sh is called.

I did some testing, but this isn’t as easy as I thought.

The update.sh has many dependencies, which I added now.

The main problem is, that the update.sh needs to be heavily adapted to work on the colibri-imx6 because of the limited functionality/different args of some commands (for example: du and readline). I am really not sure, if that will work.

Why exactly do you want update.sh to be executed on the target? Wouldn’t it be much easier to directly deploy resp. already generate update media content (e.g. just tar/zip it up and ftp/scp or whatever it to the target)?

Because the sd card is already build into our device, inside the chasing, not accessible without opening the device. Also most of our customers (about 99%) don’t have a linux machine, so they cannot prepare a sd card for the update process.

So I have to do that on the colibri-imx6 directly.

What exactly do you mean with “already generate update media content”?

What exactly do you mean with “already generate update media content”?

I would basically suggest a step 0 “Generate update media content” where you basically first run ./update.sh on a regular Linux machine and subsequently tar/zip it up prior to making it available for your step 1 “Download tar.bz2 from Server / Load via USB” which now rather than using our regular tarball would be a pre-generated one which may be copied/extracted to your built-in SD card and immediately consumed by run setupdate; run update without any further on-target processing required.

Ah yeah. Actually, I already thought about that. My idea was to prepare a sd card by running the update script, copy the complete sd card with dd, transfer it to the device and write it to the sd card in the device with dd. But there is a new problem: the sd card has a size of 4GB so the update file would also have 4GB, which would be kind of impracticable. Also the eMMC has only 4GB, so we wouldn’t have enough space to do this operation.

Maybe dd in combination with gunzip over pipes might work, but I didn’t had the time to check that.

Why using dd? Just tar/zip it up and it will be fractions of the size.

Omg now I get it, I was on a completely wrong path.

I thought the update.sh prepares the partition layout of the sd card too. So I thought, I would need to copy it with dd.

Thanks for the support. Problems should be solved.

You are very welcome. Just let us know should you have any further questions or comments.

Unfortunately, if using our regular
legacy update scripts there will be a
reset at the end of the update. So
the issue will be that after the run
update step it will always reset
before doing the env default -a &&
saveenv. Your proposed solution as
given above will therefor update-loop
(;-p). However, once you remove the
reset from that script your proposed
solution should work quite nicely.

I did similar upgrade script in the past and you can ommit reset by adding additional variable. for example:
setenv force_upgrade=1
and
if force_upgrade = 1 then; setenv force_upgrade=0; saveenv; run upgrade_cmd

and, by the way my upgrade was based only on a few boot commands added with fw_setenv

Well done!