Is nanobsd web-based upgrade supposed to be working now?
-
Hi
I looked http://redmine.pfsense.org/projects/pfsense/issues?set_filter=1 and didn't see any open bugs for this.
My last attempt to upgrade from 0731 snapshot to 0803 failed. Am I doing something wrong?
http://forum.pfsense.org/index.php/topic,18161.msg93883.html#msg93883
Thanks in advance
-
Bump
I just tried an upgrade from the 0805 2GB snapshot to the 0807 2GB snapshot. Same results.
It would appear that the upgrade image "latest.tgz" is wiping out the partition table on slice 2 on the CF card. I was unable to grab a copy of "latest.tgz" before the update process deleted it. Same for the "upgrade_log.txt".
Before upgrade:
/dev/ad0s1
/dev/ad0s1a
/dev/ad0s1c
/dev/ad0s2
/dev/ad0s2a
/dev/ad0s2c
/dev/ad0s3
/dev/ad0s4
…
After the upgrade attempt:/dev/ad0s1
/dev/ad0s1a
/dev/ad0s1c
/dev/ad0s2
/dev/ad0s3
/dev/ad0s4...
-
More information
"latest.tgz" is a tar file (Duh!), but I can't understand why "dd" would be used to copy it to slice2 of the CF card:
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.444509 secs (2358953 bytes/sec) /usr/bin/gzip -dc /root/latest.tgz | /bin/dd of=/dev/ad0s2 obs=64k 191654+819 records in 1501+1 records out 98416640 bytes transferred in 26.344876 secs (3735703 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 deviceIt would appear that the desire here is to have just one upgrade image ("latest.tgz") regardless of CF card size. Without knowing more about the intent and goals of the developers, I can only guess. Perhaps a better approach would be:
Remake the file system on slice 2. No "dd" zeroing out of the slice. newfs should just do the right thing regardless of CF card size. Then untar latest.tgz into the newly made slice2 root. Obviously if you're booted on slice2 all of this would happen to slice1 instead.
I think this explains why the upgrade works for those that download the appropriate image from http://snapshots.pfsense.org/FreeBSD_RELENG_7_2/pfSense_RELENG_1_2/updates/ and apply it manually through the web interface. Those are disk images.
-
Last update
Yes, manual update from the correct disk image works perfectly ;D:
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.441099 secs (2377190 bytes/sec) /usr/bin/gzip -dc /root/firmware.tgz | /bin/dd of=/dev/ad0s2 obs=64k WARNING: Expected rawoffset 0, found 63 1949066+606 records in 15229+1 records out 998097408 bytes transferred in 221.885917 secs (4498246 bytes/sec) After upgrade fdisk/bsdlabel /sbin/fsck_ufs -y /dev/ad0s2a *** FINAL System shutdown message from root@xxxxxx.lan *** System going down IMMEDIATELY pfSense is now shutting down ... Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 done All buffers synced. Uptime: 22h27m37s vr2: vr_stop: Rx shutdown error Rebooting... PC Engines ALIX.2 v0.99h 640 KB Base Memory 261120 KB Extended Memory 01F0 Master 848A SanDisk SDCFH2-002G Phys C/H/S 3970/16/63 Log C/H/S 992/64/63 1 FreeBSD 2 FreeBSD Boot: 2 //bboooott..ccoonnffiigg:: --DD Consoles: internal video/keyboard serial port BIOS drive C: is disk0 BIOS 640kB/261120kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (sullrich@RELENG_1_2__FreeBSD_7_2_snaps.pfsense.org, Fri Aug 7 21:05:43 EDT 2009) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x72f4b8 data=0x13cbec+0x51c60 | - Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-RELEASE-p3 #0: Fri Aug 7 21:14:29 EDT 2009 sullrich@RELENG_1_2__FreeBSD_7_2_snaps.pfsense.org:/usr/obj.pfSense/usr/pfS7 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Geode(TM) Integrated Processor by AMD PCS (498.05-MHz 586-class CPU) ...Wow, that's the first time I've successfully upgraded without a screwdriver!!! 8)
-
I don't get it ??? … I'm probably to stupid :P
I have also the alix with a 2GB CF card wit 1.2.3-RC2 (built on Thu Jul 23 17:25:52 EDT 2009) and tried to flash the lastest.gz from http://snapshots.pfsense.org/FreeBSD_RELENG_7_2/pfSense_RELENG_1_2/.updaters from the web menu manual firmware upgrade (it didn't work).
@gloomrider: Can you make a step-by-step manual, only short, which file to download, updgrade in console?, or manuel firmware upgrade from the firmware menu...
Many thanks!!!!
-
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? ???