Dashboard reports wrong version

clarknova

Minutes ago I used console option 13 to updated from a local file, which I had scp'ed to /tmp (whose size I have increased to 400M). The update appeared to complete successfully and pfsense rebooted.

When I reloaded the Dashboard in my browser, it still showed my previous pfsense version:


2.0-RC3 (amd64)
built on Fri Aug 12 15:32:25 EDT 2011

Update available. Click Here to view update.
Platform 	nanobsd (2g)
NanoBSD Boot Slice 	pfsense1 / ad0s2

But other evidence seems to indicate that I'm on the latest version:


cat /tmp/pfSense_version 
Wed Aug 24 11:09:10 EDT 2011

What's the explanation here?

clarknova

Note: s/gif/gz/

upgrade_log.txt.gif

jimp

Check "uname -a"

That is the version of the installed kernel.

The files in /etc/ would be from when the pfSense code was made, or perhaps gitsynced, etc.

Was this a custom update file you made somehow? Or something else? If you upload the file using the GUI does it work?

If the other files are coming from the update, but not the kernel, there could be an issue there, or perhaps it just can't write out the kernel for some reason

clarknova


uname -a
FreeBSD pfsense.tfcg.co 8.1-RELEASE-p4 FreeBSD 8.1-RELEASE-p4 #0: Fri Aug 12 15:32:05 EDT 2011     root@FreeBSD_8.0_pfSense_2.0-AMD64.snaps.pfsense.org:/usr/obj./usr/pfSensesrc/src/sys/pfSense_wrap.8.amd64  amd64

So it appears the kernel did not update. I downloaded the update image from snapshots.pfsense.org, scp'ed it to pfsense, then used console option 13 to install from local file, because GUI updates have been painfully slow lately. The update appeared to complete and pfsense rebooted itself at the end.

jimp

Do you have any firmware options set to gitsync in the GUI?

Seems odd that it would work one way and not another, but unless you can reproduce the same issue on a stock install that hasn't been modified in some way it's hard to know where the problem lies.

clarknova

I haven't done anything with git on this one. The only modification outside the GUI is to increase the size of /tmp. I'll switch to the older slice, try another update and see what happens.

jimp

Well if it's NanoBSD that's even more perplexing because that would seem to indicate that the kernel inside of the image was older, since the entire slice is rewritten from the update file.

(I didn't see that you mentioned NanoBSD in the OP)