I see that trunk has now gained some scripts for upgrading firmware whilst retaining configuration - this is definitely an important feature for Kamikaze.

In the case of x86 the platform-specific part is https://svn.openwrt.org/openwrt/trunk/t … latform.sh Unfortunately, this performs the upgrade by a rather brutal write to /dev/hda. In particular this means that if you have created a separate /dev/hda3 partition for data, this will be lost. Whilst Broadcom platforms with 4MB of flash and a single squashfs TRX image are probably going to have to work this way, on a Soekris with a 4GB flash card this is a bit of a problem. So I was wondering if there's a chance for a less destructive upgrade to be implemented for x86 before this becomes feature-frozen, and would like to throw around a few ideas for discussion.

The simplest way to keep the partition table might be to use the 'skip' and 'seek' options to dd to skip 512 bytes and leave the MBR alone. However this carries the risk that if the target image has different partition sizes to the partitioning on the old image, then the machine is toast.

Another option would be to split the image into two, and dd to /dev/hda1 (kernel) and /dev/hda2 (root) separately. This would always work, and the only requirement is that these partitions exist, and are as big as or bigger than the images being loaded.

Now, given that an x86 board allows 4 DOS partitions, it would be extremely valuable if there could be two or more images, and bootup could choose whichever is valid; then if an upgrade is stopped partway through, the device isn't bricked. Meraki do this with their bootstrap loader, and maybe this code could be reused: http://wiki.openwrt.org/OpenWrtDocs/Har … 3b15fed0df

However, this still leaves the issue of having to upgrade the kernel and the root fs separately. Meraki solve this by using a ramdisk root filesystem, and this is what I'm doing for now on a Soekris net4501: /dev/hda1 contains the kernel and the ramdisk, and an upgrade just requires mounting /dev/hda1, updating two files, and rebooting. This device has 64MB, so the extra RAM usage isn't a problem, but for systems with less RAM this isn't so appealing (e.g. Routerboard)

What would be really nice is to have a single image which contains both the kernel and a squashfs root filesystem, as a TRX does. Options include:

1. use TRX file format (or something like it) to combine the kernel and squashfs filesystem. Needs an x86 boot loader which understands it, plus some way to tell the kernel where to find the squashfs data. Sounds hard.

2. put the kernel inside the squashfs filesystem. We'd have to teach grub to read a squashfs filesystem (e.g. a new stage 1.5 loader); a lot of work I think.

3. store the kernel and squashfs filesystem as two separate files in /dev/hda1, then mount the squashfs using a loopback mount - this is the sort of complex initialisation that the initramfs was designed for. Then /dev/hda2 can become an ext2 or jffs2 mini_fo mount on top of that. I think this is probably the easiest to implement, most likely to work, and most portable.

In this case, an OpenWrt 'image' could then be an ext3 filesystem image which contains those files plus the grub loader, which is easy to upgrade (dd to /dev/hda1). However it still suffers from the risk of power being lost during the upgrade. So the only real advantage here is that a firmware upgrade is a single dd to /dev/hda1, rather than a dd to /dev/hda which zaps all other partitions on the flash.

3a. Alternatively, the 'upgrade' process can mount /dev/hda1 and just update those two files (the kernel and the squashfs loopback). In this case, if there's enough space you would copy them under temporary names, sync, and then 'mv' them into place; this would be a relatively risk-free procedure. You could also have any number of images available and switch between them, depending on how big you made /dev/hda1.

It would also be possible to use a VFAT filesystem instead of ext2 as the firmware partition (booting using syslinux), which would be friendlier to Windows users. With OpenWrt on a flash card or USB stick, upgrading it would be as simple as plugging it into your PC and copying two files over.

Does anyone have any thoughts on this? I know all I'm offering here is talk rather than code, but perhaps a better solution is planned already.

Cheers, Brian.