I got very quick and very good responses to my request for help in
determining why attempting to restore my /usr partition was resulting
in "root full" error messages. Thanks to all who replied!
The cause is simply that the mini-root, which is a fixed size, is too
small for restoring large partitions. (The /tmp directory is being
used during the restore process.)
The simplest solution is to simply delete /vmunix after booting the
mini-root. That frees up about 1.5MB of space. (Since you've already
booted, /vmunix isn't needed anymore.) This is also apparently the
solution with the official Sun "okey-dokey" seal. :-) I used this
one, and it worked fine.
Another commonly-suggested solution was to mount another partition
(eg. your real root partition) over /tmp. That should provide plenty
of space for /tmp during the restore. I didn't try it, but several
people told me it works and restore does clean up after itself, so
you won't have any files littering your root partition when you're
done.
Several people suggested that I might have forgotten either to mount
the partition or to cd to that directory before I began the restore.
Although this wasn't the case, they are good things to check first!
Here is my original query:
>
>In attempting to restore the /usr partition, I received an error message
>reporting that the root partition was full. Since I was booted off of
>the mini-root partition, the message presumably was referring to the
>mini-root partition rather than the true root partition.
>
>I'm not sure why the mini-root partition would become full when attempting
>a restore and I'm even less sure what to do about it. Would increasing the
>size of the swap partition result in a larger mini-root partition? I'm
>currently running with a 60MB swap partition.
>
>I even tried invoking restore interactively, but still received the error
>message. It apparently is running out of space while attempting to
>extract the table of contents of the backup tape.
>
>This system is a Sun SPARCstation 10 running Solaris 1.1 with 32MB RAM.
>
Thanks to all those who replied!
538280000-Reidinger <columba!wpr@aluxpo.att.com>
B C Hamshere <B.C.Hamshere@newcastle.ac.uk>
Benjamin Zwittnig <Benjamin.Zwittnig@arnes.si>
Bernhard Ross <ross@era_lab>
Bonnie Lucas <lucas@Nadn.NAVY.MIL>
Claus Assmann <ca@informatik.uni-kiel.de>
Dave Mitchell <D.Mitchell@dcs.shef.ac.uk>
David B. Brown <dbrown@lizzard.med.utah.edu>
Gary Richardson <Gary.Richardson@proteon.com>
Gene Loriot <epl@Kodak.COM>
Glenn Satchell - Uniq Professional Services <glenn@uniq.com.au>
Gregory Bond <gnb@bby.com.au>
Ian MacPhedran <Ian_MacPhedran@engr.usask.ca>
<janaka@ee.pdx.edu>
Janet Ulrich <ju@compwr.com>
Jay Lessert <jayl@lattice.com>
John Benjamins <johnb@blas.cis.McMaster.CA>
Ken Erickson <Kenneth.Erickson@Eng.Sun.COM>
Peter.Samuel@nms.otc.com.au (Peter Samuel)
Ray Brownrigg <Ray.Brownrigg@isor.vuw.ac.nz>
Reggie Beavers - UNIX Sys Admin <reggie.beavers@sfwmd.gov>
Reggie Dugard <reggie@rentec.com>
Richard J. Niziak <rickn@hammerhead.copley.com>
Robert D. Worsham <worsham@aer.com>
Robert Wolf <rwolf@dciem.dnd.ca>
Salvatore Saieva <merccap!saieva@uunet.uu.net>
Schwarze <Peter.Schwarze@oi54.kwu.siemens.de>
Steve_Kilbane <steve@cegelecproj.co.uk>
Sue Rodger- IP Administrator <rodger@nic.tdcnet.ca.gov>
Sven Maurmann <sven@mpim-bonn.mpg.de>
Taft Metcalf <daVinci!metcalf@cygnusx1>
Timothy G Smith - Special Projects <tgsmith@Sun.COM>
Tom Orban <orban@advtech.uswest.com>
Tony Sunman <mi029@macaulay-land-use.scot-agric-res-inst.ac.uk>
Wally Hartshorn, System Administrator and GIS Analyst
email: wallyh@adm-is.epa.state.il.us
snail: Illinois EPA, 1340 N. 9th St., #9, Springfield, IL 62702
phone: (217) 785-6882 fax: (217) 524-6970
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:14 CDT