Latest snapshots won't install (disk full?)
-
2.0-BETA4 (i386)
built on Mon Sep 20 22:40:28 EDT 2010
FreeBSD 8.1-RELEASE-p1
nanobsd (512mb)I tried using autoupdate to install the Oct 24 8am snapshot in the UI. After downloading the image Firefox just goes to 'page not found'. Refreshing brings me back to the Dashboard and the old firmware.
I tried to manually update in the web UI and it tells me that the image is corrupt.
I tried to update using option 13 on the console using both URL and local file, and both times it tells me that the disk is full. The dashboard is telling me that the disk is 87% full, so I'm guessing this is the problem.
The CF card I'm using is actually a 2GB card, I just moved to the 512MB image because it sped up the update process, but now that decision appears to be biting me.
Is it normal for the 512MB image to not have room to update itself or have I botched something? Would it be easiest at this point to partition and mount the unused space on my CF as a temp space to upload a new image? Can somebody give me a hint on doing that? Here's the output of fdisk, if that helps.
fdisk ******* Working on device /dev/ufs/pfsense0 ******* parameters extracted from in-core disklabel are: cylinders=444 heads=16 sectors/track=63 (1008 blks/cyl) parameters to be used for BIOS calculations are: cylinders=444 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 447489 (218 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 443/ 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></unused> -
Someone else noticed the same problem on IRC. Something that was added to recent builds pushed it over the size limit. Not sure what the ETA is on a fix, but the easiest thing to do is to use the 1GB or larger images.
-
the easiest thing to do is to use the 1GB or larger images.
That would require reflashing the CF at this point though, right? Wouldn't it be easier to mount the unused portion of the CF and use it as a temp space to upload a new image? I'm a little inept with BSD partitioning to go messing with this right now though, so I guess in my case the answer to my question is no. ;)
-
Yes it would require a reflash.
We can't assume there is any free space on a CF to use. Someone may be running a 512MB image on an actual 512MB card. And we need to write to the alternate slice so it can't be downloaded there.
-
I think I'm in luck, and I've overwritten only the first slice with the 512MB image:
disklabel /dev/ad0s1 # /dev/ad0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 448481 16 unused 0 0 c: 448497 0 unused 0 0 # "raw" part, don't edit disklabel: partition c doesn't cover the whole unit! disklabel: An incorrect partition c may cause problems for standard system utili tiesdisklabel /dev/ad0s2 # /dev/ad0s2: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 1902017 16 unused 0 0 c: 1902033 0 unused 0 0 # "raw" part, don't editI'm currently running in ad0s1, so if I boot into ad0s2 I should be in business. You'll warn me if I look like I'm going to blow something up, right?
-
Delete Perl and you might have enough space to update. As far as I know, nothing is actually using it. It is only there because currently rrdtool is marked as needing Perl (even though it doesn't really, might even be just for some sample scripts that are included in the build). A simple change to its options in the Makefile would fix this so that it is no longer including Perl in the builds (unless it isn't the only program listing Perl as a dependency). There may be other unnecessary programs that have been added while updating to newer versions of programs, but Perl is a big one I know about.
Run these commands:
/etc/rc.conf_mount_rw
rm -rf /usr/local/lib/perl5
/etc/rc.conf_mount_roIf you don't have any large packages installed, this should free up enough space to update.
-
Thanks for the tip, it will be valuable to have on record.
I dodged the bullet this time because I'm running on a 2G CF, and my second slice still had a 2G image on it. I only had to switch to the other slice then update to the latest 2G snap as usual.
-
Of course, the only way you wouldn't be able to update from the other slice should be if you had flashed the card with an image that can't update from either slice - in other words you would be unable to overwrite the slice that can successfully perform an update from one that cannot update (there may be exceptions to this, but generally it holds true).
The main reasons an update fails either do not even start to write to the other slice (update file didn't pass checks or ran out of space downloading update) or overwrites the other slice but leaves one that is still capable of doing updates. Of course, you can run out of space by installing packages, filling up the drive with files created by packages, or uploading files and become unable to update, but that is something you can resolve, likely by uninstalling the packages or deleting the uploaded files.
