Is nanobsd web-based upgrade supposed to be working now?
-
If you attempted to upgrade using "latest.tgz", this likely wiped out your partition table on slice2. I can't be certain subsequent attempts to upgrade will be successful.
For a 2GB card, you'll want this file:
You can always find the latest upgrades at http://snapshots.pfsense.org
After you have the file downloaded, use the "Manual Update" tab, "Enable Firmware Upload", browse for the file you downloaded above and click the "Update firmware" button.
But like I said, you may have wiped out your slice2 in which case, you may not be able to upgrade at all. :(
-
It's a beautiful thing. I was able to capture the entire upgrade process. The log is attached. For those of you (like me) who didn't really understand what was going on under the covers, this should reveal much.
Now if only auto-update worked this well! ;D
-
I have tried this exactly as described in the posts above and it seems this is not working for me somehow. I'm running an ALIX board with 3 NICS and an internal wireless card. This is what I did:
- Completely erase the CF Card
- Write "pfSense-1.2.3-4g-20090819-0545-nanobsd.img" to the card
- Logon to the webinterface and upload my latest backup
- The firewall reboots (clean build, only config restored)
- Logon to the webinterface and navigate to the manual update page
- Upload the following file: "http://snapshots.pfsense.org/FreeBSD_RELENG_7_2/pfSense_RELENG_1_2/updates/pfSense-1.2.3-4g-20090821-0842-nanobsd-upgrade.img.gz"
Now, the firmware in progress animation is displayed until you manually reboot the device. I can leave it running for 24 hours and still nothing happen. Upgrade log only shows:
pfsense:/conf# tail upgrade_log.txt NanoBSD Firmware upgrade in progress... pfsense:/conf#Only thing I noticed is that the new Nano-BSD upgrade files are *.gz and it looks like all the systems expect a *.tgz, in the upgrade_log.txt Gloomrider posted it also shows a "/root/firmware.tgz" file? ??? I'm confused now, am I supposed to upload a *.gz or *.tgz??
-
".tgz" is a gzipped tar file. This makes sense for "upgrade.tgz" as it's basically a tar image of the root file system. "firmware.tgz" is another matter as this is actually a disk image that is sized for the specific CF card. These naming conventions are a bit of a nit. "firmware.tgz" should actually be "firmware.gz", but it doesn't break anything the way it is.
The log that I posted I got from the serial console. Before I did anything, I attached to the serial console, typed "8" for a shell prompt, then typed "tail -f /cf/conf/upgrade_log.txt". If you have never upgraded this file will not exist. Perhaps you could do something like "touch /cf/conf/upgrade_log.txt" before you begin. Now download the upgrade image then upload it to pfSense through the manual web method. As soon as the upload is complete, you should start seeing stuff written to the log.
It's crucial to begin "tailing" the log before you begin the upgrade.
Hope This Helps
-
Hi Gloomrider,
Thanks for your reply, that clears up about gz vs tgz.
Unfortunately that does not change the situation, when I write pfSense-1.2.3-4g-20090819-0545-nanobsd.img snapshot to my 4GB compact flashcard all is running fine. Next, I use the console update or the manual firmware upload on the webinterface to load "pfSense-1.2.3-4g-20090821-0842-nanobsd-upgrade.img.gz".
At this point nothing happens, I can leave it running for 24 hours but the firmware does not update. The update log file only shows the lines I posted.
-
What output does this command give?:
ls /dev/ad0* -
What output does this command give?:
ls /dev/ad0*pfsense:~# ls -l /dev/ad0*
crw-r–--- 1 root operator 0, 66 Aug 23 20:09 /dev/ad0
crw-r----- 1 root operator 0, 67 Aug 23 20:09 /dev/ad0s1
crw-r----- 1 root operator 0, 70 Aug 23 20:09 /dev/ad0s1a
crw-r----- 1 root operator 0, 71 Aug 23 20:09 /dev/ad0s1c
crw-r----- 1 root operator 0, 68 Aug 23 20:09 /dev/ad0s2
crw-r----- 1 root operator 0, 72 Aug 23 20:09 /dev/ad0s2a
crw-r----- 1 root operator 0, 73 Aug 23 20:09 /dev/ad0s2c
crw-r----- 1 root operator 0, 69 Aug 23 20:09 /dev/ad0s3After the upgrade some are missing.. Could it have something to do with my config, or perhaps something with this specific snapshot? Should this work regardless of the XML config?
-
This all looks fine. Are you able to attach a serial cable? Are you certain you're "tailing" the log before you start uploading the upgrade file through the web GUI?
-
This all looks fine. Are you able to attach a serial cable? Are you certain you're "tailing" the log before you start uploading the upgrade file through the web GUI?
I've flashed the latest image onto the card now and it is working. When the next snapshot is released I will connect the console cable and post what happens on the console. Would I need to start "tail" on the console or will just the console output do?
Ow, just for fun I tried an upgrade to "pfSense-2.0-ALPHA-ALPHA-4g-20090821-0521-nanobsd-upgrade.img" and that worked fine. As this is still alpha I'm now back on 1.2.3-RC2.
-
Yes, if you use the serial console to watch the upgrade, you would want to "tail -f /cf/conf/upgrade_log.txt" before you upload the upgrade file through the GUI. The nice thing about doing this through the serial console is you also get to watch which slice it boots from.
-
It could have been something with the previous snapshot. This update succeeded ;D ;D ;D
NanoBSD Firmware upgrade in progress... Installing /root/firmware.tgz. Installing /root/firmware.tgz. SLICE 2 OLDSLICE 1 TOFLASH ad0s2 COMPLETE_PATH ad0s2a GLABEL_SLICE pfsense1 Wed Aug 26 14:20:37 CEST 2009 total 8 dr-xr-xr-x 7 root wheel 512 Aug 26 12:18 . drwxr-xr-x 23 root wheel 1024 Aug 26 12:18 .. crw-r----- 1 root operator 0, 66 Aug 26 12:18 ad0 crw-r----- 1 root operator 0, 67 Aug 26 12:18 ad0s1 crw-r----- 1 root operator 0, 70 Aug 26 12:18 ad0s1a crw-r----- 1 root operator 0, 71 Aug 26 12:18 ad0s1c crw-r----- 1 root operator 0, 68 Aug 26 12:18 ad0s2 crw-r----- 1 root operator 0, 72 Aug 26 12:18 ad0s2a crw-r----- 1 root operator 0, 73 Aug 26 12:18 ad0s2c crw-r----- 1 root operator 0, 69 Aug 26 12:18 ad0s3 crw------- 1 root operator 0, 25 Aug 26 12:18 ata crw------- 1 root wheel 0, 74 Aug 26 12:19 bpf0 crw------- 1 root wheel 0, 76 Aug 26 12:18 bpf1 crw------- 1 root wheel 0, 86 Aug 26 12:18 bpf2 crw------- 1 root wheel 0, 94 Aug 26 14:17 bpf3 crw------- 1 root wheel 0, 95 Aug 26 12:18 bpf4 crw------- 1 root wheel 0, 96 Aug 26 12:18 bpf5 crw------- 1 root tty 0, 10 Aug 26 14:20 console crw-rw-rw- 1 root wheel 0, 53 Aug 26 12:18 crypto crw-rw-rw- 1 root wheel 0, 11 Aug 26 12:18 ctty crw-rw---- 1 uucp dialer 0, 43 Aug 26 12:18 cuad0 crw-rw---- 1 uucp dialer 0, 44 Aug 26 12:18 cuad0.init crw-rw---- 1 uucp dialer 0, 45 Aug 26 12:18 cuad0.lock crw-rw---- 1 uucp dialer 0, 49 Aug 26 12:18 cuad1 crw-rw---- 1 uucp dialer 0, 50 Aug 26 12:18 cuad1.init crw-rw---- 1 uucp dialer 0, 51 Aug 26 12:18 cuad1.lock crw------- 1 root wheel 0, 5 Aug 26 12:18 devctl cr-------- 1 root wheel 0, 65 Aug 26 12:18 devstat dr-xr-xr-x 2 root wheel 512 Aug 26 12:18 fd crw------- 1 root wheel 0, 12 Aug 26 12:18 fido crw-r----- 1 root operator 0, 4 Aug 26 12:18 geom.ctl crw------- 1 root wheel 0, 22 Aug 26 12:18 io crw------- 1 root wheel 0, 7 Aug 26 12:18 klog crw-r----- 1 root kmem 0, 21 Aug 26 12:18 kmem dr-xr-xr-x 2 root wheel 512 Aug 26 12:18 led crw-r----- 1 root operator 0, 84 Aug 26 12:18 md0 crw-r----- 1 root operator 0, 85 Aug 26 12:18 md1 crw------- 1 root wheel 0, 63 Aug 26 12:18 mdctl crw-r----- 1 root kmem 0, 20 Aug 26 12:18 mem dr-xr-xr-x 2 root wheel 512 Aug 26 12:18 net lrwxr-xr-x 1 root wheel 7 Aug 26 12:18 net1 -> net/vr0 lrwxr-xr-x 1 root wheel 7 Aug 26 12:18 net2 -> net/vr1 lrwxr-xr-x 1 root wheel 7 Aug 26 12:18 net3 -> net/vr2 lrwxr-xr-x 1 root wheel 8 Aug 26 12:18 net4 -> net/ath0 lrwxr-xr-x 1 root wheel 10 Aug 26 12:18 net5 -> net/pflog0 lrwxr-xr-x 1 root wheel 11 Aug 26 12:18 net6 -> net/pfsync0 lrwxr-xr-x 1 root wheel 8 Aug 26 12:18 net7 -> net/enc0 lrwxr-xr-x 1 root wheel 7 Aug 26 12:18 net8 -> net/lo0 lrwxr-xr-x 1 root wheel 8 Aug 26 12:19 net9 -> net/tun0 crw------- 1 root wheel 0, 3 Aug 26 12:18 network crw------- 1 root wheel 0, 52 Aug 26 12:18 nfs4 crw------- 1 root kmem 0, 13 Aug 26 12:18 nfslock crw-rw-rw- 1 root wheel 0, 23 Aug 26 14:20 null crw-r--r-- 1 root wheel 0, 6 Aug 26 12:18 pci crw-rw---- 1 proxy proxy 0, 54 Aug 26 12:18 pf crw-rw-rw- 1 root wheel 0, 97 Aug 26 14:20 ptyp0 crw-rw-rw- 1 root wheel 0, 8 Aug 26 12:18 random lrwxr-xr-x 1 root wheel 4 Aug 26 12:18 stderr -> fd/2 lrwxr-xr-x 1 root wheel 4 Aug 26 12:18 stdin -> fd/0 lrwxr-xr-x 1 root wheel 4 Aug 26 12:18 stdout -> fd/1 crw------- 1 root wheel 0, 40 Aug 26 12:18 ttyd0 crw------- 1 root wheel 0, 41 Aug 26 12:18 ttyd0.init crw------- 1 root wheel 0, 42 Aug 26 12:18 ttyd0.lock crw------- 1 root wheel 0, 46 Aug 26 12:18 ttyd1 crw------- 1 root wheel 0, 47 Aug 26 12:18 ttyd1.init crw------- 1 root wheel 0, 48 Aug 26 12:18 ttyd1.lock crw--w---- 1 root tty 0, 98 Aug 26 14:20 ttyp0 crw------- 1 uucp dialer 0, 87 Aug 26 14:20 tun0 dr-xr-xr-x 2 root wheel 512 Aug 26 12:18 ufs dr-xr-xr-x 2 root wheel 512 Aug 26 12:18 ufsid lrwxr-xr-x 1 root wheel 6 Aug 26 12:18 urandom -> random crw-rw---- 1 root operator 0, 38 Aug 26 12:18 usb crw-rw---- 1 root operator 0, 37 Aug 26 12:18 usb0 crw-rw---- 1 root operator 0, 39 Aug 26 12:18 usb1 crw------- 1 root operator 0, 64 Aug 26 12:18 xpt0 crw-rw-rw- 1 root wheel 0, 24 Aug 26 12:18 zero -rw------- 1 root wheel 40M Aug 26 14:19 /root/firmware.tgz MD5 (/root/firmware.tgz) = 8b457e76d20107d7627bc685a9d193c7 /dev/ufs/pfsense0 on / (ufs, local) devfs on /dev (devfs, local) /dev/md0 on /var/tmp (ufs, local) /dev/md1 on /var (ufs, local) /dev/ufs/cf on /cf (ufs, local) devfs on /var/dhcpd/dev (devfs, local) last pid: 24015; load averages: 1.65, 0.58, 0.22 up 0+02:02:24 14:20:40 39 processes: 2 running, 37 sleeping Mem: 47M Active, 65M Inact, 28M Wired, 40K Cache, 34M Buf, 99M Free Swap: PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 890 root 1 4 0 46120K 20636K accept 0:52 0.00% php 507 root 1 44 0 5944K 3908K select 0:48 0.00% openvpn 873 root 1 4 0 7180K 4780K kqread 0:30 0.00% lighttpd 888 root 1 4 0 44072K 17804K accept 0:05 0.00% php 1767 root 1 -8 20 3492K 1388K piperd 0:03 0.00% sh 882 root 1 4 0 44072K 17528K accept 0:03 0.00% php 1554 root 1 8 20 3156K 800K nanslp 0:01 0.00% check_reload_status 21671 root 1 44 0 7780K 3280K select 0:01 0.00% sshd 420 root 1 44 0 3312K 1492K select 0:00 0.00% hostapd 944 nobody 1 44 0 3156K 1316K select 0:00 0.00% dnsmasq 21839 root 1 20 0 3508K 2288K pause 0:00 0.00% tcsh 483 root 1 -58 0 5716K 2252K bpf 0:00 0.00% tcpdump 247 root 1 44 0 3268K 1124K select 0:00 0.00% syslogd 11251 _ntp 1 44 0 3156K 1228K select 0:00 0.00% ntpd 874 root 1 8 0 39976K 5264K wait 0:00 0.00% php 881 root 1 8 0 39976K 5264K wait 0:00 0.00% php 886 root 1 8 0 39976K 5264K wait 0:00 0.00% php 484 root 1 -8 0 3156K 764K piperd 0:00 0.00% logger NanoBSD upgrade starting dd if=/dev/zero of=/dev/ad0s2 bs=1m count=1 1+0 records in 1+0 records out 1048576 bytes transferred in 0.204520 secs (5127010 bytes/sec) /usr/bin/gzip -dc /root/firmware.tgz | /bin/dd of=/dev/ad0s2 obs=64k 3949906+635 records in 30861+1 records out 2022547968 bytes transferred in 391.879336 secs (5161150 bytes/sec) After upgrade fdisk/bsdlabel /sbin/fsck_ufs -y /dev/ad0s2a ** /dev/ad0s2a ** Last Mounted on /tmp/builder/_.mnt ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 3436 files, 161085 used, 3723055 free (4447 frags, 464826 blocks, 0.1% fragmentation) /sbin/tunefs -L pfsense1 /dev/ad0s2a /dev/ufs/pfsense1 / ufs ro 1 1 /dev/ufs/cf /cf ufs ro 1 1 gpart set -a active -i 2 ad0 ad0s2 has active set /usr/sbin/boot0cfg -s 2 -v /dev/ad0 # flag start chs type end chs offset size 1 0x00 0: 1: 1 0xa5 846: 15:63 63 3950289 2 0x80 847: 1: 1 0xa5 669: 15:63 3950415 3950289 3 0x00 670: 0: 1 0xa5 771: 15:63 7900704 102816 version=1.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) options=packet,update,nosetdrv default_selection=F2 (Slice 2) Wed Aug 26 14:27:33 CEST 2009 *** FINAL System shutdown message from root@pfsense.local *** System going down IMMEDIATELY -
Cool! ;D
This is the 4G update I see. Did you happen to notice it took 6.5 minutes to flash one slice? :o
-
Cool! ;D
This is the 4G update I see. Did you happen to notice it took 6.5 minutes to flash one slice? :o
Yes, 6.5 minutes of worrying that I might need to open the case again :D The CF controllers on ALIX boards don't seem to be very fast :-) So what do I do now? Do I need to copy Slice2 to Slice1 or just leave it like this? What happens if I invoke the next upgrade? Does it then upgrade Slice1 and the set that one active and reboot?
–---------------------
EDIT:
I see we cheered a bit too soon:
pfsense:~# fdisk ******* Working on device /dev/ufs/pfsense1 ******* parameters extracted from in-core disklabel are: cylinders=3918 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=3918 heads=16 sectors/track=63 (1008 blks/cyl) fdisk: invalid fdisk partition table found Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 3949281 (1928 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 845/ head 15/ sector 63 The data for partition 2 is: <unused>The data for partition 3 is: <unused>The data for partition 4 is: <unused>pfsense:~# ls -l /dev/ad0* crw-r----- 1 root operator 0, 66 Aug 26 14:28 /dev/ad0 crw-r----- 1 root operator 0, 67 Aug 26 22:15 /dev/ad0s1 crw-r----- 1 root operator 0, 68 Aug 26 14:28 /dev/ad0s2 crw-r----- 1 root operator 0, 72 Aug 26 14:28 /dev/ad0s2a crw-r----- 1 root operator 0, 73 Aug 26 14:28 /dev/ad0s2c crw-r----- 1 root operator 0, 69 Aug 26 14:28 /dev/ad0s3</unused></unused></unused>So now fdisk shows that there is no second partition and I'm missing some stuff under /dev/ad*
darnit.. Everything still works though..
UPDATE2:
After duplicating Slice2 to Slice1 the ls -l /dev/ad0* seems okay again. Fdisk is still reporting only 1 partition and an invalid parition table?? ??? ??? ??? ???
pfsense:~# fdisk ******* Working on device /dev/ufs/pfsense1 ******* parameters extracted from in-core disklabel are: cylinders=3918 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=3918 heads=16 sectors/track=63 (1008 blks/cyl) fdisk: invalid fdisk partition table found Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 3949281 (1928 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 845/ head 15/ sector 63 The data for partition 2 is: <unused>The data for partition 3 is: <unused>The data for partition 4 is: <unused>pfsense:~# ls -l /dev/ad* crw-r----- 1 root operator 0, 66 Aug 26 14:28 /dev/ad0 crw-r----- 1 root operator 0, 67 Aug 26 22:30 /dev/ad0s1 crw-r----- 1 root operator 0, 101 Aug 26 14:28 /dev/ad0s1a crw-r----- 1 root operator 0, 102 Aug 26 14:28 /dev/ad0s1c crw-r----- 1 root operator 0, 68 Aug 26 14:28 /dev/ad0s2 crw-r----- 1 root operator 0, 72 Aug 26 14:28 /dev/ad0s2a crw-r----- 1 root operator 0, 73 Aug 26 14:28 /dev/ad0s2c crw-r----- 1 root operator 0, 69 Aug 26 14:28 /dev/ad0s3</unused></unused></unused> -
Interesting. The log output shows the update seemed to work as expected. Just curious, did the update not work, or are you just concerned with what fdisk is saying?
-
The update worked fine, I'm running the 26th snapshot now. No issues whatsoever.
But the experience with this Fdisk output tells me the next upgrade will fail ::)
Could someone please briefly explain the differences between slices, partitions and the /dev/ad0* files and how they relate to each other? ???
-
The update worked fine, I'm running the 26th snapshot now. No issues whatsoever.
But the experience with this Fdisk output tells me the next upgrade will fail ::)
Could someone please briefly explain the differences between slices, partitions and the /dev/ad0* files and how they relate to each other? ???
There was a new 4G snapshot posted yesterday. Have you tried it?
Edit: Oops, you're running that. FYI: /dev/ufs/pfsense0 = slice 1 and /dev/ufs/pfsense1 = slice 2. You should try running fsck on the slice you're NOT running on.
/sbin/fsck_ufs -y /dev/ad0s1a -
Got this now:
pfsense:~# /sbin/fsck_ufs -y /dev/ad0s1a ** /dev/ad0s1a (NO WRITE) ** Last Mounted on / ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 7966 files, 276870 used, 3607270 free (4254 frags, 450377 blocks, 0.1% fragmentation) pfsense:~# fdisk ******* Working on device /dev/ufs/pfsense1 ******* parameters extracted from in-core disklabel are: cylinders=3918 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=3918 heads=16 sectors/track=63 (1008 blks/cyl) fdisk: invalid fdisk partition table found Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 3949281 (1928 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 845/ head 15/ sector 63 The data for partition 2 is: <unused>The data for partition 3 is: <unused>The data for partition 4 is: <unused>pfsense:~#</unused></unused></unused> -
I see it now. fdisk is auto-selecting the mounted root file system which has no partition table. If you want to see the partition table:
EDIT:
fdisk /dev/ad0Be careful and don't write anything unless you know what you're doing.
I think you'll be fine for the next snap :)
EDIT:
Here's mine:
router:~# fdisk /dev/ad0 ******* Working on device /dev/ad0 ******* parameters extracted from in-core disklabel are: cylinders=3970 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=3970 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 1949409 (951 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 909/ head 15/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 1949535, size 1949409 (951 Meg), flag 0 beg: cyl 910/ head 1/ sector 1; end: cyl 795/ head 15/ sector 63 The data for partition 3 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 3898944, size 102816 (50 Meg), flag 0 beg: cyl 796/ head 0/ sector 1; end: cyl 897/ head 15/ sector 63 The data for partition 4 is: -
Every time I attempt to upgrade (2gig nano file) I get a message after a bit I get a failure due to the upgrade image being larger than the partition. I remember reading earlier someone have the same issue but could not find it after searching the term. I started the tail but all I got was:
pfsense:~# tail -f /cf/conf/upgrade_log.txtWARNING: Expected rawoffset 0, found
63NanoBSD Firmware upgrade in progress…
Installing /root/firmware.tgz.
Installing /root/firmware.tgz.
SLICE 1
OLDSLICE 2
TOFLASH ad0s1
COMPLETE_PATH ad0s1a
GLABEL_SLICE pfsense0
NanoBSD Firmware upgrade in progress...Broadcast Message from root@pfsense.local
(no tty) at 12:40 EDT...NanoBSD Firmware upgrade in progress...
Installing /root/firmware.tgz.
Installing /root/firmware.tgz.
SLICE 1
OLDSLICE 2
TOFLASH ad0s1
COMPLETE_PATH ad0s1a
GLABEL_SLICE pfsense0Broadcast Message from root@pfsense.local
(no tty) at 12:40 EDT...thanks,
Jim -
As you can see in this thread, my first successful upgrade attempt was August 9th. Prior to that, I was just reflashing every time a new snap appeared on the server. Perhaps at some point the size of the disk images changed and I never noticed it because I was reflashing the whole CF card. This is all speculation of course, but it might be useful to reflash (this is where multiple CF cards come in handy) and wait for the next snap, attempt an update and see what happens. I haven't had any issues since 8/9 and I have updated with every new update on the snapshot server.