2.0 Autoupdate Problem?

[DimitriRodis]

I found some posts in the past about similar issues, but didn't know if this had been fixed, or if it's a regression, etc, since the other posts that I found were from last year.

Currently running the following embedded build:
2.0-ALPHA-ALPHA
built on Fri Apr 17 14:09:47 EDT 2009
FreeBSD 7.1-RELEASE-p4

There is an update available, according to the auto update tabe in system_firmware_check.php:
–---
A new version is now available

New version:    Mon Apr 20 07:05:24 EDT 2009
Current version: 2.0-ALPHA-ALPHA
Update source:  http://snapshots.pfsense.org/FreeBSD7/HEAD/_updaters

When I invoke the upgrade, the file downloads, and then I get:

The image file is corrupt.

Update cannot continue

[sullrich]

That happens from time to time if the upload is stalled.  Just wait for the next one.

[DimitriRodis]

Tried it 3 times.. It got to 100% downloaded each time, and then it supposedly started to update, and then it got that message immediately after.

[iced98lx]

@DimitriRodis:

Tried it 3 times.. It got to 100% downloaded each time, and then it supposedly started to update, and then it got that message immediately after.

I got that when I tried to update using the "latest.tgz" file, which may be where this is pointed.. it's just a flaw in the update, once the new build builds (2 hours) and uploads it should be good again..

[dotdash]

@DimitriRodis:

Currently running the following embedded build:
2.0-ALPHA-ALPHA
built on Fri Apr 17 14:09:47 EDT 2009
FreeBSD 7.1-RELEASE-p4

AFAIK, embedded upgrades are currently not working. Generally, the image will download to /tmp. On embedded /tmp is a small memory disk which does not have enough space.

[bill_mcgonigle]

@dotdash:

AFAIK, embedded upgrades are currently not working. Generally, the image will download to /tmp. On embedded /tmp is a small memory disk which does not have enough space.

Yeah, mine has 35MB and the update is 50MB:

$ df -h
Filesystem             Size    Used   Avail Capacity  Mounted on
/dev/ufs/pfSense       107M     74M     25M    75%    /
devfs                  1.0K    1.0K      0B   100%    /dev
/dev/md0                38M    228K     35M     1%    /tmp
/dev/md1                19M    5.2M     12M    30%    /var
/dev/ufs/pfSenseCfg    4.5M     86K    4.1M     2%    /cf

What's the intent?  I'm having trouble finding flash devices that are small enough for pfSense (only half kidding) - should pfSense have the option of grabbing additional space on the storage device for temporary storage?  I've got the embedded image on a 1GB stick.

[jimp]

@bill_mcgonigle:

What's the intent?  I'm having trouble finding flash devices that are small enough for pfSense (only half kidding) - should pfSense have the option of grabbing additional space on the storage device for temporary storage?  I've got the embedded image on a 1GB stick.

There are methods of resizing the flash image to use all of the available space on your given media, and there are also some presized images available from a third-party, but the usual warnings/trust issues apply in that case. (Though I have heard of no issues)

[dotdash]

As noted in another thread, just resizing the image does not fix the embedded updates.
Changing the platform, rebooting, updating, changing back has worked for me. (On a resized image) YMMV.
Updating may work on the Hacom images, as they are based on a full install. I have not tried myself.

[bill_mcgonigle]

Thanks for the links.  Is there a way to create a new partition on a live system and mount it over /tmp?

It's been a very long time since I've dealt with BSD disk labels and neither fdisk or disklabel seem to have an easy interface to add a partition.  Pointers appreciated.

[bill_mcgonigle]

I did the resize to a 128MB image, but that doesn't seem to be the right approach:

$ df -h
Filesystem             Size    Used   Avail Capacity  Mounted on
/dev/ufs/pfSense       112M     73M     30M    71%    /
devfs                  1.0K    1.0K      0B   100%    /dev
/dev/md0                38M    162K     35M     0%    /tmp
/dev/md1                19M    4.1M     14M    23%    /var
/dev/ufs/pfSenseCfg    1.7M    179K    1.4M    11%    /cf

For some reason 73MB shows 'used' after resizing, so that's a stumbling block (I could resize it larger), but the update process didn't even attempt to use a non-RAM-disk storage, so I don't suppose resizing larger would make any difference.

I put some notes/scripting on how to do a resize using VirtualBox here:

http://bfccomputing.com/downloads/pfsense/get-resize-image.sh

if anybody else is trying this without a BSD host.

Does anybody know what the planned strategy is for updating embedded on 2.0?  Given parts prices, I'd think having a larger default embedded image size with a tmp filesystem on flash would work for most people.  Even in CF, there doesn't seem to be much price difference between 64MB and 1GB parts, at least from some quick Googling.