SUMMARY: disk space problems with patches/upgrades

Stefan Voss (s.voss@terradata.de)
Tue, 25 Nov 1997 10:25:12 +0100 (MET)

--Boundary_(ID_rI2pZ2hLPYP6uEJfc/oFsw)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=text
Content-description: text
Content-disposition: ATTACHMENT; FILENAME=text

Hi,

thanks to all who replied. Some of you thought, that i will have no problem
with the patches, others did. The best idea came from Glenn Satchell,
who also included a script to grow the root partition and the corresponding
man page. These are included here as attachments for all who have the
same problem.

However, the machine needs to be runing day and night and over the weekend
as well, so i have cancelled the idea of patching it this year. Somewhen
in the next year, when i can get it for a night/weekend, i will install
2.5 on it. Then i can repartition the disk, as it's current layout looks
really weird.

BTW: one of my ideas was to move one of the directories from / to somehere
else, and as an example, i suggested /sbin. No good idea. Will cause great
trouble. /sbin needs to be on the root partition. It contains statically
linked programs, which are used before any other partition is mounted.

CONCLUSION:
-----------
As a conclusion, it might be possible to install all patches (maybe not
with install_cluster but manually one after the other). But then, one
should avoid saving previous versions (thus making it impossible to back
out the patches). Some files on the root partition can be removed or shrinked
(e.g. utmpx, wtmpx etc.) to supply more disk space, but important directories
(like /sbin) should NOT be moved to other locations. If the root partition
is followed by the swap partition, then it is possible to grow the root
and shrink the swap using growfs.

THE ANSWERS CAME FROM:
----------------------

casper@holland.Sun.COM
hargrme@wisdom.maf.nasa.gov
Ian TCollins <itc1@scigen.co.uk>
peter.allan@aeat.co.uk (Peter M Allan)
"D. Stew McLeod" <stewart.mcleod@boeing.com>
foster@bial1.ucsd.edu
rick@lunger.llnl.gov
Rich Kulawiec <rsk@itw.com>
Glenn Satchell - Uniq Professional Services <Glenn.Satchell@uniq.com.au>

-------

You have about 3MB left in /; patches don't take extra space in / generally,
as the files are replaced; only some patches add files and few cause
actual increases in file space; you need to have enough space to acoomodate
to copies of the largest file to be patched, however.

-------

try and install the patches one by one; if they won't install, then the
process will tell you.

You can remove /hsfsboot and /kadb (but patches include kadb, I think).
Remove packages you dont' use (device drivers for grahics you dont' have).

-------

You will run into problems with a small / partition. I would recommend doing:

- a ufsdump of the / and /usr partition.
- bootup from cdrom
- make the primary drive one partition.
- newfs the partition
- restore the backups i.e., ufsrestore on the one / partition
- install bootblock on the new / partition
cd /<newdisk>/usr/platform/sun4m/lib/fs/ufs
installboot bootblk /dev/rdsk/<newdisk root partition>
- bootup the system.

-------

Patches are uncompressed in /tmp. provided this is on its own partition,
patch install will whinge about lack of disk space, but still work.

-------

Have you got another machine like it on which you could prepare a disk and then
quickly swap them ? Buy a disk if you need to - you'll get to keep it anyway.

Try running the patch install without the option to save previous files
(installpatch -d). The negative part is that you will not be able to
back out of the patch.

-------

You can install patches with a smaller root. Once I got the same
message about / being too small, but it was a bug; it was really
complaining that /var didn't have enough space. This is where
most of the patch info goes, so you might try freeing some
space here. You can do a

cat /dev/null >! /var/adm/<filename>

where <filename> can be:

utmp
utmpx
wtmp
wtmpx

These files effect the who command and possibly others, so you might want
to get more info before you remove their contents. I regularly do this
without any bad consequences.

-------

I've been here before, there's no good clean fix. You need room in root,
the only way to get it (without a newfs) is to move something out and
sym link it. I don't know how a reboot will handle a symlink of something
like sbin to a filesystem that hasn't been mounted yet, it doesn't sound
good. Possibly you can move long enough to patch, then move back before
reboot.

You probably don't want to hear this but I think the best approach will
be to just schedule the upgrade. The filesystem map you are currently
using is a pretty old idea for a layout. I recommend something like the
following for a server:
/ 100MB
swap whatever
/usr 500MB
/var 200MB

This will fit cleanly on a 1GB disk, if you have a 2.1GB (probably do on
a SS1000) then bump the sizes up a bit, +20% I'm assuming things like
AnswerBooks will go somewhere else, like /export/... a different filesystem.

This is also a really good argument to use Veritas volume management, you
could move and grow things enough to get through this.

-------

Buy a bigger disk and throw it in an external enclosure; when you
have some downtime, copy the smaller disk to the larger one, then
put the patches in using the larger disk. Then pull the larger
disk out of the enclosure, the smaller disk out of the machine,
and swap them. (The smaller disk is now online as your emergency
backup should your upgrade/patches result in problems.)

Big disks are cheap. System admin time is not.

------------------------------------------------------------------------------

GLEN SATCHELL WROTE:
--------------------

You definitely need to increase the root partition size at some
stage...

What I would do is to extend the partition by stealing some space from
the beginning of the swap partition (assuming that it is partition 1).
Then use the attached growfs script (part of Solstice Disksuite, but it
doesn't need any other parts) to expand the filesystem into the new
space.

You can do this online if you're careful or you may prefer to boot into
single user mode.

- Turn off the primary swap partition, swap -d /dev/dsk/c0t3d0s1 (you
might need to temporarily add another swap partition if you use a lot
of virtual memory)

- run format and change the end of partition 0, change the beginning of
partition 1 to correspond. Make sure the end of partition 1 is the same
cylinder as before. Don't change anything else on that disk. Label the
disk and exit.

- You now have to reboot because the kernel caches the disks superblock
in memory and won't recognise the changes without rebooting.

- Run growfs -M / /dev/rdsk/c0t3d0s0 to expand the filesystem, use df
-k to check the new size.

I would suggest expanding root to be 50 megabytes to make sure you
don't have to go through this procedure again. You'll need a bigger
root to install Solaris 2.5 (or 2.6 or 2.7 by next year :-)

Alternatively, if you have a spare disk you could make that into a new
system disk. Partition that as required, ufsdump|ufsrestore from the
existing to the new, edit /etc/vfstab to change the old to the new
addresses and don't forget installboot. Then boot from that disk
instead of your old one.

------------------------------------------------------------------------------

ORIGINAL POSTING
----------------

Hi there,

i have a SparcServer 1000 running Solaris 2.4. First i want to install the
2.4 recommended patches, later (maybe next year) i want to upgrade the
machine to 2.5 or a higher version. So far, so good.

For a reason that i can't remember, my / partion is only 13 MB "large" and more
or less full:

Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c0t3d0s0 13143 11010 823 93% /

/var, /opt, /usr and /usr/openwin are mounted on their own partitions on the
same physical disk.

du -s reports the following:

0 vol
1 net
2 bin
2 export
2 lib
2 mnt
18 cdrom
56 tmp
62 devices
352 hsfsboot
352 ufsboot
768 kadb
2028 dev
3040 etc
7456 kernel
7646 sbin

>From a Solaris 2.5 patch installation, i know, that this procedure requires
at least 4 MB free space in several directories, including the root directory...

The machine is very important (of course, otherwise i would have no problem
with it), it is used at night and on the weekends, so if have not much time
to play around with it (like repartitioning the disk). This is, why i want to
do the upgrade as late as possible.

Unfortunately, we need the recommended patches to make a fast ethernet card
working...

My question(s): can i install the patches with this small root directory ?
And what about the upgrade ? If installing the patches is impossible with the
current configuration: can i move one of the above directories to a free
partition and link it to / (e.g. move /sbin to somewhere else) ? Or what
else ?

Any help (preferably quick and (un)dirty solutions) will be appreciated. A
summary will follow - even if it takes a while, this depends on the best
solution and on the work load of the server and on how cooperative my users
are ;-)

--Boundary_(ID_rI2pZ2hLPYP6uEJfc/oFsw)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=growfs
Content-description: shell-script
Content-disposition: ATTACHMENT; FILENAME=growfs
X-Sun-Data-type: shell-script

#!/bin/sh
#
#ident "@(#)growfs.sh 1.8 94/12/06 SMI"
#
# Copyright (c) 1992, 1993, 1994 by Sun Microsystems, Inc.
#

#exec newfs -G "$@"

myname=`basename $0`
USAGE="usage: $myname [ -M mount-point ] [ newfs-options ] raw-special-device"
if [ ! "$UFS_MKFS" ]; then
UFS_MKFS="/usr/lib/fs/ufs/mkfs"
fi
verbose=""
mkfs_opts="-G"
mkfs_subopts=""
size=""

add_opt() {
mkfs_opts="$mkfs_opts $1"
}

add_subopt() {
if [ ! "$mkfs_subopts" ]; then
mkfs_subopts="-o $1"
else
mkfs_subopts="$mkfs_subopts,$1"
fi
}

while getopts "GM:Nva:b:c:d:f:i:m:n:o:r:s:t:C:" c ; do
save=$OPTIND

case $c in
G) ;;
M) add_opt "-M $OPTARG" ;;
N) add_subopt "N" ;;
v) verbose="1" ;;
a) add_subopt "apc=$OPTARG" ;;
b) add_subopt "bsize=$OPTARG" ;;
c) add_subopt "cgsize=$OPTARG" ;;
d) add_subopt "gap=$OPTARG" ;;
f) add_subopt "fragsize=$OPTARG" ;;
i) add_subopt "nbpi=$OPTARG" ;;
m) add_subopt "free=$OPTARG" ;;
n) add_subopt "nrpos=$OPTARG" ;;
o) add_subopt "opt=$OPTARG" ;;
r) add_subopt "rpm=$OPTARG" ;;
s) size=$OPTARG ;;
t) add_subopt "ntrack=$OPTARG" ;;
C) add_subopt "maxcontig=$OPTARG" ;;
\?) echo $USAGE; exit 1 ;;
esac

OPTIND=$save
done

shift `expr $OPTIND - 1`
if [ $# -ne 1 ]; then
echo $USAGE
exit 1
fi
raw_special=$1

if [ ! "$size" ]; then
size=`devinfo -p $raw_special | awk '{ print $5 }'`
if [ $? -ne 0 -o ! "$size" ]; then
echo "$myname: cannot get partition size"
exit 2
fi
fi

if [ "$verbose" ]; then
echo $UFS_MKFS $mkfs_opts $mkfs_subopts $raw_special $size
fi

echo $UFS_MKFS $mkfs_opts $mkfs_subopts $raw_special $size
# exec $UFS_MKFS $mkfs_opts $mkfs_subopts $raw_special $size

--Boundary_(ID_rI2pZ2hLPYP6uEJfc/oFsw)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=growfs.1m
Content-description: default
Content-disposition: ATTACHMENT; FILENAME=growfs.1m
X-Sun-Data-type: default

.\" ident "@(#)growfs.1m 1.16 95/03/15 SMI"
.pn 257
.TH GROWFS 1M "06 October 1994"
.ds NN "Solstice DiskSuite
.ds NA DiskSuite
.SH NAME
growfs \- non-destructively expand a mounted file system
.SH SYNOPSIS
.B /usr/opt/SUNWmd/sbin/growfs
[
.B \-M
.I "directory-name"
]
[
.I "newfs-options"
]
.I "raw-special-device"
.sp
.SH AVAILABILITY
.LP
This program is available with the \*(NN software package (SUNWmd).
.sp
.SH DESCRIPTION
IX "growfs command" "" "\f(CWgrowfs\fP \(em grow file system"
.IX "file system" "grow growfs" "file system" "grow \(em \f(CWgrowfs\fP"
.LP
.B growfs
non-destructively expands a mounted or unmounted file system up to the size
of the file system's partition.
.B growfs
is a \*(lqfriendly\*(rq front-end to the
.BR mkfs (1M)
program.
.LP
This command is most often used after a metadevice has been expanded using
.BR metattach (1M).
.LP
.B growfs
will ``write-lock'' (see
.BR lockfs (1M))
a mounted file system when expanding. The length of time the file system is
write-locked can be shortened by expanding the file system in stages. For instance,
to expand a 1 Gbyte file system to 2 Gbytes, the file system can be grown in 16
Mbyte stages. To do this, use the
.B -s
option to specify the total size of the new file system at each stage. The
argument for
.B -s
is the number of sectors, and must be a multiple of the cylinder size.
.LP
Note that \fBgrowfs\fP displays the same information as
.BR mkfs (1M)
during the expansion of the file system. This is
normal behavior for
.BR growfs .
.LP
You must be super-user to use this command.
.LP
If \fBgrowfs\fP is aborted, the user can recover any lost free space by
unmounting the file system and running \fBfsck\fP(1M), or the user can issue the
\fBgrowfs\fP command again.
.sp
.SH OPTIONS
.LP
.TP
.BI -M " directory-name"
The file system to be expanded is mounted on \fIdirectory name\fP. File
system locking \&(\fBlockfs\fP) will be used.
.TP
.I "newfs-options"
The options are documented in the
.B newfs
man page.
.TP
.I "raw-special-device"
is the name of a raw special device residing in
.BR /dev ,
including the disk partition, where you want the file system to be grown.
.sp
.SH EXAMPLES
.LP
The following example verbosely displays the parameters
for the raw special device,
.BR /dev/rdsk/c0t1d0s0 ,
but does not actually expand the unmounted file system:
.LP
.if n \fB
.if t \f(CW
.nf
example% \ growfs \-vN /dev/rdsk/c0t1d0s0
mkfs \-G \-N /dev/rdsk/c0t1d0s0 16048 34 8 8192 1024 16 10 60 2048 t 0 -1
/dev/rdsk/c0t1d0s0: 16048 sectors in 59 cylinders of 8 tracks, 34 sectors
8.2Mb in 4 cyl groups (16 c/g, 2.23Mb/g, 896 i/g)
super-block backups (for fsck \-b#) at:
\ 32, 4432, 8832, 13232,
example%
.fi
.if n \fR
.if t \fR
.br
.ne 2.5i
.LP
The following example shows how \fBgrowfs\fP is used to expand the file system
.B /dev/rdsk/c0t2d0s0
mounted on
.B /var.
.if n \fB
.if t \f(CW
.nf
example% \ growfs \-M /var /dev/rdsk/c0t2d0s0
/dev/rdsk/c0t2d0s0: 16048 sectors in 59 cylinders of 8 tracks, 34 sectors
8.2Mb in 4 cyl groups (16 c/g, 2.23Mb/g, 896 i/g)
super-block backups (for fsck \-b#) at:
\ 32, 4432, 8832, 13232,
example%
.if n \fR
.if t \fR
.fi
.SH "SEE ALSO"
.BR fsck (1M),
.BR lockfs (1M),
.BR mkfs (1M),
.BR metattach (1M),
.BR newfs (1M),
.BR fs (5)
.LP
.I "\*(NN Administration Guide"

,,,
(o o)
--------------------------------o0Oo-(_)-oO0o---------------------------------

Stefan Voss Phone: # 49 (0) 5139-9908-51
Software & System Support Fax: # 49 (0) 5139-9908-10
TerraData Geophysical Services GmbH e-mail: s.voss@terradata.de
Ehlbeck 15 a
D - 30938 Burgwedel, Germany

--Boundary_(ID_rI2pZ2hLPYP6uEJfc/oFsw)--