home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / unix / aix / 12748 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  3.8 KB
  1. Path: sparky!uunet!olivea!spool.mu.edu!agate!stanford.edu!rutgers!concert!uvaarpa!murdoch!holmes.acc.Virginia.EDU!op
  2. From: op@holmes.acc.Virginia.EDU (Olaf  Pors)
  3. Newsgroups: comp.unix.aix
  4. Subject: hd3 outside of rootvg is bad news
  5. Message-ID: <1992Dec21.145716.7122@murdoch.acc.Virginia.EDU>
  6. Date: 21 Dec 92 14:57:16 GMT
  7. Sender: usenet@murdoch.acc.Virginia.EDU
  8. Organization: University of Virginia
  9. Lines: 84
  10. Originator: op@holmes.acc.Virginia.EDU
  11.  
  12.  
  13.   For those of you who are concerned about backups, the
  14. following is a public service announcement to my fellow
  15. system administrators.
  16.  
  17.   Make sure that /dev/hd3 (/tmp) exists and that it
  18. resides within the root volume group!
  19.  
  20.   People have good reasons for wanting to move hd3 out of
  21. rootvg.  From the standpoint of disk hardware maintenance,
  22. it is best to have one volume group per disk.  If a disk
  23. fails, only that volume group is affected.  If more than
  24. one disk is part of a volume group, you would probably
  25. have to restore all the files on both disks if one of the
  26. disks fails.  Also, smit backs up all of /tmp along with
  27. rootvg.  Therefore, if a huge (1 Gb) /tmp is needed, it
  28. makes a lot of sense to move it into another volume
  29. group.  Unfortunately, if you subsequently do a smit
  30. "backup the system" on a 3.2.2 system, the backup
  31. completes normally, but you'll have problems trying to
  32. restore from it.
  33.  
  34.   At the time of the backup, the /.fs.size file written
  35. does not contain a /dev/hd3 entry, since hd3 is not part
  36. of rootvg.  At the time of the restore, /dev/hd3 is
  37. consequently not created.  After all files have been
  38. restored, /usr/lpp/bosinst/bosmain does an explicit
  39.  
  40.    mount /dev/hd3 /tmp
  41.  
  42. which fails but bosmain continues.  If the /tmp in hd4 is
  43. not large enough to contain the boot logical volume
  44. images, a "bosboot -a -d device" failure then stops
  45. everything.  You'll see the following messages:
  46.  
  47.   Copying ODM from RAM to hard disk...
  48.   mount: /dev/hd3 on /tmp: No such file or directory
  49.   Updating database with names of dynamically created special files...
  50.   Could NOT retrieve device configuration from previous system
  51.   Initializing boot logical volume for subsequent boots...
  52.   bosboot: not enough file space to create:
  53.      /tmp/disk.image
  54.      /tmp has 4808 free blocks
  55.      /tmp/disk.image needs 7360 blocks
  56.  
  57.   At this point, you may get into a maintenance shell and
  58. either (1) link /tmp into a filesystem with more room
  59. (e.g. /usr):
  60.  
  61.      mkdir /usr/tmp1
  62.      rmdir /tmp
  63.      ln -s /usr/tmp1 /tmp
  64.  
  65. or (2) somehow get hold of or make a /tmp on another
  66. disk.  Do NOT hit control-C at any time in the maintenance
  67. shell - this will abort bosmain, resulting in an "INIT:
  68. SINGLE USER MODE" message (another previously-reported
  69. problem).  In either case 1 or 2, you must manually retype
  70. the bosboot command for which you must guess at the proper
  71. "device" parameter; e.g.  /dev/hdisk0.  The hdiskxx names
  72. are assigned dynamically during configuration, and so are
  73. not guaranteed to be what you think.  If you do get
  74. bosboot to finish successfully, you still lose some
  75. configuration information (hostname, IP address, etc).
  76.  
  77.   I discovered these problems during a simulated disaster
  78. situation, and the IBM folks in Richmond kindly gave me
  79. the commands for workaround (2).  But my hd3's are moving
  80. back into rootvg as soon as possible!  IBM is discouraging
  81. the "hd3 outside of rootvg" configuration.  This leaves
  82. two unresolved, but non-critical, problems:
  83.  
  84. 1. If the /tmp disk fails, you can replace the disk but you'll
  85.    probably have to restore rootvg from backup (consider, for
  86.    example, adding a logical partition to /usr which just
  87.    happens to be selected from the disk that /tmp is on).
  88.  
  89. 2. "Backup the system" backs up /tmp, so all the trash in
  90.    a huge /tmp will wind up on the backup tapes.
  91.  
  92. Olaf Pors
  93. Academic Computing Center
  94. University of Virginia
  95. op@Virginia.EDU
  96.