---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 272 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 peter.allan@aeat.co.uk (Peter M Allan) "D. Stew McLeod" foster@bial1.ucsd.edu rick@lunger.llnl.gov Rich Kulawiec Glenn Satchell - Uniq Professional Services ------- 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 //usr/platform/sun4m/lib/fs/ufs installboot bootblk /dev/rdsk/ - 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/ where 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 ;-) ---------- X-Sun-Data-Type: shell-script X-Sun-Data-Description: shell-script X-Sun-Data-Name: growfs X-Sun-Content-Lines: 79 #!/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 ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: growfs.1m X-Sun-Content-Lines: 127 .\" 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