On Wed, 23 Nov 2005, Steve Roder wrote:

> > Richard,
> >    Nothing in the error log.
> >
> > # bosboot -a -q
> >
> > Filesystem      KB required
> > /tmp            20582
> > # df -k |grep  /tmp
> > /dev/hd3           786432    608948   23%      134     1% /tmp

mmmm.....

The failing machine:
(4:06pm)[new-tsmserver1]{~}> ls -al /usr/bin/gzip
lrwxrwxrwx   1 root     system           26 Jul 27 14:53 /usr/bin/gzip ->
/usr/opt/freeware/bin/gzip
(4:06pm)[new-tsmserver1]{~}> ls -al /usr/bin/compress
-rwxr-xr-x   3 bin      bin           66303 Nov 20 2002  /usr/bin/compress

It could be in the shell, but what is strange is the working server has
the same link for gzip, but a very different compress:

4:11pm)[new-tsmserver2]{~}> ls -al /usr/bin/gzip
lrwxrwxrwx   1 root     system           26 Jul 27 08:13 /usr/bin/gzip ->
/usr/opt/freeware/bin/gzip
(4:11pm)[new-tsmserver2]{~}> ls -al /usr/bin/compress
-r-xr-xr-x   3 bin      bin           17498 Jul 27 08:09 /usr/bin/compress

They are at different ML levels (ML02 on the broken one, ML03 on the
working one), but the one that works did not have this issue on ML02.

By copying /usr/bin/compress from the working machine to the broken
machine, I was able to run bosboot -a.

So, the problem is fixed, but how did it get to this state?  IBM did the
AIX pre-installs.

thinking about a fresh reinstall......

:-)


>
> Here's the problem.  Notice how it complains it can't open
> /tmp/bosboot_67756_18272/unix_1704.Z?  If I do repeated ls's on that dir
> as the command runs, I see this:
>
> (3:43pm)[new-tsmserver1]{/tmp}> sudo ls -al bosboot*
> total 40616
> drwx------   2 root     system          512 Nov 23 15:42 .
> drwxrwxrwt  12 bin      bin            1536 Nov 23 15:42 ..
> -rw-r--r--   1 root     system      7660080 Nov 23 15:42 Bootram.fs
> -r-xr-xr-x   1 root     system     10485742 Nov 23 15:42 unix_1704
> -rw-------   1 root     system      2637824 Nov 23 15:43 unix_1704.gz
>
> and on the working server:
>
> (3:44pm)[new-tsmserver2]{/tmp}> sudo ls -al bosboot*
> total 23648
> drwx------   2 root     system          512 Nov 23 15:44 .
> drwxrwxrwt  11 bin      bin            2048 Nov 23 15:44 ..
> -rw-r--r--   1 root     system      7460981 Nov 23 15:44 Bootram.fs
> -r--------   1 root     system        12485 Nov 23 15:44 bootinfo.txt
> -rw-r--r--   1 root     system            0 Nov 23 15:44 dd.out
> -rw-r--r--   1 root     system          153 Nov 23 15:44 filesystems
> -rw-r--r--   1 root     system            0 Nov 23 15:44 mkboot.out
> -r-xr-xr-x   1 root     system      4614307 Nov 23 15:44 unix_3950.Z
>
> So, it's using gzip, but expecting compress?
>
> mmm....so, why the difference?  How does it decide what compression
> program to use?
>
> >
> >
> > Larry
> >
> >
> > Richard Sims writes:
> >
> > > On Nov 23, 2005, at 3:01 PM, Lawrence McMahon wrote:
> > >
> > >>    Yes, /tmp has space.
> > >> /dev/hd3           786432    608948   23%      134     1% /tmp
> > >
> > > Well, it has space at the time the 'df' command was issued; but it
> > > may have run out of space during an operation, and as part of
> > > operation recovery, the operation may have removed the partial work
> > > from /tmp.
> > >
> > > I would check the AIX Error Log, where AIX usually creates an entry
> > > (e.g., JFS_FS_FULL) when a file system has filled. Also try the
> > > bosboot -q option.
> > >
> > >    Richard Sims
> >
> >
> >
> > Lawrence McMahon
> > Senior Programmer Analyst
> > 341 Computing Center, North Campus
> > 645-3579
> >
> >
>
> Steve Roder
> University at Buffalo
> (spr AT buffalo DOT edu | (716)645-3564)
>
>

Steve Roder
University at Buffalo
(spr AT buffalo DOT edu | (716)645-3564)