Upgrade on Alix fails, ad0 corrupt
-
I'm trying to do an upgrade to one of the latest snapshots, but the command that updates the bootloader seems to fail.
14773+1 records out 968163840 bytes transferred in 213.830337 secs (4527720 bytes/sec) After upgrade fdisk/bsdlabel /sbin/fsck_ufs -y /dev/ad0s1a ** /dev/ad0s1a ** 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 6288 files, 325995 used, 1533363 free (627 frags, 191592 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)... 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 permittedIs there any way to fix this without having to reimage a 2.1 snap on the CF card from scratch?
-
That implies that something at the very start of the CF was corrupted somehow. I don't recall seeing that happen before even if a previous upgrade failed in odd ways.
There probably isn't a way around that exact error without re-imaging, but I would also start being suspicious of the CF as a whole. Get a good backup, grab a spare card, write that out and you'd be a lot better off.
It's possible that you could write the image to the same card again and be fine, but given that CF cards are rather inexpensive it may not be worth trying to save if there is a chance the card is starting to fail.
