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)
|