Upgrade to 2.1.2: Stuck on 2.1



  • Hi,

    I tried upgrading from 2.1 to 2.1.2 (I didn't get a chance to upgrade to 2.1.1). After router upgrades, I still end up on 2.1.

    I'm on alix board with nanobsd (4g)

    Anyone else having this issue?



  • I installed a fresh install of 2.1.1 on an ALIX. Now I updated to 2.1.2 but system seems to be crashed. Don't know exactly what happend, but I can't reach anything on my IP. Have to check via console later this day :(

    2.1.2 seems to be broken for ALIX.


  • Banned

    @mrsunfire:

    2.1.2 seems to be broken for ALIX.

    Negative. 8 Alix boxes running 2.1.2 ATM. And please do not multipost about the same issue.



  • Go to Diag>nanobsd and check the upgrade log, what does that show?



  • Negative. 8 Alix boxes running 2.1.2 ATM.

    and I have 11 Alix/nanoBSD running 2.1.2 - they are working nicely.



  • @cmb:

    Go to Diag>nanobsd and check the upgrade log, what does that show?

    Showing success upgrade.
    Only errors I've noticed where:

    
    Misc log:
    
    fdisk: invalid fdisk partition table found
    bsdlabel: /dev/ad0s3: no valid label found
    bsdlabel: /dev/ad0s3: no valid label found
    bsdlabel: /dev/ad0s3: no valid label found
    tar: Failed to set default locale
    tar: Failed to set default locale
    shutdown: [pid 90083]
    
    


  • @doktornotor:

    @mrsunfire:

    2.1.2 seems to be broken for ALIX.

    Negative. 8 Alix boxes running 2.1.2 ATM. And please do not multipost about the same issue.

    Don't know exactly why you deletet my post with error updating my ALIX APU1C to 2.1.2. This thread is a different issue, but ok. I will go on…

    After resetting my pfsense because it was stuck on "Reboot after updating firmware", my serial console isn't working anymore. I only can connect via SSH. The connection is fine, because I see the ALIX booting till you can select from what you want to boot. As default I chose F1: pfsense, then it starts to boot up, but nothing more happens.

    What to do?

    Also strange: I now use a i386 version of pfsense, with 2.1.1 I used the AMD version.


  • Banned

    0/ I deleted nothing, I'm not even a moderator. Regardless, it has been deleted because you posted two idential posts in two different threads. Just do NOT do that.
    1/ APU != ALIX. You seriously are confusing people here. Totally different HW!
    2/ Last time I've heard, cross-arch upgrades are not exactly something supported. Why don't you just do a fresh install and restore the config?
    3/ The APU is something far from tested as well.



  • OK, the APU is from the same manufactor of the ALIX but called different. I will try a fresh install and come back later.



  • I'm seeing the same issue on an ALIX board. The upgrade goes through with no errors reported on screen/console, but when it reboots, it boots back into 2.1. The upgrade log has only the following that appears notable.

    fdisk: invalid fdisk partition table found
    bsdlabel: /dev/ad0s3: no valid label found
    bsdlabel: /dev/ad0s3: no valid label found
    bsdlabel: /dev/ad0s3: no valid label found
    shutdown: [pid 75726]



  • @kaput are you on 4g image?



  • Yes.



  • Can someone test 4g image to see if it's not broken? I had no problems upgrading 2g images, but 4g gives problem.


  • Rebel Alliance Developer Netgate

    Provide the whole upgrade log. The part being quoted isn't the problem.

    We tested the 4GB version more than others, as it's the most common one in use.




  • Rebel Alliance Developer Netgate

    Here's your problem:

    gpart set -a active -i 1 ad0
    gpart: table 'ad0' is corrupt: Operation not permitted
    

    Try this:

    gpart bootcode -b /boot/mbr ad0
    

    Then try the upgrade again.



  • Thanks, jimp. Missed that perm issue in the log.

    Unfortunately, running "gpart bootcode -b /boot/mbr ad0" also results in the exact same error, noting that ad0 is corrupt.



  • I have the exact same issue with same error in my upgrade log on a 2g install on an Alix box.

    I also had the issue on a 4g install but I opted to flash a new image and swap cards. The 2g box though is 4 hours round trip away so I would love to fix the issue and update remotely.

    I also had another 4g box that updated just fine. So, 2 out of 3 are broken and would not update with autoupdate or manual update.


  • Rebel Alliance Developer Netgate

    Other things to try:

    Set the boot slice on Diagnostics > NanoBSD, see if it actually changes.

    or

    gpart recover ad0
    

    or

    sysctl kern.geom.debugflags=16
    boot0cfg -v -s 1 ad0
    fdisk -a /dev/ad0
    sysctl kern.geom.debugflags=0
    

    (For fdisk make sure to specify the values it asks and press 'y' to confirm!)

    We have yet to be able to reproduce this effectively, but several people have hit it. It would be helpful to know some more about the original setup that failed. Was it your own CF or did it come with the device? Had it ever been upgraded before, and if so how many times? What was its original version of pfSense on that CF card before upgrading?



  • Slice does not change; nor I can copy ad0s2 -> ad0s1.



  •  gpart bootcode -b /boot/mbr ad0
    gpart: table 'ad0' is corrupt: Operation not permitted
    
    
    gpart recover ad0
    gpart: recovering 'ad0' failed: Function not implemented
    
    


  • 
    fdisk -a /dev/ad0
    
    

    I get an Intput/Output error.

    This is compact flash card. It was installed as 2.0 and then upgraded to 2.0.3 and later 2.1.



  • In my case I had pfSense nanobsd v1.2.3 upgraded to v2.0, that one upgraded to v2.1 - all of them upgraded OK. Now when I wanted to upgrade to v2.1.2, It seems corrupted. I'm preparing a fresly flashed CF card with config already put in.



  • I am having the same issue.  Hopefully my situation will help shed some light.

    • I have upgraded at least two other NanoBSD 4G (ALIX) system without issue.

    • Today I am upgrading three identical boxes - ALIX boards running 4G CF card

    • One existing install was already 2.1 and I successfully upgraded to 2.1.2

    • The other two were at 2.0.3 and I successfully upgraded to 2.1, but they are both now stuck on 2.1 after auto-upgrade and manual upgrade attempts.



  • Also a side note, I'm not on Alix, but on a Jetway JNF99 with 5 intel nics, Atom CPU and 4GB of RAM, i386 build. The new CF card will carry a 64-bit version this time.


  • Rebel Alliance Developer Netgate

    If you're getting an "i/o error" or "device not configured", reboot and try again. At least for the "i/o error" it seems to lean more toward maybe a bad CF but it's still tough to say for sure.

    Also worth a try:

    sysctl kern.geom.debugflags=16
    fdisk -B -b /boot/boot0 ad0
    


  • I'm in the same boat with 40 plus devices scattered across 4 provinces. I actually haven't managed to get a single one to upgrade except the 3 in our local offices that I performed a clean install on, 2G and 4G, current versions 2.03 and 2.1 on all remotes attempting auto upgrade and manual firmware uploads. Not sure what to do, since I don't want to risk chopping them up and losing remote connectivity. I don't own a helicopter to get around that quickly  ;D

    All Alix boards. Errors in the upgrade log

    fdisk: invalid fdisk partition table found
    bsdlabel: /dev/ad0s3: no valid label found
    bsdlabel: /dev/ad0s3: no valid label found
    bsdlabel: /dev/ad0s3: no valid label found
    tar: Failed to set default locale
    tar: Failed to set default locale
    shutdown: [pid 24752]



  • I have same issue apparently. No answer. Here's my log:

    NanoBSD Firmware upgrade in progress...
    
    Installing /root/latest.tgz.
    SLICE         1
    OLDSLICE      2
    TOFLASH       ad0s1
    COMPLETE_PATH ad0s1a
    GLABEL_SLICE  pfSense0
    Sun Apr 13 02:37:42 EDT 2014
    
    total 8
    dr-xr-xr-x   7 root  wheel         512B Apr 12 15:03 .
    drwxr-xr-x  26 root  wheel         1.0k Apr 12 15:03 ..
    crw-r-----   1 root  operator    0,  56 Apr 12 15:03 ad0
    crw-r-----   1 root  operator    0,  57 Apr 12 15:03 ad0s1
    crw-r-----   1 root  operator    0,  60 Apr 12 15:03 ad0s1a
    crw-r-----   1 root  operator    0,  58 Apr 12 15:03 ad0s2
    crw-r-----   1 root  operator    0,  61 Apr 12 15:03 ad0s2a
    crw-r-----   1 root  operator    0,  59 Apr 12 15:03 ad0s3
    crw-------   1 root  operator    0,  28 Apr 12 15:03 ata
    crw-------   1 root  wheel       0,  11 Apr 13 01:29 bpf
    lrwxr-xr-x   1 root  wheel           3B Apr 12 15:03 bpf0 -> bpf
    crw-------   1 root  tty         0,   4 Apr 13 02:37 console
    crw-rw-rw-   1 root  wheel       0,  44 Apr 12 15:03 crypto
    crw-rw-rw-   1 root  wheel       0,  10 Apr 12 15:03 ctty
    crw-rw----   1 uucp  dialer      0,  35 Apr 12 15:03 cuau0
    crw-rw----   1 uucp  dialer      0,  36 Apr 12 15:03 cuau0.init
    crw-rw----   1 uucp  dialer      0,  37 Apr 12 15:03 cuau0.lock
    crw-rw----   1 uucp  dialer      0,  41 Apr 12 15:03 cuau1
    crw-rw----   1 uucp  dialer      0,  42 Apr 12 15:03 cuau1.init
    crw-rw----   1 uucp  dialer      0,  43 Apr 12 15:03 cuau1.lock
    crw-------   1 root  wheel       0,   5 Apr 12 15:03 devctl
    cr--------   1 root  wheel       0,  54 Apr 12 15:03 devstat
    dr-xr-xr-x   2 root  wheel         512B Apr 12 15:03 fd
    crw-------   1 root  wheel       0,  13 Apr 12 15:03 fido
    crw-r-----   1 root  operator    0,   3 Apr 12 15:03 geom.ctl
    crw-------   1 root  wheel       0,  23 Apr 12 15:03 io
    crw-------   1 root  wheel       0,   8 Apr 12 15:03 klog
    crw-r-----   1 root  kmem        0,  15 Apr 12 15:03 kmem
    dr-xr-xr-x   2 root  wheel         512B Apr 12 15:03 led
    crw-r-----   1 root  operator    0,  62 Apr 12 15:03 md0
    crw-r-----   1 root  operator    0,  66 Apr 12 15:03 md1
    crw-------   1 root  wheel       0,  47 Apr 12 15:03 mdctl
    crw-r-----   1 root  kmem        0,  14 Apr 12 15:03 mem
    crw-------   1 root  kmem        0,  16 Apr 12 15:03 nfslock
    crw-rw-rw-   1 root  wheel       0,  25 Apr 13 02:37 null
    crw-r--r--   1 root  wheel       0,  27 Apr 12 15:03 pci
    crw-rw----   1 root  proxy       0,  45 Apr 12 15:03 pf
    crw-rw-rw-   1 root  wheel       0,   9 Apr 12 15:03 ptmx
    crw-rw-rw-   1 root  wheel       0,   6 Apr 12 15:03 random
    crw-------   1 root  wheel       0,  24 Apr 12 15:03 speaker
    lrwxr-xr-x   1 root  wheel           4B Apr 12 15:03 stderr -> fd/2
    lrwxr-xr-x   1 root  wheel           4B Apr 12 15:03 stdin -> fd/0
    lrwxr-xr-x   1 root  wheel           4B Apr 12 15:03 stdout -> fd/1
    crw-------   1 root  wheel       0,  32 Apr 12 15:03 ttyu0
    crw-------   1 root  wheel       0,  33 Apr 12 15:03 ttyu0.init
    crw-------   1 root  wheel       0,  34 Apr 12 15:03 ttyu0.lock
    crw-------   1 root  wheel       0,  38 Apr 12 15:03 ttyu1
    crw-------   1 root  wheel       0,  39 Apr 12 15:03 ttyu1.init
    crw-------   1 root  wheel       0,  40 Apr 12 15:03 ttyu1.lock
    crw-------   1 uucp  dialer      0,  73 Apr 12 15:04 tun1
    dr-xr-xr-x   2 root  wheel         512B Apr 12 15:03 ufs
    dr-xr-xr-x   2 root  wheel         512B Apr 12 15:03 ufsid
    lrwxr-xr-x   1 root  wheel           9B Apr 12 15:03 ugen0.1 -> usb/0.1.0
    lrwxr-xr-x   1 root  wheel           9B Apr 12 15:03 ugen1.1 -> usb/1.1.0
    lrwxr-xr-x   1 root  wheel           6B Apr 12 15:03 urandom -> random
    dr-xr-xr-x   2 root  wheel         512B Apr 12 15:03 usb
    crw-r--r--   1 root  operator    0,  46 Apr 12 15:03 usbctl
    crw-------   1 root  operator    0,  55 Apr 12 15:03 xpt0
    crw-rw-rw-   1 root  wheel       0,  26 Apr 12 15:03 zero
    
    -rw-r--r--  1 root  wheel    76M Apr 13 02:34 /root/latest.tgz
    
    MD5 (/root/latest.tgz) = b914649dd6be90a461a99615c07882c3
    
    /dev/ufs/pfSense1 on / (ufs, local, noatime, synchronous)
    devfs on /dev (devfs, local)
    /dev/ufs/cf on /cf (ufs, local, noatime, synchronous)
    /dev/md0 on /tmp (ufs, local)
    /dev/md1 on /var (ufs, local)
    devfs on /var/dhcpd/dev (devfs, local)
    
    last pid: 52248;  load averages:  3.09,  1.78,  1.20  up 0+11:34:50    02:38:14
    67 processes:  7 running, 60 sleeping
    
    Mem: 92M Active, 50M Inact, 74M Wired, 6780K Cache, 33M Buf, 7052K Free
    Swap: 
    
      PID USERNAME  THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
    92215 root        1  76    0 40308K 20156K accept   4:21  0.00% php
    86955 root        1  76    0 26484K 15784K accept   2:37  0.00% php
    41671 root        1  44    0  8004K  4984K kqread   1:04  0.00% lighttpd
    93099 root        1  76   20  3644K  1332K piperd   0:20  0.00% sh
      292 root        1  76   20  3352K  1112K kqread   0:15  0.00% check_reload_status
    45599 nobody      1  44    0  5512K  2316K select   0:12  0.00% dnsmasq
    31777 root        1  44    0  3264K  1208K select   0:12  0.00% apinger
    97171 root        1  44    0  3416K  1400K select   0:10  0.00% syslogd
    66552 root        1  44    0  7284K  5872K select   0:07  0.00% bsnmpd
    30425 root       21  44    0 21400K  3996K ucond    0:05  0.00% filterdns
    78170 root        1  64   20  6280K  6300K select   0:05  0.00% ntpd
    52603 dhcpd       1  44    0 11456K  7584K select   0:05  0.00% dhcpd
    25251 root        1  44    0  3264K   848K piperd   0:03  0.00% logger
    90659 proxy       1  64   20 10356K  5928K kqread   0:03  0.00% squid
    25151 root        1  44    0  5868K  1916K bpf      0:02  0.00% tcpdump
    61760 root        1  44    0  5952K  2324K kqread   0:01  0.00% lighttpd
    72531 root        1  64   20  5432K  3224K select   0:01  0.00% openvpn
    19617 root        1  44    0  5144K  1544K select   0:01  0.00% hostapd
    
    NanoBSD upgrade starting
    
    dd if=/dev/zero of=/dev/ad0s1 bs=1m count=1
    1+0 records in
    1+0 records out
    1048576 bytes transferred in 0.344171 secs (3046671 bytes/sec)
    
    /usr/bin/gzip -dc /root/latest.tgz | /bin/dd of=/dev/ad0s1 obs=64k
    3844449+0 records in
    30034+1 records out
    1968357888 bytes transferred in 394.695594 secs (4987028 bytes/sec)
    After upgrade fdisk/bsdlabel
    
    /sbin/fsck_ufs -y /dev/ad0s1a
    ** /dev/ad0s1a
    ** Last Mounted on /tmp/netgatemnt
    ** Phase 1 - Check Blocks and Sizes
    ** Phase 2 - Check Pathnames
    ** Phase 3 - Check Connectivity
    ** Phase 4 - Check Reference Counts
    ** Phase 5 - Check Cyl groups
    5506 files, 317470 used, 3462558 free (542 frags, 432752 blocks, 0.0% fragmentation)
    
    ***** FILE SYSTEM IS CLEAN *****
    
    /sbin/tunefs -L pfSense0 /dev/ad0s1a
    Checking for post_upgrade_command...
    Found post_upgrade_command, executing (pfSense0)...
    tar: Failed to set default locale
    Checking for /tmp/pfSense0/tmp/post_upgrade_command.php... 
    Running /tmp/pfSense0/tmp/post_upgrade_command.php pfSense0
    Adding serial port settings (/tmp/pfSense0)...
    Reading /tmp/pfSense0/boot/loader.conf...
    
    /dev/ufs/pfSense0 / ufs ro,sync,noatime 1 1
    /dev/ufs/cf /cf ufs ro,sync,noatime 1 1
    
    gpart set -a active -i 1 ad0
    gpart: table 'ad0' is corrupt: Operation not permitted
    
    /usr/sbin/boot0cfg -s 1 -v /dev/ad0
    #   flag     start chs   type       end chs       offset         size
    1   0x00      0:  1: 1   0xa5    751: 15:63           63      3854529
    2   0x80    752:  1: 1   0xa5    479: 15:63      3854655      3854529
    3   0x00    480:  0: 1   0xa5    581: 15:63      7709184       102816
    
    version=2.0  drive=0x80  mask=0x3  ticks=182  bell=# (0x23)
    options=packet,update,nosetdrv
    volume serial ID 9090-9090
    default_selection=F1 (Slice 1)
    Sun Apr 13 02:48:27 EDT 2014
    
    NanoBSD Firmware upgrade is complete.  Rebooting in 10 seconds.
    
    File list:
    /tmp/pfSense0
    /tmp/pfSense0/.snap
    /tmp/pfSense0/COPYRIGHT
    /tmp/pfSense0/bin
    /tmp/pfSense0/bin/cat
    /tmp/pfSense0/bin/chflags
    /tmp/pfSense0/bin/chmod
    /tmp/pfSense0/bin/cp
    /tmp/pfSense0/bin/csh
    /tmp/pfSense0/bin/tcsh
    /tmp/pfSense0/bin/date
    /tmp/pfSense0/bin/dd
    /tmp/pfSense0/bin/df
    /tmp/pfSense0/bin/domainname
    /tmp/pfSense0/bin/echo
    /tmp/pfSense0/bin/expr
    /tmp/pfSense0/bin/hostname
    /tmp/pfSense0/bin/kenv
    /tmp/pfSense0/bin/kill
    /tmp/pfSense0/bin/ln
    /tmp/pfSense0/bin/link
    .....a bunch more tmp files..
    Misc log:
    
    fdisk: invalid fdisk partition table found
    bsdlabel: /dev/ad0s3: no valid label found
    bsdlabel: /dev/ad0s3: no valid label found
    bsdlabel: /dev/ad0s3: no valid label found
    tar: Failed to set default locale
    tar: Failed to set default locale
    shutdown: [pid 82135]
    
    fdisk/bsdlabel log:
    
    Before upgrade fdisk/bsdlabel
    ******* Working on device /dev/ad0 *******
    parameters extracted from in-core disklabel are:
    cylinders=7745 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=7745 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 3854529 (1882 Meg), flag 0
    	beg: cyl 0/ head 1/ sector 1;
    	end: cyl 751/ head 15/ sector 63
    The data for partition 2 is:
    sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
        start 3854655, size 3854529 (1882 Meg), flag 80 (active)
    	beg: cyl 752/ head 1/ sector 1;
    	end: cyl 479/ head 15/ sector 63
    The data for partition 3 is:
    sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
        start 7709184, size 102816 (50 Meg), flag 0
    	beg: cyl 480/ head 0/ sector 1;
    	end: cyl 581/ head 15/ sector 63
    The data for partition 4 is:
     <unused># /dev/ad0s1:
    type: unknown
    disk: amnesiac
    label: 
    flags:
    bytes/sector: 512
    sectors/track: 63
    tracks/cylinder: 16
    sectors/cylinder: 1008
    cylinders: 3813
    sectors/unit: 3844449
    rpm: 3600
    interleave: 1
    trackskew: 0
    cylinderskew: 0
    headswitch: 0		# milliseconds
    track-to-track seek: 0	# milliseconds
    drivedata: 0 
    
    8 partitions:
    #          size     offset    fstype   [fsize bsize bps/cpg]
      a:    3844433         16    unused        0     0   
      c:    3844449          0    unused        0     0     # "raw" part, don't edit
    # /dev/ad0s2:
    type: unknown
    disk: amnesiac
    label: 
    flags:
    bytes/sector: 512
    sectors/track: 63
    tracks/cylinder: 16
    sectors/cylinder: 1008
    cylinders: 3813
    sectors/unit: 3844449
    rpm: 3600
    interleave: 1
    trackskew: 0
    cylinderskew: 0
    headswitch: 0		# milliseconds
    track-to-track seek: 0	# milliseconds
    drivedata: 0 
    
    8 partitions:
    #          size     offset    fstype   [fsize bsize bps/cpg]
      a:    3844433         16    unused        0     0   
      c:    3844449          0    unused        0     0     # "raw" part, don't edit
    ---------------------------------------------------------------
    
    ******* Working on device /dev/ad0 *******
    parameters extracted from in-core disklabel are:
    cylinders=7745 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=7745 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 3854529 (1882 Meg), flag 0
    	beg: cyl 0/ head 1/ sector 1;
    	end: cyl 751/ head 15/ sector 63
    The data for partition 2 is:
    sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
        start 3854655, size 3854529 (1882 Meg), flag 80 (active)
    	beg: cyl 752/ head 1/ sector 1;
    	end: cyl 479/ head 15/ sector 63
    The data for partition 3 is:
    sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
        start 7709184, size 102816 (50 Meg), flag 0
    	beg: cyl 480/ head 0/ sector 1;
    	end: cyl 581/ head 15/ sector 63
    The data for partition 4 is:
     <unused># /dev/ad0s1:
    type: unknown
    disk: amnesiac
    label: 
    flags:
    bytes/sector: 512
    sectors/track: 63
    tracks/cylinder: 16
    sectors/cylinder: 1008
    cylinders: 3813
    sectors/unit: 3844449
    rpm: 3600
    interleave: 1
    trackskew: 0
    cylinderskew: 0
    headswitch: 0		# milliseconds
    track-to-track seek: 0	# milliseconds
    drivedata: 0 
    
    8 partitions:
    #          size     offset    fstype   [fsize bsize bps/cpg]
      a:    3844433         16    unused        0     0   
      c:    3844449          0    unused        0     0     # "raw" part, don't edit
    # /dev/ad0s2:
    type: unknown
    disk: amnesiac
    label: 
    flags:
    bytes/sector: 512
    sectors/track: 63
    tracks/cylinder: 16
    sectors/cylinder: 1008
    cylinders: 3813
    sectors/unit: 3844449
    rpm: 3600
    interleave: 1
    trackskew: 0
    cylinderskew: 0
    headswitch: 0		# milliseconds
    track-to-track seek: 0	# milliseconds
    drivedata: 0 
    
    8 partitions:
    #          size     offset    fstype   [fsize bsize bps/cpg]
      a:    3844433         16    unused        0     0   
      c:    3844449          0    unused        0     0     # "raw" part, don't edit
    ---------------------------------------------------------------
    
    Final upgrade fdisk/bsdlabel
    ******* Working on device /dev/ad0 *******
    parameters extracted from in-core disklabel are:
    cylinders=7745 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=7745 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 3854529 (1882 Meg), flag 0
    	beg: cyl 0/ head 1/ sector 1;
    	end: cyl 751/ head 15/ sector 63
    The data for partition 2 is:
    sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
        start 3854655, size 3854529 (1882 Meg), flag 80 (active)
    	beg: cyl 752/ head 1/ sector 1;
    	end: cyl 479/ head 15/ sector 63
    The data for partition 3 is:
    sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
        start 7709184, size 102816 (50 Meg), flag 0
    	beg: cyl 480/ head 0/ sector 1;
    	end: cyl 581/ head 15/ sector 63
    The data for partition 4 is:
     <unused># /dev/ad0s1:
    type: unknown
    disk: amnesiac
    label: 
    flags:
    bytes/sector: 512
    sectors/track: 63
    tracks/cylinder: 16
    sectors/cylinder: 1008
    cylinders: 3813
    sectors/unit: 3844449
    rpm: 3600
    interleave: 1
    trackskew: 0
    cylinderskew: 0
    headswitch: 0		# milliseconds
    track-to-track seek: 0	# milliseconds
    drivedata: 0 
    
    8 partitions:
    #          size     offset    fstype   [fsize bsize bps/cpg]
      a:    3844433         16    unused        0     0   
      c:    3844449          0    unused        0     0     # "raw" part, don't edit
    # /dev/ad0s2:
    type: unknown
    disk: amnesiac
    label: 
    flags:
    bytes/sector: 512
    sectors/track: 63
    tracks/cylinder: 16
    sectors/cylinder: 1008
    cylinders: 3813
    sectors/unit: 3844449
    rpm: 3600
    interleave: 1
    trackskew: 0
    cylinderskew: 0
    headswitch: 0		# milliseconds
    track-to-track seek: 0	# milliseconds
    drivedata: 0 
    
    8 partitions:
    #          size     offset    fstype   [fsize bsize bps/cpg]
      a:    3844433         16    unused        0     0   
      c:    3844449          0    unused        0     0     # "raw" part, don't edit
    ---------------------------------------------------------------</unused></unused></unused> 
    


  • @mjohnson:

    I'm in the same boat with 40 plus devices scattered across 4 provinces. I actually haven't managed to get a single one to upgrade except the 3 in our local offices that I performed a clean install on, 2G and 4G, current versions 2.03 and 2.1 on all remotes attempting auto upgrade and manual firmware uploads. Not sure what to do, since I don't want to risk chopping them up and losing remote connectivity. I don't own a helicopter to get around that quickly  ;D

    All Alix boards. Errors in the upgrade log

    fdisk: invalid fdisk partition table found
    bsdlabel: /dev/ad0s3: no valid label found
    bsdlabel: /dev/ad0s3: no valid label found
    bsdlabel: /dev/ad0s3: no valid label found
    tar: Failed to set default locale
    tar: Failed to set default locale
    shutdown: [pid 24752]

    I hear ya about all those remote devices and no time to travel there if there is a problem.  For me if there is a risk of breaking it at a remote site I would send them another firewall box and tell them to swap it when time permits.  This way the new firewall is working at the corporate office with the remote site's configuration file and should work fine when it reaches at the remote site.  Then have them send the old one back to redo for another site.

    I know it's a PITA.  Might be good for critical sites that can't go down for any period of time.  Hopefully soon we can get these upgrade issues sorted out.


  • Rebel Alliance Developer Netgate

    I have a faulty image in my hands now, hopefully I can track down a solution soon.

    Current theory is that it was actually corrupt before the latest update and it just started to show it now, but once I have more time to experiment with the broken CF image I'll know for sure.

    I'm certain we can come up with a fix, but it might be something scary like doing a DD of a good partition table to the start of the disk. Not something I'd generally recommend however in theory all NanoBSD images of the same size should have the same partition layout so it may be safe.

    In the meantime I'd like to find out if everyone involved here had 4GB NanoBSD images, or both 2GB and 4GB, or even more.



  • Both 4GB CF for me.



  • 2 and 4GB for me.



  • Jim,

    I have both 2G and 4G nanobsd images displaying this problem.

    Michael


  • Rebel Alliance Developer Netgate

    For those of you that have an issue, show me the output of:

    fdisk -p /dev/ad0
    

    And note if it's 2gb or 4gb.

    If you have a working system of the same size to compare against, show the output from it also.



  • Not working: 2GB

    /dev/ad0

    g c3875 h16 s63
    p 1 0xa5 63 1902033
    a 1
    p 2 0xa5 1902159 1902033
    p 3 0xa5 3804192 102816

    Working: 4GB

    /dev/ad0

    g c7751 h16 s63
    p 1 0xa5 63 3844449
    p 2 0xa5 3844575 3844449
    a 2
    p 3 0xa5 7689024 102816

    Not Working: 2GB

    /dev/ad0

    g c3875 h16 s63
    p 1 0xa5 63 1902033
    p 2 0xa5 1902159 1902033
    a 2
    p 3 0xa5 3804192 102816

    Working: 2GB

    /dev/ad0

    g c3897 h16 s63
    p 1 0xa5 63 1902033
    a 1
    p 2 0xa5 1902159 1902033
    p 3 0xa5 3804192 102816


  • Rebel Alliance Developer Netgate

    Those last two are interesting in that they're nearly identical and one works and the other doesn't. I expect some variation as we have, over time, slightly shrunk the NanoBSD slice sizes, but that is a bit curious.

    The .img file I read from the CF with the "corrupt" table appears to be OK, despite the CF showing a damaged table. So I'm left to wonder if there may be some other CF-related factor at play.

    The following commands could be dangerous so if you choose to attempt them, proceed with extreme caution. I tested these on my own ALIX with a good MBR and it survived, but there are no guarantees. You need only try one of these methods unless it doesn't help, then proceed to the next one.

    Method #1: Rewrite the MBR+Partition table with dd

    sysctl kern.geom.debugflags=16
    dd if=/dev/ad0 of=/tmp/mbr_part_bkup.img bs=512 count=1
    dd of=/dev/ad0 if=/tmp/mbr_part_bkup.img bs=512 count=1
    
    

    Method #2: Have fdisk reset the partition table:

    sysctl kern.geom.debugflags=16
    fdisk -p /dev/ad0 > /tmp/fdisk_bkup.txt
    fdisk -if /tmp/fdisk_bkup.txt /dev/ad0
    
    

    Method #3: Take a "working" fdisk output and rewrite using it. I can't stress enough that you must make sure the partition boundaries line up, don't grab the fdisk output from a differently sized card:

    
    # Get the "fdisk -p" output from a similar but working CF, save it in /tmp/fdisk_bkup.txt
    sysctl kern.geom.debugflags=16
    fdisk -if /tmp/fdisk_bkup.txt /dev/ad0
    
    

    After any of those, chances are that no commands will work to reboot the unit, so either pull the power or run the following to force a panic+reboot:

    sysctl debug.debugger_on_panic=0
    sysctl debug.kdb.panic=1
    

    After that has completed, try the upgrade once again.

    Obviously that isn't something you'd want to try on a remote unit.



  • All of mine are in remote locations and in production. Can't risk taking them down.

    I'll be swapping them out with upgraded (Software) replacements in the next week or so.

    Is there value in trying these fixes after that?


  • Rebel Alliance Developer Netgate

    @mkomar:

    All of mine are in remote locations and in production. Can't risk taking them down.

    I'll be swapping them out with upgraded (Software) replacements in the next week or so.

    Is there value in trying these fixes after that?

    It would still help to know if any of the above methods would correct the faulty partition table, so that others can benefit from the knowledge.



  • I should have a couple of those units on hand next week. I'll give it a shot and report back once I've done so.



  • JimP - Should have my hands on one or two of the malfunctioning units in the next few days. I'd be happy to try the various fixes you have proposed, and/or if it would be of more value, I'd be happy to either get you serial access to one or both of them and/or get either CF card(s) and/or dd img dumps out to you.

    Would any of the options work better than others as far as getting a 'known good' fix out there?