Is nanobsd web-based upgrade supposed to be working now?



  • 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

    upgrade.txt



  • 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:

    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*
    
    


  • @gloomrider:

    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/ad0s3

    After 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?



  • @gloomrider:

    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



  • @gloomrider:

    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?  ???



  • @pakjebakmeel:

    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/ad0
    
    

    Be 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
    63

    NanoBSD 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 pfsense0

    Broadcast 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.



  • 10-4 Gloomrider.  I have multiple CFs and reflash regularly when an update comes out and I am unable to update via the gui or the console.  I just have not had any luck with this yet.  I settled on the 2gig image since it looked middle of the road and that my cf card is 4gigs.  It formats just under that size so I was worried that the 4 gig image/dual partitions would not exactly fit.  I thought things were looking up when you and the other gentleman were successful in upgrading but no, I am still reflashing:(



  • When was the last time/snapshot you reflashed?  It would seem only manual update is working.  I think auto-update is still trying to use the old embedded (AKA broken) paradigm.

    Nanobsd images that I download from http://snapshots.pfsense.org/FreeBSD_RELENG_7_2/pfSense_RELENG_1_2/updates are updating fine for me.

    EDIT: I wonder if the fact you're using a different size card has anything to do with it?  Why don't you try a 4GB image on your 4GB card?



  • @jzsjr:

    10-4 Gloomrider.  I have multiple CFs and reflash regularly when an update comes out and I am unable to update via the gui or the console.  I just have not had any luck with this yet.  I settled on the 2gig image since it looked middle of the road and that my cf card is 4gigs.  It formats just under that size so I was worried that the 4 gig image/dual partitions would not exactly fit.  I thought things were looking up when you and the other gentleman were successful in upgrading but no, I am still reflashing:(

    Check out this thread: http://forum.pfsense.org/index.php/topic,18805.0.html

    This looks an awful lot like what you and others are reporting.  I have been using "dd" under both Linux and FreeBSD to flash my 2GB Sandisk cards and I've not had any of these problems.

    EDIT: It appears there are subtly different sizes of CF cards.  See this post: http://forum.pfsense.org/index.php/topic,18805.msg96698.html#msg96698



  • Hi,

    running embedded since longtime. Now I wanted to switch from embedded to nanobsd, because reflashing, resizing  and move rrd's from time to time sucks. First, what I learned: no more WRAP. No problem have ALIX'es too. Also read about bigger Memory nedded. No problem, have plenty of 1GB CF.

    But I spent hours to test the Update mechanism. Not one success. Fails anytime. Manual, Auto, Console. I thought I have FreeBSD experience since Years. But no Idea what is going on here.

    at the moment I test from pfSense-1.2.3-1g-20090824-1854-nanobsd

    Option 13
    Enter the URL to the .tgz update file:

    tgz?

    It is http://snapshots.pfsense.org/FreeBSD_RELENG_7_2/pfSense_RELENG_1_2/updates/pfSense-1.2.3-1g-20090828-0527-nanobsd-upgrade.img.gz

    nope is img.gz…

    Anyway, whatever I do: ad0s2x get shot...
    assuming it dd's not really the right format/file?

    pfSense:~#  tail -f /cf/conf/upgrade_log.txt

    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.226607 secs (4627287 bytes/sec)

    /usr/bin/gzip -dc /root/firmware.tgz | /bin/dd of=/dev/ad0s2 obs=64k
    949467+8 records in
    7417+1 records out
    486130176 bytes transferred in 116.117005 secs (4186555 bytes/sec)
    After upgrade fdisk/bsdlabel

    /sbin/fsck_ufs -y /dev/ad0s2a
    Can't stat /dev/ad0s2a: No such file or directory
    Can't stat /dev/ad0s2a: No such file or directory

    /sbin/tunefs -L pfsense1 /dev/ad0s2a
    tunefs: /dev/ad0s2a: could not find special device

    <quote>Embedded has historically been a second class citizen</quote>
    <ironic>Now it's third class...?</ironic>

    No, to be honest, there seems to be a lack of testing. Even the the graphical part "firmware upgrade in Progress" is off the Center. And stays also after failing. I can not  find out if I test alpha or beta?

    With over 1000 reads, this topic seems to be well watched...



  • Just a note, I was able to successfully upgrade a pfsense 512MB cf to the latest snapshot, using manual firmware upgrade.  went flawlessly, which is good, because its a remote location (non critical, just for testing).



  • this means:

    Download from URL or local File? Or maybe WebInterface?

    From pfSense-1.2.3-512mb-20090827-1405 ?and the File was pfSense-1.2.3-512mb-20090829-0427-nanobsd-upgrade.img.gz?

    I think i will try this with another size than 1gb.



  • Download file appropriate to your system from here:

    http://snapshots.pfsense.org/FreeBSD_RELENG_7_2/pfSense_RELENG_1_2/updates

    File is now on your hard drive.

    Now update the pfSense instance using the Manual Update web interface.  "System:Firmware:Manual Update"



  • I have been attempting the manual updates.  I am using the Sandisk ultra II 4gig cf card and chose the the 2gig image mainly because for the longest time the 4gig image was not being updated.  Now it looks like the 512 and the 4gig image are the favorites to get updated.  My understanding from placing the 2gig image and a 4gig cf card was that the card was formated with 2 1gig partitions and that anything else was wasted.  It would seem that the fault lies somewhere in the formatting process that the nano image uses.  I will try out the 4 gig image and see how that manually updates.
    thanks,
    Jim



  • Okay, my 4gig CF card is only showing 1.88 gig capacity and will not reformat to original size.  Is this due to the nano image and windows only seeing one partition?  Is there any way to restore the card to the original size or is it permanently smaller?  This probably has something to do with my updating problem.
    jim


Log in to reply