Upgrade to 2.1.2: Stuck on 2.1
-
Can someone test 4g image to see if it's not broken? I had no problems upgrading 2g images, but 4g gives problem.
-
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.
-
http://pastebin.com/YX8vK7C1
-
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.
-
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.
-
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>
-
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.
-
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
-
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 102816Working: 4GB
/dev/ad0
g c7751 h16 s63
p 1 0xa5 63 3844449
p 2 0xa5 3844575 3844449
a 2
p 3 0xa5 7689024 102816Not Working: 2GB
/dev/ad0
g c3875 h16 s63
p 1 0xa5 63 1902033
p 2 0xa5 1902159 1902033
a 2
p 3 0xa5 3804192 102816Working: 2GB
/dev/ad0
g c3897 h16 s63
p 1 0xa5 63 1902033
a 1
p 2 0xa5 1902159 1902033
p 3 0xa5 3804192 102816 -
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?
-
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?
-
From my post a few entries up ( https://forum.pfsense.org/index.php?topic=75069.msg413219#msg413219 ) – I listed them in order of preference (and likely destructive potential!)
So try them in that order, method #1, then #2, then #3 only if both 1 and 2 fail.
-
[2.1-RELEASE][root@pfsense]/root(1): sysctl kern.geom.debugflags=16
kern.geom.debugflags: 0 -> 16
[2.1-RELEASE][root@pfsense]/root(2): d 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=1dd if=/dev/ad0 of=/tmp/mbr_part_bkup.img bs=512 count=1
1+0 records in
1+0 records out
512 bytes transferred in 0.000771 secs (664033 bytes/sec)
[2.1-RELEASE][root@pfsense]/root(3): dd of=/dev/ad0 if=/tmp/mbr_part_bkup.img bs=512 count=1
1+0 records in
GEOM_PART: integrity check failed (ad0, MBR)512 bytes transferred in 0.024720 secs (20712 bGEOM: ad0s1: media size does not match label.
ytes/sec)
GEOM: ad0s2: media size does not match label.
[2.1-RELEASE][root@pfsense]/root(4): -
I also have the problem in this post and have been following it closely. I am particularly interested in an in-place fix since I don't have an extra CF card or reader to re-flash.
mkomar - in the third line of your post shouldn't there be 2 d's instead of one for the 'dd' command? Maybe a copy/paste error?
-
Adding my experience to the thread. I am also having the same issue. I am using a SanDisk Extreme 4 GB CF. This is the output for fdisk -p /dev/ad0:
/dev/ad0
g c7751 h16 s63
p 1 0xa5 63 3861585
a 1
p 2 0xa5 3861711 3861585
p 3 0xa5 7723296 102816i have tried recreating the MBR using both the dd method and the fdisk method. Both did not help with a successful upgrade. I do not have a working device that I can copy the MBR so option #3 is out.
Additionally, trying to change the boot slice does not "stick".
-
mkomar - in the third line of your post shouldn't there be 2 d's instead of one for the 'dd' command? Maybe a copy/paste error?
Must have been dropped somehow. If it wasn't 'dd' the we would see an error instead of the command output.
I've still got a 'broken' device standing by if someone is interested in finding a reliable on-line fix. In the mean time, I've just done a config backup/restore and replaced the production units.
-
Since 2.1.3 came out, has this solved any of these problems for anyone? I was going to go for it, but I don't know if that's a good idea - wanted to see what others have seen for 2.1.3
I'm on nano alix 4g netgate
-
jimp, I've got the same problem on a 4gb CF. Output of fdisk -p /dev/ad0:
/dev/ad0
g c7745 h16 s63
p 1 0xa5 63 3854529
p 2 0xa5 3854655 3854529
a 2
p 3 0xa5 7709184 102816I've tried method #1 and #2, but neither worked. The output of fdisk -if /tmp/fdisk_bkup.txt /dev/ad0 from method #2 is below in case it's notable. I didn't get any errors from method #1, the system just booted back into 2.1 on the same slice. The same thing happened after method #2. I'm also not able to switch the bootup slice for whatever reason.
fdisk: WARNING line 2: number of cylinders (7745) may be out-of-range
(must be within 1-1024 for normal BIOS operation, unless the entire disk
is dedicated to FreeBSD)
******* Working on device /dev/ad0 *******This system and CF card have been in stable operation for awhile now and I've successfully installed all the updates from 2.0.1 to 2.1. I never got a chance to install 2.1.1, I've had similar problems attempting to install 2.1.2.
-
Since 2.1.3 came out, has this solved any of these problems for anyone? I was going to go for it, but I don't know if that's a good idea - wanted to see what others have seen for 2.1.3
Nothing related to this in particular has changed. The worst that'll happen is it'll reboot back on the same version so there isn't any harm in trying. The vast majority can upgrade just fine, so there's no reason to not try, as it'll more than likely work for you.
For those who have an ALIX (or anything else with 256 MB RAM and nano), if you're running more than you reasonably should be on a box with 256 MB RAM, disabling some services (especially OpenVPN if you're running multiple instances) before upgrading will allow you to upgrade successfully in an unrelated circumstance to this thread, where it fails because you run out of RAM when trying to upgrade.
-
I'm seeing the exact same reported issues that I've read in this thread…
gpart set -a active -i 1 ad0 gpart: table 'ad0' is corrupt: Operation not permitted
None of the prescribed fixes have done anything to help. I'm running a NetGate with M0n0wall on 256M RAM, of which only 54% is currently in use. I tried turning off a couple of services to see if it would help, but it is no use.
As with others, it looks like it's upgrading and says it will reboot when finished, but it appears to just log my out after a time, and no upgrade occurs. Do we have any clue why this isn't working? Do I need a new CF card?
Thanks,
Dave -
I ordered a new flash card and installed the latest version (2.1.3) without incident, following the guide posted at https://doc.pfsense.org/index.php/Installing_pfSense. I was able to backup & restore my configuration from the old card to the new card. I will probably re-flash the old card in a few weeks just to make it serviceable again, but right now it is my fallback. Everything transferred cleanly. I didn't need a serial modem cable since I already had the latest bios, but it's worth checking the bios version to make sure. By default the new image will install configure the gateway to 192.168.1.1 with admin and pfsense for login/password. I had to manually configure my laptop's IP address to be in that subnet before I could start the restore, but that might be an issue of the laptop I was using since it should work with DHCP. After the restore the pfsense IP changed to match my old setup, so I set the laptop back to DHCP and all is back to normal. Finally I can feel good about using the VPN again after heart bleed.
For those still stuck on 2.1 I would suggest doing the same, since I wasn't willing to risk a production firewall with the commands in this post, nor did others seem to have luck with them. A new flash card is only $10 and card readers are also cheap if you don't have one already. It's unfortunate that some of us got stuck, but at least it can be fixed.
-
Pmiller,
That's nice that you were able to do that, but it's not an option for some of us. I have pfSense firewalls distributed around the world. Am I supposed to hop on my jet and get this all done? Some sites don't have people onsite to ship it to me.
I, for one, am still waiting on a workable solution.
Michael
-
Finally found the right googleFU to find this thread ;)
I'm in the same boat with ad0 corrupt during the upgrade whether or not auto or manual, going from 2.1 to 2.1.3 (tried 2.1.2 for giggles with the same result)
Running a netgate fw-7535 with a 4gb CF card that has been upgraded successfully in the past.
fdisk output looks the same as others have posted.
$ fdisk -p /dev/ad0 # /dev/ad0 g c7745 h16 s63 p 1 0xa5 63 3854529 p 2 0xa5 3854655 3854529 a 2 p 3 0xa5 7709184 102816
Hours later
Ended up flashing to a new card which was a massive PITA as I had forgotten how to do it and the new card kept hanging on boot.In case it helps here's a fdisk dump of the newly working 4g card I have in there now. (running 4g nano amd64 2.1.3)
$ fdisk -p /dev/ad0 # /dev/ad0 g c7773 h16 s63 p 1 0xa5 63 3844449 a 1 p 2 0xa5 3844575 3844449 p 3 0xa5 7689024 102816