Alternative upgrade mechanism
-
Or subtitle: How much memory?
At the moment the three embedded systems of m0n0wall, FreeNAS, and pfSense all use dd to perform full upgrades on HDD/CF images. In pfSense I see the development of an binary patch update mechanism but unfortunately only allows updates and new files. I went for an alternative of allowing upload of compressed ISO images, decompressing into MFS, and then using rsync with a quite a few options to the local root file system. The ISO images I generate are significantly smaller as their is no configuration partition.
rsync \ --verbose \ --archive \ --hard-links \ --dry-run \ --one-file-system \ --delete-after \ --delay-updates \ --numeric-ids \ --checksum \ --omit-dir-times \ --ignore-times \ --exclude=etc/fstabWith suitable hosting it should be possible to use rsync+ssh as another alternative completely avoiding upload & decompressing the firmware image.
-
See the RC2e thread. I have scripts that do something similar now.
-
I'm actually having a lot of problems with the FreeBSD kernel panicing now, it worked fine on NFS root and there is plenty of memory available (256MB). I can mount the image, rsync, but after unmounting the kernel panics and reboots.
:(
-
Which version? 6.1-RELEASE?
-
RELENG_6 from CVS, I'm justing rebuilding with the latest now. I used to use RELENG_6_1 but it broke so I went back to 6, the release tag is RELENG_6_1_RELEASE?
-
Ahh okay, RELENG_6 should be stable. There was a major NFS bug in 6.1 release however.
-
Nice, but on NFS its ok, I'll try a few different tag versions today and see what works. Fixing this I can get another release out and work on the VLAN DHCP support.
-
Release is RELENG_6_1_0_RELEASE, trying that instead :D
-
After some Gentoo inspired mistakes, I think I have pin pointed this bug (?) down to unmounting a second mount of the root device. Is this a known strange problem? ???
-
Andrew fixed a few things in this area over the weekend.