Hi sun-managers!
I apologize for the extremely late followup / summary on this subject.
I do hope that this SUMMARY may be helpful to others. I'd like to thank
all of those who helped me (and soon, others) with their responses --
there were quite a few of them and they all came in promptly. I would
to thank everyone who provided more than a guess and who addressed the
questions directly and did not speculate or address non-issues. I would
like to especially thank Jon LaBadie and Casper Dik for quite a bit of
correct feedback containing correct information and very helpful
suggestions xthat allowed me to personally solve the problem, learn more
about Solaris and get on with things.
Scott
SUMMARY: The bottom line is that it appears that Solaris 7 uses hard
links to (a program) /usr/lib/isaexec to determine which "bitness" of a
binary to use. Specifically, "isaexec" apparently determines 32bit or
64bit operating mode and calls an appropriate program. This may be
similar to other hard links that are in use in Solaris 7 (ie:
/usr/bin/kill, et al.)
The following 35 programs are hard linked:
/usr/lib/isaexec /usr/bin/adb /usr/bin/kgmon /usr/bin/ps
/usr/bin/savecore /usr/bin/setuname /usr/bin/uptime /usr/bin/w
/usr/bin/ipcs /usr/bin/gcore /usr/bin/plimit /usr/bin/truss
/usr/bin/prex /usr/bin/tnfxtract /usr/sbin/crash /usr/sbin/lockstat
/usr/sbin/prtconf /usr/sbin/swap /usr/sbin/sysdef /usr/sbin/whodo
/usr/sbin/dmesg /usr/proc/bin/pcred /usr/proc/bin/pfiles
/usr/proc/bin/pflags /usr/proc/bin/pldd /usr/proc/bin/pmap
/usr/proc/bin/prun /usr/proc/bin/psig /usr/proc/bin/pstack
/usr/proc/bin/pstop /usr/proc/bin/ptime /usr/proc/bin/ptree
/usr/proc/bin/pwait /usr/proc/bin/pwdx /usr/ucb/ps
Depending on how any one of these programs is modified, there is a good
chance that the program /usr/lib/isaexec will be modified as well and
will not do what it was intended to do. This has the expected effect of
causing seemingly unpredictable results when any of the above programs
is referenced (ie: executed to perform a function).
For example, replacing /usr/bin/ps will affect /usr/bin/swap -- and
this, in turn, affects the boot process. I can report that the system
will still boot without a proper /usr/bin/isaexec -- but I'm not
suggesting that any of these programs be removed in an effort to save
space and help clear clutter! :-)
In case isaexec, itself, becomes corrupt, all that is necessary is to:
(1) erase each of the above programs, (2) replace /usr/lib/isaexec (from
another system or CD), and then (3) hard link the rest of the filenames
to /usr/lib/isaexec. There may additional work as well such as
replacing the "true" target program (such as /usr/bin/sparcv9/ps) and/or
rebooting.
Scott
------------------------------------------------------------------------------
The following is an edited list of some of the responses, in no
particular, order with a few comments from me. There is no real purpose
to read past this point but I'd like my comments to be in any archives
of this list. The basic issue that I would like to thank those who
addressed the questions directly and did not guess or speculate.
> From: mwang@ (Michael Wang)
> why do you need to replace /usr/bin/ps etc?
> hard link saves space.
It is not a question of "why" ... your reponse doesn't help nor does it
address my questions. Specifically, I asked:
(1) Can anyone explain why this is being done? What's the logic
behind this and is this the future of Solaris?
and
(2) Is one of these programs just happens to get replaced or modified,
what is necessary to make sure the rest of the programs that are hard
linked will work properly?
I hope my SUMMARY is sufficient to answer these two questions!
> From: john.hilger@
> This is due to the fact that Solaris can run in 64 bit mode or 32 bit
> mode. When your system boots up, it will perform a test to determine if
> the hardware supports 64 bit architecture and if so, it will run in 64 bit
> mode. If the hardware is not capable of running in 64 bit mode it will run
> in 32 bit mode. You can also set an eprom value to force a system to run
> in 32 bit mode if desired. The reason you have all of these links is due
> to the fact that some commands needed to be re-written for the 64 bit OS
> version of Solaris, particularly those that function at a low level (i.e.
> ps).
Yes, thank you. Now to address how to fix it (since isaexec wasn't
mentioned, more information still needs to be obtained).
> From: Roger Fujii <rmf@>
> my guess is that this is how they dynamically use the same executables
> on both 32 and 64 bit kernels. The routines that access the kernel
> *must* be done in the native size of the kernel, so this small wrapper
> program must figure out what size the kernel is and use the appropriate
> program.
> If you look in /usr/bin, you will find a sparcv7 directory and
> a sparcv9 directory (if you loaded the 64 bit stuff).
> > (2) Is one of these programs just happens to get replaced or modified,
> > what is necessary to make sure the rest of the programs that are hard
> > linked will work properly?
> you don't replace the thing in /usr/bin, but in /usr/bin/sparcv*
Thank you. Again, mostly complete, but no mention of isaexec?
> From: Nickolai Zeldovich <kolya@>
> Possibly because all these programs do similar things and they thought it
> would be nice to have a single setuid-root program which will then perform
> the appropriate task based on how it was called.
um, and possibly not...
> From: Jon LaBadie <jon@jgcomp.com>
> Hey, neato!! ps and swap are two of 35 links to a program only
> 5K in size.
> I did a little investigation. There is something called "ISA"
> dealing with the system architecture. Some programs include
> isainfo, isalist, and isaexec (the latter 1 of the 35 links).
> There is also a C library routine called isaexec(3C). ps and
> bretheren are merely interfaces to isaexec().
> I think the objective is to have architecture specific things
> replaced by common code that looks up the underlying architecture
> and calls the right specific code. That way, your sparc10,
> ultra2, e1000, 32bit and 64bit versions all have the same single
> version of ps installed in /usr/bin.
That's it. Thank you!
And this responder even found other hard links around the system
> There are also 29 links to /usr/bin/vax and 17 to /usr/bin/kill.
> These are not part of the ISA scheme I mentioned above.
> > center [6]> cd /usr/sbin
> > center [7]> ./swap
> > ps: can't find controlling terminal
> Let me guess, /proc is not mounted?
No. The original message stated the situation -- but your other
information was perfect!
> From: Casper Dik <casper@holland.Sun.COM>
> You shouldnt' have done that! What you've done now is killed
> /usr/lib/isaexec
> /usr/bin/ps and /usr/sbin/swap are programs that come in to versions:
> a 32 bit and a 64 bit version.
> The actuall executables live under /usr/bin/sparcv9 and /usr/bin/sparcv7.
> Isaexec is a switching program that will check what type of os you're
> running and execute the proper one.
Thanks Casper!
> You've just destroyed your system, I would think, or nearly.
Actually, it still boots... CDE runs, etc. Amazing that Solaris can
do this, isn't it?
Additionally:
> From: Casper Dik <casper@holland.Sun.COM>
> There isn't a primary program as far as Unix is concerned.
> However, there is one as far as Solaris installation is concerned:
> grep /usr/bin/ps /var/sadm/install/contents
> /usr/bin/ps=../../usr/lib/isaexec l none SUNWcsu
> There's also an easy way to fix this when you've reinstalled isaexec.
> "pkgchk -n -f" (well, run w/ -f first to see what's wrong)
> From: Steven Dodd <S.Dodd@leeds.ac.uk>
> How was it modified?
I'm not sure, exactly, other than it was either "cp" or "mv" to
overwrite the file. Whichever one was used, the net effect was that
all of the programs were pointing to the wrong program (ie: isaexec
had been changed, and all the programs were pointing to it... so, cp
was used?).
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:16 CDT