The SAR saga continues

The SAR saga continues

Post by Lucky Leavel » Wed, 16 Aug 1995 04:00:00



Update on continuing efforts to coax sar on OSR5 to speak to me again:

Based on recent postings by Bela and Charlie, I attempted the following:

        1.  Checked /etc/ps/booted.kernel - it did not exist, so

        2. Ran kernel -uv to recreate it; it errored out with

                kernel: booted inode 4294936250 is not unix
                kernel: booted inode 4294936250 is not unix
                kernel: cannot stat hd(40)unix: no such file or directory
                                                (error 2)

        3.  Tried putting /usr/lib/sa/sar_enable -y in P21perf in /etc/rc2.d
                and rebooted.  Got the same error:

                sar_enable already enabled
                kernel check failed, kernel = (null), code = (Unknown)

Any ideas?          
Lucky

Lucky Leavell                            Phone: (812) 945-6555
Relational Information Systems, Inc.       FAX: (812) 949-9233

New Albany, IN 47150-2013                       71534,2674 (CompuServe)
                                 WWW Home Page:  http://wl.iglou.com/ris

 
 
 

The SAR saga continues

Post by Lucky Leavel » Wed, 16 Aug 1995 04:00:00


Just a brief public posting to state that my sar is working again!

In the wee small hours this morning, MEGO and all, I noticed the
date/time stamp for /unix was older than it should have been.  I forced
the kernel to relink, rebooted and ... <drum roll> ... sar worked!  Don't
ask me why, it just does!

I did follow Bela and Charlie's suggestions first, so perhaps that did it!

A happy camper,
Lucky

Lucky Leavell                            Phone: (812) 945-6555
Relational Information Systems, Inc.       FAX: (812) 949-9233

New Albany, IN 47150-2013                       71534,2674 (CompuServe)
                                 WWW Home Page:  http://wl.iglou.com/ris

 
 
 

The SAR saga continues

Post by jlath.. » Wed, 16 Aug 1995 04:00:00


I had a similar problem when I upgraded to OSR5.

I solved it by copying the origional boot file from out in the /var directory
structure to its proper place for booting.

I then rebuilt my kernel and rebooted.

After this the sar_enable -y command worked just fine.

Hope this helps.

 
 
 

The SAR saga continues

Post by Bela Lubki » Thu, 17 Aug 1995 04:00:00


Quote:> I had a similar problem when I upgraded to OSR5.

> I solved it by copying the origional boot file from out in the /var directory
> structure to its proper place for booting.

> I then rebuilt my kernel and rebooted.

> After this the sar_enable -y command worked just fine.

The problem is caused by a bug in /boot.  If the kernel's inode number
is >32767, it gets improperly sign extended to 32 bits, which confuses
kernel(ADM) and thus sar(ADM).  The problem only happens on systems with
a combined boot/root filesystem; a fresh install of OpenServer Release 5
uses a separate /stand (/dev/boot) filesystem which has only a few files
and therefore uses only very small inode numbers.

You corrected the problem by relinking the kernel, which happened to get
written with an inode number <32768.  Next time you relink it might come
back.  The same effect could have been achieved by copying /unix over an
existing file with a low inode number (cat /unix > some-other-file),
then renaming it to /unix.

I'm working on a more permanent fix.  Would people who are currently
experiencing the problem please email me directly, and *do not* apply
the workaround I've outlined above.  I need an unspoiled test bed or two
to experiment with.

Quote:>Bela<

 
 
 

1. The Networking Saga Continues...

All,

Ok, its not RedHat 5.0, PPP or DIALD thats causing the
crabs but IPAUTOFW.  I use IP_AUTOFW to allow my Win95
LAN users (ie. my wife, Theresa ;) to be able to communicate
to the outside world using ICQ and SpeakFreely.

[No, I am not going to try to force her onto Linux as
her sole system,  thank you.]

It seems (to me) that the ephemeral ports being allocated
by Linux are initially less than the start of the ip forward
block, but after some time, the port numbers ratchet up to
this range.  It seems that when this happens, the connect
library call times-out with no client socket.  I have not
tested this by writing a client application (which I will
do - wheres Stevens?) but by disabling the IP_AUTOFW,
telnet's and TCP's start working again.  Also using strace
allows me to confirm that the ephemeral port number is
indeed in the IP_AUTOFW block.

Does anyone know definitively if this is the case?  Can it
be remedied by NOT hacking at the kernel?

Bruce McDonald.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i

mQCNAzRkEEYAAAEEALDHLCpZ0iXz3fmlQNncUvhR1LtpBfhq7yNvVunV/2LlZnPH
2xu8E459JSwXNvruKPGbPS7QAqP6WXaYL0kLSzAKRnaJlzs53n4IRHfkc7ycKHcb
EUQxdZ2EyGLt80voGUO8uNH/gpBJkHhHU2g4h+URxfRlQ4n5QvzDGlDoSrYhAAUR
tC1CcnVjZSBKLiBNY0RvbmFsZCA8YnJ1Y2VtY2RAYmVsbGF0bGFudGljLm5ldD6J
AJUDBRA0ZkGo/MMaUOhKtiEBAetEA/9+wZR3S+3STLbOL2A6IdmF6q00ilj49tzK
Ge9xfsMthUyIWF+BgZf5ZYzyXIH2eQhRFj0TlGTpQd+37sTvh2UGQKAwpG6IWXRw
onQvG507FJ6RcYLCou/L6odaUHlR449chu/C8WmUvuPZa6VZNZgI7N79p4dCgdN6
yIZRdBpZBLQoQnJ1Y2UgSi4gTWNEb25hbGQgPGJydWNlbWNkQGhvdG1haWwuY29t
PokAlQMFEDRkEEb8wxpQ6Eq2IQEBCWMD+wbJ8LQcoJAcFDQEQYjsuLUnXrPU3Fev
J72JzGhNdYK4o8VdQ+L3CWDR8FxgY7u/3Fm+rQWcQm2xnrc/Nw/CfHqJ2bckZmNX
8lY+nA2BPyQNTeHR0yDXoQN7qBMer9svm2Gva3s0QI4HWxrGSLj3uqPvXg583k3/
Be45CPEmVVxy
=xkor
-----END PGP PUBLIC KEY BLOCK-----

2. Q: SENDMAIL

3. Installing xfce: the saga continues (or I'm too stupid for Linux)

4. Banshee Server Installation

5. The PPP Saga Continues

6. time limit on commands?

7. PS/2 mouse: Day 2, the Saga continues ... please help!

8. Any one that know when

9. HA... the saga continues (found a binary)

10. RH6.0 installs, but won't boot - saga continues

11. The Mosaic saga continues ....

12. RH 7.2 kernel recompile problems - the saga continues...

13. Linux Password Saga Continues