/ getting full during "make buildworld" for 4.5

Dominic Marks dominic_marks at btinternet.com
Tue Feb 5 02:22:06 GMT 2002


On Tue, Feb 05, 2002 at 12:58:38AM +0000, Charlie Brewster wrote:
> I'm trying to upgrade from 4.4 to 4.5 using cvsup and "make buildworld" et
> seq. and I'm seeing it crash due to running out of space on the /
> filesystem. Previous upgrade builds have gone mostly OK, although I had to
> manually move files around to free up space in / with 4.3 to 4.4. This time
> I cleared out as much as possible before starting the build, but there just
> isn't enough space allocated for the root filesystem.
> I originally partitioned single 6GB hard drive in the Box using sysinstall
> defaults with 4.0 and have it configured as follows:
> ad0s1a	/ 	  50 MB
> ad0sib	swap	 261 MB
> ados1e	/var	  20 MB
> ad0s1f	/usr	5857 MB
> With hindsight I probably should have made / and possibly /var larger (yes,
> I've had /var run out of space as well where I'd saved log files from
> earlier make buildworlds), or just put everything apart from swap into one
> big partition/slice.

The defaults were 50MB and 20MB and they were too low. I now set a 75MB /
and this is comfortable for both -STABLE and -CURRENT for the forseable
future. I should qualify my previous statement, its not the size of /
partition requirement has grown drastically, its that you need extra room
when installing, if you see below a 4.5 / is still 39MB.

> Am I correct in thinking that there's no way of reslicing/partitioning a
> FreeBSD hard drive as I might, for example with MS DOS and Partition Magic?

You can use growfs(8) if you have spare room on your disc which is
currently unclaimed. However, since there is no shrinkfs for most people
this isn't very useful.

> On one of the newsgroup archives I saw a reference to being able to do a
> workaround by setting up symbolic links. How might I set this up so that
> files being created during "make buildworld" and written to subdirectories
> in / get mapped to somewhere like a /usr/root directory where there would
> be loads of space? Does anyone have any experience of this sort of
> temporary fix working?

You could do the following, its a bit of a risky strategy however, a
possibly one shot trick.

rm /kernel.*
rm -r /modules*

dom at oxygen:/home/dom$ du -ch /kernel.*
3.5M    /kernel.GENERIC
1.7M    /kernel.old
5.2M    total

dom at oxygen:/home/dom$ du -ch /modules*
5.1M    /modules
5.1M    /modules.old
 10M    total

So you could reclaim 15.2MB of space. This might allow the install to
complete. Of course, if the machine crashes you'll just have /kernel
left which should be okay if you dont use any modules for loading
critical drivers and you don't install a broken kernel from your
installkernel, but thats unlikely... 'we' hope :)

dom at gallium:/home/dom$ mount
/dev/ad0s1a on / (ufs, local)
/dev/ad0s1f on /home (ufs, local)
/dev/ad0s1d on /misc (ufs, local)
/dev/ad0s1g on /tmp (ufs, asynchronous, local)
/dev/ad0s1h on /usr (ufs, local, soft-updates)
/dev/ad0s1e on /var (ufs, local, soft-updates)

This is how I have broken down the slicing on my most recently installed
machine. This lets me have different mounting settings depending on how
important the individual slice is. I place the most importance on /home
and /misc, /misc contains numerous 

dom at gallium:/home/dom$ uname -rs

dom at gallium:/home/dom$ df -h
Filesystem    Size   Used  Avail Capacity  Mounted on
/dev/ad0s1a    74M    39M    29M    58%    /
/dev/ad0s1f   1.9G   458M   1.3G    26%    /home
/dev/ad0s1d   3.5G   575M   2.7G    17%    /misc
/dev/ad0s1g   394M   602K   362M     0%    /tmp
/dev/ad0s1h    21G    12G   6.9G    64%    /usr
/dev/ad0s1e    98M   5.1M    85M     6%    /var

My sizing in this case is looking a bit dodgy now. I think I was over
zealous when laying out /tmp and /var, I could have allocated a fair bit
less and been fine. I have also started making a /pkg slice on some of
my machines where the ports database is kept. This can grow to being a
large file on systems with a lot of ports installed and this was causing
me all sorts of problems by filling up /var constantly. Once you create
the /pkg slive just set the PKG_DBDIR environment variable in
/etc/login.conf and all your users, including root most importantly
should use the new location instead of the classic /var/db/pkg. This
leaves /var to storing logs and mail as well as other useful files.

If you look at:
/dev/ad0s1h    21G    12G   6.9G    64%    /usr

dom at gallium:/home/dom# du -hs /usr/ftp/
 11G    /usr/ftp/

Disc space theif? :)

> Yes, I accept that probably I'll have to back the whole system up, but my
> preferred course would be to do this onto CDROM - once I finally arrive at
> a FreeBSD version where CDROM mounting works consistently on this machine -
> hopefully 4.5
> Many thanks for any help.
> CB
> ------ FreeBSD UK Users' Group  -  Mailing List ------
> http://listserver.uk.freebsd.org/mailman/listinfo/freebsd-users


More information about the Ukfreebsd mailing list