Is the a way to find 'X' in Solaris 10 update X ?
Dave
later, how can I do this? I know it's encoded in /etc/release
drkirkby@kestrel:[~] $ cat /etc/release
Solaris 10 10/08 s10s_u6wos_07b SPARC
Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 27 October 2008
with a 'u6' here indicating its update 6, but is there any way of doing
this in an unambiguous way on all Suns?
With the use of sed/awk/grep etc I could determine it on this particular
machine, but I would not have much confidence such a script would work
on any random Sun running any random update of Solaris 10.
--
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange' take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.
Richard B. Gilbert
> Assume I want to determine if a SPARC is running Solaris 10 update 4 or
> later, how can I do this? I know it's encoded in /etc/release
>
> drkirkby@kestrel:[~] $ cat /etc/release
> Solaris 10 10/08 s10s_u6wos_07b SPARC
> Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
> Use is subject to license terms.
> Assembled 27 October 2008
>
>
> with a 'u6' here indicating its update 6, but is there any way of doing
> this in an unambiguous way on all Suns?
>
>
> With the use of sed/awk/grep etc I could determine it on this particular
> machine, but I would not have much confidence such a script would work
> on any random Sun running any random update of Solaris 10.
>
sunburn_# cat /etc/release
Solaris 10 1/06 s10s_u1wos_19a SPARC
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 07 December 2005
sunblok_# cat /etc/release
Solaris 8 2/02 s28s_u7wos_08a SPARC
Copyright 2002 Sun Microsystems, Inc. All Rights Reserved.
Assembled 18 December 2001
I think that you should be able to rely on it for any version of Solaris
from the Solaris 8 above and all succeeding releases.
There is an excellent chance that Solaris 7, Solaris 6, etc. will do
likewise though I would like to test it before risking anything important.
Martin Paul
> Assume I want to determine if a SPARC is running Solaris 10 update 4 or
> later, how can I do this? I know it's encoded in /etc/release
I think this file is the only source for that information, and it's
probably the official way to do what you want:
http://developers.sun.com/solaris/articles/using_etc_release.html
The document lists all /etc/release files from Solaris 2.5.1 4/97 to
Solaris 9 Beta. Maybe you can ask the author to update it, too.
BTW, I was wondering whether an upgrade install would update
/etc/release as well - this document confirms that:
The purpose of the /etc/release file is to determine easily the base
OS level or the OS release the system was upgraded to.
hth,
Martin.
--
SysAdmin | Institute of Scientific Computing, University of Vienna
PCA | Analyze, download and install patches for Solaris
| http://www.par.univie.ac.at/solaris/pca/
John D Groenveld
>Assume I want to determine if a SPARC is running Solaris 10 update 4 or
>later, how can I do this? I know it's encoded in /etc/release
For what purpose are you trying obtain the specific S10 release
installed?
If its for application compatibility, then you should be looking
at packages and patches.
John
groe...@acm.org
Dave
> Dave wrote:
>> Assume I want to determine if a SPARC is running Solaris 10 update 4
>> or later, how can I do this? I know it's encoded in /etc/release
>
> I think this file is the only source for that information, and it's
> probably the official way to do what you want:
>
> http://developers.sun.com/solaris/articles/using_etc_release.html
>
> The document lists all /etc/release files from Solaris 2.5.1 4/97 to
> Solaris 9 Beta. Maybe you can ask the author to update it, too.
>
> BTW, I was wondering whether an upgrade install would update
> /etc/release as well - this document confirms that:
>
> The purpose of the /etc/release file is to determine easily the base
> OS level or the OS release the system was upgraded to.
>
> hth,
>
> Martin.
Thank you Martin,
Looking at that link, there is no consistency in how /etc/release is
written. Lines include:
Manufactured in the USA 16 April 1997
Assembled 06 October 1998
Solaris 2.6 Maintenance Update 2, Assembled April 1998
Solaris 8 Maintenance Update 1 applied
Without some consistency, it makes parsing /etc/release almost
impossible. One would need some sort of artificial intelligence application!
My reason for wanting this is that I intend building some binaries for
the open-source mathematics program Sage:
This will possibly be done on a Solaris 10 update 1 Blade 2500, but
perhaps on a T5240 running Solaris 10 update 4. When Sage was run, I
wanted to check the release of Solaris being used is no older than what
the binaries were built on.
I guess the ideal solution would be to install the very first release of
Solaris 10 and build the binaries on that. I do have an Ultra 60 or
Ultra 80 lying around doing nothing useful, which could be pressed into
service, though building on one of those machine would take several days.
Rich Teer
> My reason for wanting this is that I intend building some binaries for the
> open-source mathematics program Sage:
>
> http://www.sagemath.org/
>
> This will possibly be done on a Solaris 10 update 1 Blade 2500, but perhaps on
> a T5240 running Solaris 10 update 4. When Sage was run, I wanted to check the
> release of Solaris being used is no older than what the binaries were built
> on.
OK. In that case, if I were you I'd simply document the fact that used Solaris 10
Update 1 to build your stuff, and that the end user must be using that version or
something newer. (To be extra friendly you can tell them how to check /etc/release.)
Much (all?) software these days has a minimum OS requirement documented somewhere,
so I don't hink it's unreasonable for you to take that approach too.
--
Rich Teer, SCSA, SCNA, SCSECA
URLs: http://www.rite-group.com/rich
http://www.linkedin.com/in/richteer
Sami Ketola
> This will possibly be done on a Solaris 10 update 1 Blade 2500, but
> perhaps on a T5240 running Solaris 10 update 4. When Sage was run, I
> wanted to check the release of Solaris being used is no older than what
> the binaries were built on.
>
> I guess the ideal solution would be to install the very first release of
> Solaris 10 and build the binaries on that. I do have an Ultra 60 or
> Ultra 80 lying around doing nothing useful, which could be pressed into
> service, though building on one of those machine would take several days.
Unless there is something in your application that really needs Solaris 10
the ideal solution would be to compile it on Solaris 8. That would make
it work on all less than 10 year old Solaris releases.
If you don't have spare system to run Solaris 8 for the compilation process
you can always run Solaris 8 on a Solaris 10 zone.
Sami
--
.signature: no such file or directory
ThanksButNo
Nonsense! Your worst case is a long string of "if-then-else"
statements, which might be ugly, but certainly easy. There's
only a few dozen possibilities to test for. But it's really
even easier than that:
The first line always starts with "Solaris VERSION" and the
assembly/manufacture date is always the last three tokens on the
third line (Day Month Year). If there is a fourth line, it means
it's a maintenance update, which means bug-fix so you can probably
ignore it. But if not, just scan for "Update N".
This good up to Solaris 10, where the assembly/manufacture date
is on the fourth line instead, because the third line is always
"Use is subject to license terms".
And believe me, if somebody as naturally stupid as me can
figure this out, it certainly wouldn't need any artificial
intelligence!
:-)
Michael Laajanen
Solaris 6, whats that?
/michael
Richard B. Gilbert
6 comes after 5 and before 7! I know that Sun changed the numbering
scheme in an incompatible way somewhere in there but I came on board
late enough that Solaris 8 was current although our antique PCs were
running a really antique version (2.6????). Sorry I don't remember the
details but they weren't and still aren't very important to me. My job,
at the time (2003), was installing Solaris 8 and a typesetting
application on new PCs and replacing the antique hardware/software with
new. Solaris 2.6 or whatever the junk had been running hit the dumpster
along with the hardware!
Tim Bradshaw
> Without some consistency, it makes parsing /etc/release almost
> impossible. One would need some sort of artificial intelligence application!
Fortunately there are a finite, small, and known set of these files,
so a simple case statement will suffice.
Tim Bradshaw
> This will possibly be done on a Solaris 10 update 1 Blade 2500, but
> perhaps on a T5240 running Solaris 10 update 4. When Sage was run, I
> wanted to check the release of Solaris being used is no older than what
> the binaries were built on.
>
Then looking at the release file won't help. You need to look at
patch levels.
Dave
I assume it would also change if you installed a French, German or
whatever else version of Solaris. It would be useful if there was a
system call to get this sort of information.
Casper H.S. Dik
>Tim Bradshaw wrote:
>> On 9 June, 09:50, Dave <f...@coo.com> wrote:
>>
>>> Without some consistency, it makes parsing /etc/release almost
>>> impossible. One would need some sort of artificial intelligence application!
>>
>> Fortunately there are a finite, small, and known set of these files,
>> so a simple case statement will suffice.
>I assume it would also change if you installed a French, German or
>whatever else version of Solaris. It would be useful if there was a
>system call to get this sort of information.
I'm not sure that is true; we only ship one version of Solaris and
each Solaris contains messages for many languages. I don't think we
have multiple /etc/release files in each release.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Dave
> On Tue, 9 Jun 2009, Dave wrote:
>
>> My reason for wanting this is that I intend building some binaries for the
>> open-source mathematics program Sage:
>>
>> http://www.sagemath.org/
>>
>> This will possibly be done on a Solaris 10 update 1 Blade 2500, but perhaps on
>> a T5240 running Solaris 10 update 4. When Sage was run, I wanted to check the
>> release of Solaris being used is no older than what the binaries were built
>> on.
>
> OK. In that case, if I were you I'd simply document the fact that used Solaris 10
> Update 1 to build your stuff, and that the end user must be using that version or
> something newer. (To be extra friendly you can tell them how to check /etc/release.)
> Much (all?) software these days has a minimum OS requirement documented somewhere,
> so I don't hink it's unreasonable for you to take that approach too.
>
Yes, that is probably the approach I will take. I just wanted to be
safe, as potentially someone could use the program on the wrong version
of the OS and get incorrect results from a maths program.
I might consider setting up a machine with the first release of Solaris
10. Then I could give a "Solaris 10 binary" which works all Solaris 10
systems.
In fact, I would not mind trying it on Solaris 9. I'm not sure if that
shipped with gcc/gas/gld in /usr/sfw/bin, which is about all I need. The
program will not build with an old gcc, but I used that to build gmp,
mpfr libraries, then the latest gcc (4.4.0).
Don't even suggest using Sun's compiler!! I'd love it to work with that,
but Sage make uses of about 100 different open-source packages, many of
which have GNUisms.
Richard B. Gilbert
I'd suggest using Solaris 9 or even Solaris 8 for the build if you do
not require features available only in the latest release. Many sites
may have valid reasons for running an older release of Solaris. If you
build with Solaris 8, your product should run on Solaris 8, 9, 10. . . .
Those three releases cover the last eight to ten years and probably
90+% of all Solaris users.