From: op@holmes.acc.Virginia.EDU (Olaf  Pors)
Newsgroups: comp.unix.aix
Subject: hd3 outside of rootvg is bad news
Date: 21 Dec 92 14:57:16 GMT
Organization: University of Virginia
Originator: op@holmes.acc.Virginia.EDU


  For those of you who are concerned about backups, the
following is a public service announcement to my fellow
system administrators.

  Make sure that /dev/hd3 (/tmp) exists and that it
resides within the root volume group!

  People have good reasons for wanting to move hd3 out of
rootvg.  From the standpoint of disk hardware maintenance,
it is best to have one volume group per disk.  If a disk
fails, only that volume group is affected.  If more than
one disk is part of a volume group, you would probably
have to restore all the files on both disks if one of the
disks fails.  Also, smit backs up all of /tmp along with
rootvg.  Therefore, if a huge (1 Gb) /tmp is needed, it
makes a lot of sense to move it into another volume
group.  Unfortunately, if you subsequently do a smit
"backup the system" on a 3.2.2 system, the backup
completes normally, but you'll have problems trying to
restore from it.

  At the time of the backup, the /.fs.size file written
does not contain a /dev/hd3 entry, since hd3 is not part
of rootvg.  At the time of the restore, /dev/hd3 is
consequently not created.  After all files have been
restored, /usr/lpp/bosinst/bosmain does an explicit

   mount /dev/hd3 /tmp

which fails but bosmain continues.  If the /tmp in hd4 is
not large enough to contain the boot logical volume
images, a "bosboot -a -d device" failure then stops
everything.  You'll see the following messages:

  Copying ODM from RAM to hard disk...
  mount: /dev/hd3 on /tmp: No such file or directory
  Updating database with names of dynamically created special files...
  Could NOT retrieve device configuration from previous system
  Initializing boot logical volume for subsequent boots...
  bosboot: not enough file space to create:
     /tmp/disk.image
     /tmp has 4808 free blocks
     /tmp/disk.image needs 7360 blocks

  At this point, you may get into a maintenance shell and
either (1) link /tmp into a filesystem with more room
(e.g. /usr):

     mkdir /usr/tmp1
     rmdir /tmp
     ln -s /usr/tmp1 /tmp

or (2) somehow get hold of or make a /tmp on another
disk.  Do NOT hit control-C at any time in the maintenance
shell - this will abort bosmain, resulting in an "INIT:
SINGLE USER MODE" message (another previously-reported
problem).  In either case 1 or 2, you must manually retype
the bosboot command for which you must guess at the proper
"device" parameter; e.g.  /dev/hdisk0.  The hdiskxx names
are assigned dynamically during configuration, and so are
not guaranteed to be what you think.  If you do get
bosboot to finish successfully, you still lose some
configuration information (hostname, IP address, etc).

  I discovered these problems during a simulated disaster
situation, and the IBM folks in Richmond kindly gave me
the commands for workaround (2).  But my hd3's are moving
back into rootvg as soon as possible!  IBM is discouraging
the "hd3 outside of rootvg" configuration.  This leaves
two unresolved, but non-critical, problems:

1. If the /tmp disk fails, you can replace the disk but you'll
   probably have to restore rootvg from backup (consider, for
   example, adding a logical partition to /usr which just
   happens to be selected from the disk that /tmp is on).

2. "Backup the system" backs up /tmp, so all the trash in
   a huge /tmp will wind up on the backup tapes.

Olaf Pors
Academic Computing Center
University of Virginia
op@Virginia.EDU
Newsgroups: comp.unix.aix