1． 查看系统的指令集架构
Isainfo：
The isainfo utility is used to identify various attributes of the instruction set architectures supported on the currently running system. Among the questions it can answer are whether 64-bit applications are supported, or whether the running kernel uses 32-bit or 64-bit device drivers.
When invoked with no options, isainfo prints the names of the native instruction sets for applications supported by the current version of the operating system. These are a subset of the list returned by isalist(1). The subset corresponds to the basic applications environments supported by the currently running system.
prtdiag -v will show the CPU type amd other system info, see the prtdiag man page.
# prtdiag -v
System Configuration:
BIOS Configuration: Award Software International, Inc. F5 01/30/2007
==== Processor Sockets ====================================
Version Location Tag
-------------------------------- --------------------------
AMD Athlon(tm) 64 Processor 3200+ Socket M2
==== Memory Device Sockets ================================
.
.
.
2． OpenSolaris ON的debug和non-debug区别
1）What's the difference?
Debug bits are compiled with DEBUG defined (-DDEBUG on cc cmdline etc).
So any code that is bracketed by a #ifdef DEBUG ... #endif becomes
active. This brings additional levels of debug and checking to
life, eg in the sample code:
#ifdef DEBUG
static void
check_for_cycles(struct fooey *fp)
{
...
}
#endif
int
foo(struct fooey *fp)
{
ASSERT(fp && fp->foo_type == FOO_TYPE1);
...
#ifdef DEBUG
check_for_cycles(fp);
#endif
...
}
The ASSERT code will be compiled if compiled with DEBUG; if not
it will disappear at preprocessing because the definition of
ASSERT changes depending on whether DEBUG is defined or not.
The second bit illustrates one of the reasons that a DEBUG kernel/system
is much slower. Instead of a simple invariant check as in the
assertion this will perform additional work such as verifying the
contents and structure of a linked list. Many debug options
are enabled with DEBUG, such as kmem_flags to perform redzone
violation checking etc - all good for debug and verification,
but at a cost to performance.
2）When using the debug ON, what messages can I get?
A few more during boot that aren't interesting. Thereafter, since
there are more checks. potentially new whinges and panics if
inconsistencies are found.
3） How can I build a non-debug ON? just use the non-debug on-closed-bins?
If using bldenv the default is non-debug; use the -d flag for debug.
If using nightly then change NIGHTLY_OPTIONS to select debug + non-debug,
debug only, or non-debug only. From the nightly usage message:
/opt/onbld/bin/nightly -?
/opt/onbld/bin/nightly[1035]: getopts: ? bad option(s)
Usage: nightly [-in] [-V VERS ] [ - S E|D|H|O ] <env_file>
Where:
-i Fast incremental options (no clobber, lint, check)
-n Do not do a bringover
-V VERS set the build version string to VERS
-S Build a variant of the source product
E - build exportable source
D - build domestic source (exportable + crypt)
H - build hybrid source (binaries + deleted source)
O - build (only) open source
<env_file> file in Bourne shell syntax that sets and exports
variables that configure the operation of this script and many of
the scripts this one calls. If <env_file> does not exist,
it will be looked for in $OPTHOME/onbld/env.
non-DEBUG is the default build type. Build options can be set in the
NIGHTLY_OPTIONS variable in the <env_file> as follows:
-A check for ABI differences in .so files
-C check for cstyle/hdrchk errors
-D do a build with DEBUG on
-F do _not_ do a non-DEBUG build
-G gate keeper default group of options (-au)
-I integration engineer default group of options (-ampu)
-M do not run pmodes (safe file permission checker)
-N do not run protocmp
-O generate OpenSolaris deliverables
-R default group of options for building a release (-mp)
-U update proto area in the parent
-V VERS set the build version string to VERS
-X copy x86 IHV proto area
-a create cpio archives
-f find unreferenced files
-i do an incremental build (no "make clobber")
-l do "make lint" in $LINTDIRS (default: $SRC y)
-m send mail to $MAILTO at end of build
-n do not do a bringover
-o build using root privileges to set OWNER/GROUP (old style)
-p create packages
-r check ELF runtime attributes in the proto area
-t build and use the tools in $SRC/tools
-u update proto_list_$MACH and friends in the parent workspace;
when used with -f, also build an unrefmaster.out in the parent
-w report on differences between previous and current proto areas
-z compress cpio archives with gzip
-W Do not report warnings (freeware gate ONLY)
-S Build a variant of the source product
E - build exportable source
D - build domestic source (exportable + crypt)
H - build hybrid source (binaries + deleted source)
O - build (only) open source
You'll have to pair them with the apporopriate debug or non-debug closed
bits.
4) How can I determine whether the ON is a debug version or not?
While booted, you can check for existence of variables declared only if
DEBUG is set on.
You can use the following command:
/usr/ccs/bin/nm /dev/ksyms | grep <variable-you-want-to-check>
Using mdb, you can also check the value of variables which are different
depending on DEBUG. For example, kmem_flags is set to 0 when DEBUG is
not set, and to 0xF when DEBUG is set.
# mdb -k
Loading modules: [...]
> kmem_flags/D
kmem_flags:
kmem_flags: 0
3. What CPU run 64 bit kernel OpenSolaris?
The install kernel is always 32bit regardless of what the machine can actually do. Once the system is installed and rebooted, the proper kernel (32 or 64) will get loaded if the system supports it.
4. Changing the hostname of your Solaris boxThe *right* way is to use sys-unconfig to re-configure the net settings on
your box.
For some purposes that's a little over the top though.
To change the hostname without sys-unconfig there are at least 3 files
you need to edit:
/etc/inet/hosts
/etc/nodename
/etc/hostname.* (where * is the name of your interface)
If you're on Solaris (rather than an OpenSolaris build) then you need to
add
/etc/inet/ipnodes
to that list.
Note that some other apps use the name of the host for other things and
may need updating.
Some of those files are marked read-only by default. If you're root and
using vi you can write to them with :w! otherwise use chmod.
5. Steps to replace the e1000g nic driver
(1) Check your system is 32bit or 64 bit:
# isainfo -b
(2) If it is 64bit, replace the 64bit e1000g binary in the directory of
/kernel/drv/amd64/
Otherwise, replace the 32bit binary at:
/kerne/drv/
(3) Confirm the driver version is 5.1.9.9:
# strings /kernel/drv/amd64/e1000g | grep Ver
or:
# strings /kernel/drv/e1000g | grep Ver
(4) Add the driver using the following command:
# add_drv -i '"pci8086,10bd"' e1000g
6. 正确使用pkgadd命令
pkgadd -d need a full path name to a directory. So the following two commands lines are equivalent .
# cd /ws/onnv-stc2/packages/i386
# pkgadd -d . SUNWstc-tetlite
And
# pkgadd -d /ws/onnv-stc2/packages/i386 SUNWstc-tetlite
7. Renaming local zone hostname
The procedure for renaming a Solaris 10 local zone's hostname is not well documented. By trial and error, Sun support and I worked out the following.
When setting up a new local zone, "unsetenv TMPDIR" or a number of key packages will fail to install in the new zone.
"hostname newHostName" and make sure /etc/nodename, /etc/inet/hosts, and /etc/inet/ipnodes have the appropriate entries for the new hostname.
"zlogin -C newZone" to allow sysIDtool to complete.
# ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ""
Generating public/private rsa key pair.
Enter file in which to save the key (//.ssh/id_rsa): /etc/ssh/ssh_host_rsa_key
# ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ""
Generating public/private dsa key pair.
Enter file in which to save the key (//.ssh/id_dsa): /etc/ssh/ssh_host_dsa_key
Kill any existing sshd and run the ssh start method /lib/svc/method/sshd start
Fix /etc/nsswitch.conf (defaults to bogus NIS stuff).
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
