Solaris Frequently Asked Questions


HOSTID AND ETHERNET ADDRESS



Problem: How do I get the Hostid and ethernet address from device

driver level?





Answer: NORMALLY, the hostid is returned by 'sysinfo' system call

with SI_HW_SERIAL command. From kernel you can access the variable

'char hw_serial[11]' which contains hostid string after system is

booted up.





For ethernet address, access 'struct ether_addr' in

/usr/include/sys/ethernet.h'.



__________________________________________________________________



CREATION OF DEVICE NODES



Problem: When using ddi_create_minor_node, an entry is created in

the /devices directory, but when and how is that entry gets linked

in the /dev directory? Answer: After the /devices node has been

created, the following utilities can be used to create appropriate

links from /devices to /dev directory.



For Disks: Use the utility /usr/sbin/disks.



For tapes: Use the utility /usr/sbin/tapes.



For serial ports: Use the utility /usr/sbin/ports.



For Pseudo devices: Make appropriate entries in /etc/devlink.tab

and then execute

/usr/sbin/devlinks.



For clone drivers: The nodes under /dev are created when the

driver open routine is called.



All of these utilities should be run either after executing

/usr/sbin/drvconfig or /usr/sbin/add_drv.



Note: boot -r (reconfiguration boot) automatically runs the above

mentioned utilities.





__________________________________________________________________



SAMPLE STREAMS DRIVER



Problems:



1. The sample driver includes , which is not

found in /usr/include/sys directory.



Solution: This header file can be found in the directory



	 /usr/src/uts/`arch -k`/sys 	



where `arch -k` will give one of the following: sun4, sun4c,

sun4d, sun4e, sun4m. Note: This header file is not essential for

the given sample driver.



2. The 5th entry in the dev_ops structure (devo_probe entry) is

nodev.



Solution: It should be 'xxprobe' instead of 'nodev'. Also add the

following 'xxprobe' routine to the driver.



static int



xxprobe (dev_info_t *dev)



{



	return (DDI_PROBE_DONTCARE);



}





__________________________________________________________________



ACCESSING SYMBOLS FROM OTHER MODULES



Problem: How to access external symbols, i.e. functions and

variables which are defined in other driver modules.



Answer: Mention the list of modules on which your driver depends

in the '_depends_on[]' list in your driver code.



e.g. If your driver accesses symbols like ufs_syncbusy, ufs_vfsops

and ufs_flushi, put the following line in your driver code, static

char _depends_on[] = "fs/ufs";



if there are more one modules that you driver depends on, add

those modules to _depends_on[] string, separated by space.



e.g. static char _depends_on[] = "fs/ufs drv/zs" ;





__________________________________________________________________



PROBLEMS RELATED TO AUTOPUSH



Problem: Can't do the 'autopush' when the system is booted for a

STREAMS module/driver. It doesn't work manually, either.



Error messages:



autopush:ERROR: File /etc/iu.ap: could not configure autopush for

line 1



autopush:ERROR: Major device is not a STREAMS driver



Possible causes/fixes:



a. The driver/module is not set up to be a STREAMS driver/module.



The cb_stream field (second last one) of 'struct cb_ops' should be

initialized to be the address of STREAMS driver's streamtab

structure.



b. The STREAMS driver/module is not loaded into system when the

'autopush' command is executed.



Put the driver in 'forceload' section of /etc/system will load the

driver/module at boot time.





__________________________________________________________________



MULTIPLE MINOR DEVS FOR A PSEUDO DRIVER



Problem: Pseudo-drivers can only support one instance. How to

multiplex multiple minor devices through one instance?



Answer: If the pseudo-driver needs more than one minor device,

they must all be handled by instance zero. All the minor nodes to

be created should be created by the attach routine when its

called. Also allocate and initialize all the minor node specific

data structures in the attach.



Rest of the handling of minor devices (open/close/ioctl...) is

same as for any other driver.



Make entries in the /etc/devlinks.tab for each minor node. Then

run devlinks to create the links from the /dev directory to

/devices for each minor node. (Note: devlinks should be run only

after the driver is loaded in the kernel and the nodes in /devices

have been created)





__________________________________________________________________



ANSWERBOOK PROBLEMS AND SOLUTIONS



Q: When running AnswerBook in either a CD-ROM based or combination

CD-ROM/hard disk based installation, the following message

appears:



Verifying environment...



	bookinfo: Can't access TOC database for book syssoft_ab:

	/cdrom/AnswerBook/_data/syssoft_ab.{dir,pag}



	Reason: No such file or directory



AnswerBook cannot start until these problems have been fixed.



How do you fix this problem?



A: This error appears if the CD-ROM is inserted into the drive but

is not mounted.



Mount the CD-ROM with the following commands:



o For a local mount:



	% mount -r /dev/sr0 /cdrom_mnt



where "cdrom_mnt" is the mount point designated for your CD-ROM

drive, usually /cdrom.



o For a remote mount:



	% mount -r server:/cdrom_remote /cdrom_mnt



where "server" is the name of the remote server, "cdrom_remote" is

the name of the directory in which the drive is mounted on the

remote server, and "cdrom_mnt" is the local mount point designated

for your CD-ROM drive.





__________________________________________________________________



DETAILS ON NIS+ INSTALLATION



Q) What is NIS+?



A) Network Information Service (NIS+) is an enterprise level

naming service designed to serve small to very large networks. It

is a replacement for earlier NIS (nee YP) and a complete rewrite.

In NIS compatibility mode, NIS+ serves NIS client requests as

well.



Q) What are the key differences between NIS and NIS+?



A) There are many differences, but here are the main four



- NIS had a flat name space, while NIS+ is hierarchical. So with

  NIS+ one can easily manage growth and changes.



- NIS+ is secure and allows fine grain access control.



- NIS+ updates are on incremental basis and much faster (in

  minutes).



- NIS tables were single key-value pairs while NIS+ has multiple

  key value pairs. This means that you can do searches based upon

  a particular value of a particular key.



Q) How will I benefit from NIS+?



A) Now, one no longer has to wait for 24 hours or more to get the

maps propagated. NIS+ does fast incremental updates. So, it should

be very fast and easy to update any of these changes



You will be able to traverse through all the domains without much

trouble. Earlier there was no easy way to find out information

about other domains.



You will get improved fault tolerance even if some of the NIS+

server die. Your client will attempt to bind to any of the NIS+

servers even if they are not the same subnet.



Your local sysadmin can set policies such that you can change some

of the fields of your entries. For example, you could change your

shell or home directory without going through a sysadmin.



Q) Can I still use all YP/NIS commands?



A) This will depend upon whether there is a NIS server available

for your domain OR whether the NIS+ server is running in YP compat

mode. If it is, then one should be able to make use of all YP

commands except those commands that change the NIS maps such as

yppasswd or chkey for publickey information.



Even if your NIS and NIS+ domainnames are not the same, one can

run ypset and bind it to a different domain than its own local

domain.



You will also notice some differences in terms of the names of the

automounter maps. These maps no longer have any embedded dots '.'

in them. Also, some of the maps may now look different, for

example, the hosts map. If some of your applications use NIS API

and refer to maps with embedded dots in them, then they will not

be able to find those maps.



We recommend that you use NIS+ commands for your queries.



Q) Can I revert back to using NIS?



A) That depends upon the way things were set up. If there is still

a NIS server on your subnet, it can still be done. The main change

required will be - change your domainname back to what it was -

change your /etc/nsswitch.conf to your earlier set up



Q) Can I still send/receive mail outside my domain? Is my NIS+

domain same as my mail domain?



A) Yes, you should be able to send/receive mail as earlier. For

mail purposes, you are still a part of the domain above you. For

example, if you are currently in XYZ.Eng.Sun.COM, for mail

purposes, you are in Eng.Sun.COM domain. Your email address may

change depending upon the new NIS+ domainnames.



Q) Can I do lookups in other domains?



A) Yes, you just need to specify the complete NIS+ name of the

table/entity that you are trying to locate.



Q) Can I log in on machines in other domains?



A) Only if your local credentials have been added to that other

domain.



Q) I am running 4.X. Can I run NIS+ on my machine?



A) No, not as a client. We only support 4.X NIS+ servers. There is

no support for any of the name service switch and the associated

getxxbyyy routines in libc. However, from a NIS+ 4.X server, one

can execute all NIS+ commands.



Q) Will conversion to NIS+ give me performance problems?



A) In normal operations, you should not see any impact. A few

things have speeded up substantially, for example, doing su with

NIS+ has become very fast.



One may find that the number of packets that go to the network

have increased in number. We hope to address that in 493 release.



Q) What are the known major problems with NIS+?



A) NIS+ servers (when running in NIS compatibility mode) can serve

NIS requests from 4.X clients but it cannot forward 4.X DNS

requests to the nameserver. This means that one cannot talk to

other DNS domains. This is not a problem with Solaris 2.0 clients

which use the name service switch to get the appropriate access.



The installation isn't exactly fool-proof. We hope to address this

in a future release.



Q) What is involved in setting up NIS+ on my desktop?



A) You should be running Solaris 2.0 or higher to be able to run

NIS+. The following should be done:



- change your domainname to the new NIS+ domainname



- create /var/nis directory



- add the IP address for your NIS+ server in your /etc/hosts file



- change your /etc/nsswitch.conf file to use NIS+ instead of NIS



- adding /etc/resolv.conf file along with nameserver entries



- make changes to your /etc/auto files to refer to automounter

  maps in auto_form from auto.form.



- adding NIS+ credentials in the cred table for yourself as well

  as for your machine.



Q) Why do I have to have all these passwds? NIS did not require

one.



A) NIS+ is secure. i.e. the NIS+ server before giving you any

information verifies that you indeed have the rights to get access

to that information. This security is based upon secure RPC, which

needs you to have publickey and secretkey stored with NIS+; and

your secretkey is encrypted with your passwd. Hence you need this

extra passwd during chkey time. If this passwd is not the same as

your login passwd, then you will not be able to make NIS+ calls

unless you have done an explicit keylogin(1).



NIS was not based upon secure RPC. So, there was no need for a

passwd there. You still needed a passwd for logging in, just as in

the old time-sharing days.



Q) Can I have different passwd for NIS+ and logging in? Are there

any impact if I have my own entry in my local /etc/passwd file?



A) yes, you can; but this would mean that you will have to do a

keylogin(1) before you can make any NIS+ operations. So, we

recommend that this not be the case. It is perfectly reasonable to

have your passwd entry also in the /etc/passwd file; just make

sure that it is the same as in passwd table. The only problem is

when you change your keys. During the installation time, you would

normally do a chkey, and chkey being a user level program cannot

read your /etc/shadow file. So, as a workaround, set your passwd

entry in /etc/nsswitch.conf to nisplus and files, do the chkey and

then put it back the original way. You will also have to change

your passwds at two places, once in your local passwd file and

then in the NIS+ passwd table with passwd(1) and nispasswd(1),

respectively.



Q) My machine name collides with someone's login name. What do I

do? Why should I care? It worked earlier, now it does not, why?



A) Clients of NIS+ (called as NIS+ principals) can be both

machines as well as normal users. The NIS+ principals are named as

use_login.domainname or machinename.domainname. For example, my

NIS+ principal name is name.eng.sun.com. My machine's NIS+

principal name is machine.eng.sun.com. NIS+ does not distinguish

between the two - both of them have their own associated

credentials and NIS+ access control mechanism uses it to

allow/deny permission to access information.



So, the machines and users now share the same name space. In the

past, this was not a problem because anyone could be a client of

NIS and access NIS information.



Approximately 10% of users may find this collision. In such cases,

preference is being given to the user. i.e. the user gets to keep

the same name and the machine's name has to be changed. We suggest

that you choose a new name for your machine and add an alias for

your machine's old name.



Q) Is it still possible to play around in a NIS+ domain and yet

use NIS domain (different from NIS+ domain) for daily operations?



A) It is possible but the steps are slightly complicated. The

problem comes from the fact that the domain names are different

and that all entries in /etc/nsswitch.conf assume that they are

all to be resolved to the current domainname. Here is the hack:



# domainname newNIS+domain



# edit /etc/nsswitch.conf file to have only files for publickey.



Comment out the entry for "nobody" in your /etc/publickey file.



# Kill ypbind



# Add the IP address of the NIS+ server in /etc/hosts file



# nisinit -c -H server_name



# nis_cachemgr



# test it by doing nisls or any other NIS+ operation on the NIS+

  domainname



# domainname old_domain_name



# restart your ypbind



With this hack, you are now accessing NIS+ tables as "nobody" and

you will have to specify the complete directory name for any

operation. Also, now you cannot make any secure RPC call.



Q) I recently installed a 486/50 machine as an NIS client in

house. and connected to our local network via a THICK net ethernet

drop. I now have that machine up at a vendor site who has THIN

ethernet and is not running NIS+ nor NIS, so I specified NONE

during the configuration. This is a class B address i.e.

130.35.19.70 and the subnet mask is ffff0000. However, I am not

able to



	a) talk to any other machines



	b) OPENWINHOME hangs consistently.



A) If you are using THIN net then make sure you reconfigure the

smc card for THIN net, the default is usually THICK net. If you

are not getting any error messages from the smc driver during boot

up then the IRQ and I/O address should be correct. However, there

might be a conflict of the shared memory address and usually this

is with the disk controller.



Q) I'm trying to use NIS+ on a PC running Solaris 86. I have an

SS2 set up is the NIS+ master server. NISD is running with a

security level of 0. I've followed the directions in answerbook

for setting up and NIS+ client. I've created an account called

markl on sparc2 (the nis server). I've put the home directory in

/home2/markl, and am using the automounter to give me a home path

of /home/markl. I can log onto sparc2 without problems. When I try

to login as markl on solaris86 (the intel box), I'm told that I

don't have a password and I should make one. It runs the passwd

command (you can see the word passwd on the screen) and then there

is not markl account. Then back to login. When I login to root,

and do a csh, I can su markl, I can cd ~markl, I can niscat

passwd.orig_dir and see the passwd data. It has an entry for

markl. If I su to junk, I'm told the junk is not a valid account.

It seems that the NIS bindings are working, just not login.



Also, I can go to a system running SunOs 4.1.2 as an NIS client

(not NIS+) and login as markl. Has anyone tested the NIS+ client

with a Sparc based NIS+ master server. Anyone have any ideas on

what I'm doing wrong??



A) The following is the workaround for this problem:



Apparently this problem is caused by the passwd file is used to

populate the passwd table by using the nisaddent "passwd" command,

it assumes that the file is a 5.X passwd file and hence does not

populate the "shadow" column of the passwd table. The sysadmin is

then supposed to run the nisaddent command with the equivalent

shadow file.



e.g.



# cat /etc/passwd | nisaddent -v passwd



# cat /etc/shadow | nisaddent -v shadow



However, in this particular case, there was no equivalent shadow

file available and hence the passwd col was empty and hence no one

could login to these machines.



Workaround #1:



The workaround is as follows:



e.g.



The /etc/passwd need to contain the encrypted password.



# cat /etc/passwd | nisaddent -v passwd



# awk -F: '{printf("%s:%s:6445::::::\n", $1, $2)}' /etc/passwd >

/tmp/shadow



# cat /tmp/shadow | nisaddent -v shadow



Workaround #2:



The other way to solve this problem is to use the -y option of

nisaddent. This only works if the customer has a running YP domain

setup. First ypxfr the passwd map to the machine and then use

nisadent -y



# /usr/lib/netsvc/yp/ypxfr -c -d YP_DOMAINNAME -h YP_SERVER

passwd.byname



# /usr/lib/nis/nisaddent -y YP_DOMAINNAME passwd



With this way, there is no need to run any awk script and

everything works fine.



Q) The NIS+ server was unavailable and the clients were not

allowing logins. What needs to be done?



A) Change the following two lines in the nsswitch.conf file



passwd: files nisplus group: files nisplus



to



passwd: files [NOTFOUND=return] nisplus group: files

[NOTFOUND=return] nisplus



You should be able to login now.



Q) What is the significance of having the default entry as

networks: nis [NOTFOUND=return] files in /etc/nsswitch.conf?



A) The reason that the default nsswitch.conf file contains

"[NOTFOUND=return]" is that we wanted the default behavior to be

4.x-compatible, and 4.x generally follows a policy of "only look

at 'files' if 'nis' is unavailable". Thus entries like



	networks: nis [NOTFOUND=return] files



do the right thing for 4.x-compatibility





__________________________________________________________________



Q) What does the choice of name service in Host Manager and User

Account Manager mean?



A) The choice of NIS+, NIS, or None is typically per-network.

Usually you should specify it the same way every time you start

Host Manager or User Account Manager on a network. Do not change

name services per-host or per-user. If you need to edit a

particular record in a particular database stored by a particular

name service, you can use the lower level tool Database Manager.



Q) If name service should always be the same, why do Host Manager

and User Account Manager present a choice?



A) Firstly, admintool can't always figure out what the right

answer is and so is asking you for verification. And secondly,

sysadmins with unusual configurations sometimes need to override

the choice of name service.



Q) Can I select a different name service for each host when adding

clients through Host Manager?



A) The simplest answer is "No". All centrally administered Solaris

hosts on a network should use the same name service(s). Even

though Solaris provides another name service (NIS+), a new set of

administration tools (admintool), and the ability to control the

order of name service lookups by database (/etc/nsswitch.conf), it

still expects all centrally administered hosts on the network to

use the same name service(s).



Unfortunately the appearance of the admintool tools has misled

some users to conclude that use of different name service(s) by

different Solaris hosts was intended to be fully automatic and

transparent.



Q) Are there exceptions to the rule that all Solaris hosts on a

network should use the same name service(s)?



A) Yes. Some support is provided to ease transition from NIS to

NIS+, or from None to NIS+. Knowledgeable users can use the None

option to set up some test configurations. And power users may

wish to modify the /etc/nsswitch.conf file on their workstation.



Q) Does saying that all Solaris hosts should use the same name

service(s) mean they should use only one name service?



A) No. Hosts normally use a combination of local and network name

services to allow both independent bootup and easy normal

operation, and to provide local overrides to network-wide

information. For example the template /etc/nsswitch.nisplus allows

local entries for passwd, group, automount, and aliases to

override network-wide information.



Q) /etc/nsswitch.conf appears to provide a great deal of

flexibility, some of which isn't used. What's the file for?



A) The initial motivation for /etc/nsswitch.conf was to give users

full control over where and in what order gethostbyname() looked,

similar to Ultrix. The implementation scheme used was so simple

and powerful that its use was extended to cover most name service

lookups rather than just gethostbyname() calls. This increased

flexibility is available to all users.



As distributed, Solaris uses one of only three standard

configurations of /etc/nsswitch.conf (templates nsswitch.nisplus,

nsswitch.nis, and nsswitch.files), depending on whether the

network name service is NIS+, NIS, or None. A simple change to

activate DNS for gethostbyname() calls is included in the comments

inside /etc/nsswitch.nisplus.



Q) Why is the None name service option provided?



A) The primary reason for the None name service option is to

support customers who won't run either NIS or NIS+. Most such

customers keep a master copy of /etc configuration files on a

central machine and use `rdist` or a similar tool to broadcast

copies to all workstations.



The second reason for the None name service option is to support

local overrides to network-wide information.



The third reason for the None name service option is to help work

around the lack of programmatic updates to NIS.



Finally, the None name service option supports quick setup of demo

or test configurations by knowledgeable users who either can't or

don't want to update the name service.



Q) If I explicitly specify a different name service when adding a

client, will Host Manager "make it right"? For example, if my

network is running NIS+, yet before adding a new dataless client I

specify None, will Host Manager update all the right files in the

right way to make the new client known all across the NIS+ domain?



A) No.



There is no combination of file and name service updates that will

make all such mixed configurations work right. No matter how hard

Host Manager tried, some combinations would never work. Non-

support of different kinds of name service clients on the same

network shows up throughout Solaris; it's not just a restriction

imposed by the admintool tools.



Q) How do the admintool tools support NIS?



A) All NIS maps can be read by all admintool tools.



No NIS map can be programmatically updated by any admintool tool.

Users of any admintool tool on a network using NIS must perform a

manual procedure. That procedure involves pretending to use None

name service, capturing the changes in /etc files, manually

merging the changes into the NIS master files and remaking the NIS

maps, and cleaning up the /etc files. The new information will not

be known across the entire NIS domain until all the push

operations initiated during the manual procedure have completed.



Note that neither this use of the None name service option as part

of the manual workaround procedure, nor the on-screen

documentation of this manual procedure by some admintool tools,

change the fact that admintool tools do not expect different

Solaris hosts on the same network to use different name

service(s).



Q) The message Host Manager gives when I select NIS and try to do

an operation that might involve updating maps seems to imply the

lack of support for NIS updates has something to do with mixed OS

versions, and might change in the future. Is this true?



A) No. Programmatic updates to NIS are not possible with any

combination of OS versions. And so no admintool tools will update

NIS under any circumstances.



The message Host Manager gives intends only to state that the tool

can't update NIS programmatically then tell the user how to do so

manually. Unfortunately the message can be interpreted more

broadly than it was intended, and may mislead some users.



Q) Why can't the admintool tools update NIS automatically?



A) The NIS protocol doesn't support updates by programs. In SunOS

4.x the only way to update NIS was to edit the files on the NIS

master then run `ypmake`. Solaris isn't any different. In fact,

Solaris doesn't support `ypserv` at all. Customers are encouraged

to migrate from NIS to NIS+. NIS+ provides much better security,

better performance, and can be updated by programs. NIS+ supports

a "NIS compatibility mode" to ease the transition.



Q) What does it mean to say a printer is a NIS+ Printer?



A) Printer Manager maintains a list of "registered" printers

across a whole network as a convenience to system administrators.

Typically system administrators will register each locally

attached printer in the list as they set it up, then refer to that

list later when setting up remote access to printers for a client.



The list of registered printers happens to be stored by NIS+, and

the label "NIS+" fits on the button better than the label

"registered". That's the only reason these printers may be called

NIS+ Printers. The "lp" subsystem knows nothing about the list of

registered printers. Registered printers don't function any

differently than unregistered printers.





__________________________________________________________________



QUESTIONS ON IP INTERFACE



Q) Is there documentation that describes the interface between IP

and network drivers, namely, the SUN specific requirements not

outlined in the DLPI Version 2 specification?



A) IP is a STREAMS module in Solaris 2.X. Any module or driver

interface with IP should follow the STREAMS mechanism.There are no

specific requirements for the interface between IP and network

drivers.



Q) When an ifconfig device0 plumb is issued, the driver

immediately receives a DL_INFO_REQ. Exactly what is required in

the DL_INFO_ACK from a Style 2 provider?



A) Please look at 'dl_info_ack_t' struct in

/usr/include/sys/dlpi.h.



Q) Is it possible for the driver to be a CLONE driver and also a

DLPI Style 2 provider?



Yes.



Q) If so, how do I map the minor number selected in the open

routine to an instance prior to a DL_ATTACH_REQ? The technique of

using the minor number to obtain the instance in the getinfo

routine is not valid prior to the DL_ATTACH_REQ. How do you

suggest this be handled?



A) The 'DL_ATTACH_REQ' request is to assign a physical point of

attachment(PPA) to a stream. The 'DL_ATTACH_REQ' request can be

issued any time after a file or stream being opened. I don't think

the 'DL_ATTACH_REQ' request has anything to do with assigning,

retrieving or mapping minor/instance number. Of course, you can

issue a 'DL_ATTACH_REQ' request for a file or stream with desired

major/minor number. To the question of mapping minor number to

instance, usually the minor number(getminor(dev) is the instance

number.



Q) In the examples a minor node is created each time the driver's

attach routine is called. How would a CLONE driver attach to

multiple boards, that is, have multiple instances, and still only

create one minor node?



A) For the CLONE driver, I don't know if it is possible to do

that. For the non-CLONE driver, it is possible to use the bits

information in a particular minor number, for example 'FF', to map

all other minor nodes.





__________________________________________________________________



QUESTIONS ON RPC AND TLI



Q) We are using the TLI functions such as t_open and t_bind in one

of our programs. When we do a t_bind call, why do we get an M_DATA

ioctl rather than an M_PROTO? Do you intend to do this

permanently?



A) The t_bind() function does local management, so M_DATA ioctl is

an appropriate message block.



Q) I'm looking for RPC development kit for Macintosh. Can you

help?



A) You probably could get those informations by calling 'Apple'.





__________________________________________________________________



NFS INTEROPERATION



Q) With Solaris 2.x configured as a client, nfs mount with HP-UX

or AIX machines will not work, even though dfshares shows that the

file systems are exported.The error message "Server not

responding" appears.



A) The following workaround is suggested (to be done on solaris

2.x machine):



1. Append the following two lines into /etc/system



	set nfs:nfs_portmon=0 	



	set nfs:nfs_fastpath=0



2. Cut the number of group that root belongs to 6 in the

/etc/group if this is the case. Usually it happens if root belongs

to 11 groups or more.





__________________________________________________________________



NETWORK INSTALL ON X86



First step in network install is to prepare a boot server. You

have two options to choose: either an Intel machine running

Solaris 2.1 FCS or a sparc machine running Solaris 2.2



How to make a sparc machine running Solaris 2.2 an install server?



Follow these steps: (Here client refers to the machine on which

you wish to install over network, and server refers to the sparc

machine that serves as an install server. In the example command

lines below, "pluto" is client and "mars" is install server).



1. Install patch # 101085-01 on server. PLEASE UNINSTALL THIS

PATCH AFTER INSTALLING ON x86 since it is no more required and is

not tested for side effects completely.



2. Insert the Solaris 2.1 for x86 FCS CD (OS CD) into the CD ROM

drive on server and the partitions are automatically mounted.



3. Make CD ROM sharable by the client. add this line to

/etc/dfs/dfstab and run shareall share -F nfs -o ro,root=pluto -d

"/cdrom" /cdrom



4. Add entries to client in yp database.



for example:



	192.246.8.13	pluto	# CompuAdd 486



in /var/etc/hosts and,



	00:60:8c:53:eb:97	pluto



in /var/etc/ethers and update yp database.



	/var/yp/make hosts



	/var/yp/make ethers



5. cd /cdrom/cdrom0;



6. add install client. /add_install_client -i internet_address -e

ether_address client i86pc for example:



/add_install_client -i 192.246.8.13 -e 00:60:8c:53:eb:97 pluto

i86pc internet and ether net addresses are of the client to be

booted.



7. Share root partition for the client sitting on the server. Add

this line



share -F nfs -o ro,root=pluto -d "/cdrom/*"



/cdrom/disc_image_number_fcs/export/exec/kvm/i386.i86pc.Solaris_2.

1 to /etc/dfs/dfstab and run shareall.



How to make an intel machine running Solaris 2.1 FCS an install

server?



Follow these steps: (Here client refers to the machine on which

you wish to install over network, and server refers to the intel

machine that serves as an install server. In the example command

lines below, "pluto" is client and "haley" is install server).



1. Insert the Solaris 2.1 for x86 FCS CD (OS CD) into the CD ROM

drive on server and mount the CD ROM



	mount -o ro -F hsfs /dev/dsk/c0t6d0p0 /cdrom



2. Make CD ROM sharable by the client. add this line to

/etc/dfs/dfstab and run shareall



	share -F nfs -o ro,root=pluto -d "/cdrom" /cdrom



3. Add entries to client in yp database.



	for example: 192.246.8.13	pluto	# CompuAdd 486



in /var/etc/hosts and,



		00:60:8c:53:eb:97	pluto



in /var/etc/ethers and update yp database.



	/var/yp/make hosts



	/var/yp/make ethers



4. cd /cdrom;



5. add install client. /add_install_client -i internet_address -e

ether_address client i86pc for example:



/add_install_client -i 192.246.8.13 -e 00:60:8c:53:eb:97 pluto

i86pc



internet and ether net addresses are of the client to be booted.



6. Share root partition for the client sitting on the server. Add

this line



	share -F nfs -o ro,root=pluto -d "/cdrom/*"



/cdrom/export/exec/kvm/i386.i86pc.Solaris_2.1 to /etc/dfs/dfstab

and run shareall.



Once you have done this, the install server is ready and is

listening to boot requests over network (rpld daemon). Now boot

the client with FCS boot floppy and network card configured

properly and connected on to the network. Follow the instruction

for installation and complete the installation.





__________________________________________________________________



ATTACHING AN EXTERNAL DISK TO A SCSI CHAIN



Problem: If you attach an external disk to a SCSI chain, the bios

does not see the driver.



Workaround: Configure the device as "FR" rather than "HD" (to

denote removable media) during the EISA configuration.





__________________________________________________________________



ENABLING THE SECOND SERIAL PORT



Problem: What is the proper procedure for enabling the 2nd serial

port,tty01?



Answer: The creation of tty01 is disabled by default. In order to

have a tty01 device please follow these steps:



1. cd to /kernel/drv and edit the file asy.conf. Uncomment the

last two lines of the file.



2. Make sure IRQ 3 is not being used by any other device in the

machine.



3. Now reboot the machine with '-r' option.(ie b -r).



Step 3 can be skipped by running 'drvconfig' and 'devlinks'. This

should create tty01.



If the above steps do not work then edit the file

/etc/path_to_inst and remove all the lines which have "asy" in

them. Then follow step 3 or the alternative to step 3.





__________________________________________________________________



UNABLE TO ACCESS A SECOND DISK



Problem: 'newfs' on the second disk starts normally, but

terminates with an error. Any further 'newfs' on the second disk

fails with a 'No such device or address' error. But it probes the

disk at boot, and utilities like fdisk and prtconf see it too.



Solution: First off, there must be a SOLARIS partition on the

drive. If there is not, then run fdisk to create the partition.

see fdisk(1) for info on this action.



The second disk is currently unusable. This is because the newfs

command blew away the VTOC, which is stored near the beginning of

slice s2, in the first few sectors on the disk. To restore the

vtoc execute:



	(? replaced by appropriate numbers)



	fmthard -n "" -i /dev/rdsk/c?t?d?s2 >/tmp/fmth



	fmthard -s /tmp/fmth /dev/rdsk/c?t?d?s2



Ignore the Invalid VTOC messages.



What is important is you should see a "new volume table of

contents in place" message after executing the second command.

not, if you do 'prtvtoc /dev/rdsk/c?t?d?s2' you should see one

slice defined (s2) covering the whole disk.



You need to do this even if you had to create a SOLARIS partition

with fdisk above.



Slice 2 cannot be used for the newfs in this mode, since it covers

cylinder 0. You must make another slice that starts on the second

cylinder, and covers as much of the disk as you want.



Here is how to do this:



In the file /tmp/fmth created above, there is a set of numbers

under the heading Dimensions:. Multiply the sectors/track by the

tracks/cylinder and you will see how many cylinders/track there

are. Lets say there are 2048 (this is a common number).



Edit /tmp/fmth adding a line just below the



* Partition Tag Flag....



line, and above the line that reads



2 5 00 0 



Add the following line:



0 6 00 2048 -2048



The  is say 2672640, the end of /tmp/fmth would

look like:



0 6 00 2048 2670592



0 5 00 0 2672640



now, run:



fmthard -s /tmp/fmth /dev/rdsk/c?t?d?s2



Slice 0 has now been created to occupy as much of the disk as is

usable.



run newfs /dev/rdsk/c?t?d?s0 to make the fs, and add an entry to

vfstab and you should be all set.





__________________________________________________________________



SCSI AND IDE DRIVES



Problem: How to make the SCSI drive as the primary drive, on a

system having both SCSI drives and the IDE drives, for installing

on a SCSI disk.



Answer: The PC hardware will typically "see" the IDE drives first,

so if you want the SCSI drive to be your primary drive, you need

to "turn off" the IDE definition(s) in the machine's BIOS setup

program.



After this, when you boot, you will see that the SCSI and "ata"

modules will both load.



Currently the installation only works on the primary drive.





__________________________________________________________________



CONFIGURING A BUS MOUSE



Q: The Microsoft 2-button bus mouse is also on the HCL. The

release notes make mention of changing the device name to /dev/msm

to get it to work. But there isn't any device called msm in the

dev directory. Even trying to create one did not bring up the

mouse. We finally just moved to a serial mouse. Has anyone got a

bus mouse to work?



Ans: Well, the Microsoft 2 - button bus mouse was tried on one of

the MP machines upstairs. Of course the mouse has to be plugged in

to the Microsoft bus mouse card. Then the file msm.conf should

match the card as far as intr and ioaddr is concerned. After this

make sure the programs "drvconfig and devlinks" are run. If not a

"touch /reconfigure" should be done and the machine rebooted.



Also, the OWconfig file should say 3 buttons instead of 2 when a

Microsoft bus mouse is used. This will allow the mouse to work

correctly. The release notes should mention that and if they don't

maybe the problem is fixed with the driver.





__________________________________________________________________



MAKING THE BUS MOUSE WORK



Q: During installation the customer gets the following message:



Configuring the /devices directory



WARNING: Can't register interrupt for logi device at IPL 1 because

it conflicts with another device using the same vector(4) with an

IPL 12. Reconfigure the conflicting devices to use different

vectors.



WARNING: logi: cannot add intr



Here is how the devices and interrupts are set up:



Logitech Mouseman tried both IRQ 5 and 3 (both gave above

mssg)



DPT 2012B/90 		14 - Edge (Bootable



Western Digital/AMC 10



ATI Graphics Ultra	 unknown



And obviously, /dev/logi does not get created. I tried both

drvconfig and devconfig - still couldn't get the node made.



Ans: IPL stands for Interrupt Priority Level. If you look at the

.conf files in the /kernel/drv directory the two comma separated

numbers next to "intr" are the IPL and IRQ respectively. By

default COM1 is enabled and it has an IRQ of 4. Also the logi.conf

file is set for an IRQ of 4 and since both the IRQs are same that

is where the WARNING message comes from.



I suggest that the logi.conf file be edited and the IRQ changed

from 4 to 3 since COM2 is disabled. Also make sure that the IRQ

jumper setting on the bus mouse card is changed to 3. After that

if the machine is rebooted after a "touch /reconfigure" is done

the logitech bus mouse driver should be loaded. To avoid rebooting

you can just run "drvconfig and devlinks" in order for the driver

to get loaded and the devices created.



In my previous email about the WARNING messages I recommended that

the Logitech bus mouse be used at IRQ 3 since COM2 is disabled. A

better recommendation is that the bus mouse be used at IRQ 5 since

this will still leave the option of using COM2 at IRQ 3.





__________________________________________________________________



CONFIGURING OPENWINDOWS THROUGH OWconfig



Q: If the devconfig program is run after installation, it will

truncate the OWconfig file to contain only the lines you

uncommented. This is not necessarily a problem IF your Openwindows

was configured properly. But it is wasn't you will need to

recreate that file. We pulled it from the CD- ROM.



Ans: If you run devconfig again giving all the correct information

then the OWconfig should be correspondingly edited.





__________________________________________________________________



DISK PARTITIONING



Q: Slices for /var and /usr/openwin



Is it necessary to divide /var and /usr/openwin directories into

slices? Installation manual doesn't say so, but installation

program shows disk size to be needed for these directories in

'Disks & File system' screen.



Ans:



It isn't strictly necessary to have separate slices for these two

filesystems. /var tends to have files that grow, i.e. log files,

mailboxes, crash dumps, etc. So unless you configure a large root

partition, generally it's A Good Thing to have a separate slice

for /var.





__________________________________________________________________



BOOTING SOLARIS X86 IN VERBOSE MODE



Problem: Trying to load Solaris x86 from hard drive and it hangs

without any error messages. The system never recovers and often

has to be rebooted.



Workaround: This type of problem can be very frustrating because

you don't have a clue as to where the system hung in the boot

process.



The lines of the booting script will be displayed as they are

executed if you set the verbose mode of the secondary boot. See

the Debugging section of boot(1M) for details. There are at least

two ways you can do this:



1) Edit the /etc/bootrc file, inserting the following line at the

beginning:



	verbose



Everything in the bootrc file will be displayed to the screen as

it is executed. This will tell you what the system was trying to

execute when it hung.



Note: If you are booting from the CD or can't get the system up at

all, you can't do this.



2) At the boot prompt, enter "i" to run the boot interpreter

interactively. Then enter:



	verbose 	source /etc/bootrc



This will re-run the booting script in verbose mode.



Note: That this does not cause the secondary boot to tell you

about the details of machine initialization.





__________________________________________________________________



THE NEW DPT SCSI CONTROLLER



Description: An outline of some the issues and observations

relating to the installation and configuration of the DPT 2022

EISA controller.



Overview: This controller is a next generation low-cost

replacement for the now obsoleted DPT-2012 family. The card is a

full length EISA controller with a reduced chip count. The cache

module now sit's on the controller and takes industry standard

36bit SIMMs rather than taking up a second slot and needing

proprietary memory modules.



Installation/Solution: By default the card has Jumper Y20 enabled

which means that for those cards with floppy controllers on them -

they will conflict with any other host based floppy controllers.

BIOS and SmartROM were at level 5C and 2C respectively. This is

important to remember as earlier revisions may cause a problem

especially with most UNIX environments. If your customer has an

earlier release of firmware please get them to contact their DPT

channel for a BIOS / SmartROM upgrade. Finally the controller EISA

setup defaults to using IRQ 15 level interrupts. For Solaris x86 I

changed this setting to IRQ 15 edge interrupts. Finally, DPT

recommended booting up DOS and running their dptmgr.exe utility to

mark the initial installation as being a Solaris installation. No

further action is required. The installation should proceed

normally.





__________________________________________________________________



X86 VERSUS SPARC



Basic Differences Between X86 Machines and SPARCstations and

hardware setup.



The x86 computer system runs the same instruction set and their

buses transport the same set of signals as on the SPARC systems,

but there are hundreds of adapter cards and motherboard

configurations to account for when installing on an x86 system.

The basic differences are described in the following sections.



BIOS Versus OpenBoot



When a PC (x86 machine) is powered on or when the reset switch is

pressed, the PC automatically executes code in ROM. This code

causes the PC to run a series of self-test routines call POST.

POST routines determine which hardware is present, verify that the

hardware is minimally functional, and perform initialization of

that hardware. This is the same sequence of events that occurs on

the SPARCstations. However, on the PC, the code in ROM is known as

the BIOS (Basic Input/Output System), whereas on SPARC systems it

is known as OpenBoot.



In addition to POST, the BIOS supplies a set of routines for

controlling and servicing the hardware in a common fashion

regardless of who the manufacturer is. Thus it acts as a layer of

abstraction that permits the Operating system and other stand-

alone programs to be shielded from some of the idiosyncrasies of a

particular hardware implementation.



In some PCs, an add-in card contains its own installable ROM BIOS

which is known as an "extension" to the system BIOS. This add-on

card is located by a special signature during the primary bootup

process. Unlike diskette or a hard disk. The BIOS boot routine is

automatically invoked as the last part of a reset. After executing

the initialization code for the extensions, the first sector from

the boot device is copied to memory and then executed. If this

sector does not contain proper bootstrap code, the results are

unpredictable. In certain situations, this can be detected because

invalid data results and an error message is issued.



Disk Drive Setup



By default, floppy drive A is first checked for a boot diskette

and then hard drive C. If the PC has both 3.5" and 5.25" floppy

drives. It may not always be apparent which one is A and which one

is B. Unlike SPARCstations. some x86 manufacturers permit the A

and B drives to be swapped simply by opening the cabinet and

changing the connector the drive is plugged into on the ribbon

cable. The other end of the cable is connected to either the

motherboard or the SCSI adapter.



You can alter the defaults for booting by modifying the system

setup program. The system setup program is a configuration utility

supplied by the system manufacturer in ROM BIOS.



If the floppy drives are swapped by recabling, use the system

setup program to modify the settings of the A and B drives to

match. Otherwise, the results of accessing files on those drives

are unpredictable.



You can also use the system setup to disable the "shadow RAM" and

the "secondary cache". All other options should remain as the

factory default values as described in the manufacturer's

documentation.



Configuration Methods



Unlike SPARCstations, x86 companies are configured by hardware

jumpering, software settings in memory, or a combination of both

methods.



Configuring with Jumper Settings



A jumper is a small rectangular piece of plastic containing

metallic holes which fit over two pins and connects them

electrically, similar to closing a switch. A jumper block has a

label which can be a letter, or some combination like J8. A jumper

can be a single pair of pins or as many as a dozen laid out either

horizontally or vertically.



ISA boards should be checked thoroughly to verify that their

hardware jumpering is set to the factory defaults described in the

manual that came with the board. This can be determined by

comparing the positions of the jumpers with those in the diagrams

contained in the manual.



Some ISA cards can also be configured by software, provided the

jumpers are set correctly. For example, the SCSI host adapter

board has a jumper setting to indicate whether it or the

motherboard is controlling the floppy drive.



Configuring with Software Settings



EISA boards do not require hardware jumpering. Instead they use a

generic configuration program which comes on diskettes supplied by

the system manufacturer. It is necessary to run this program after

EISA boards are added, removed, or repositioned in a different

slot. Although the overall function of this utility has been

standardized, there are many implementations - each of which

presents its own user interface screens and menus.



Unfortunately, there is no a single way to invoke the program.

Some manufacturers put it on a bootable DOS diskette and start it

up automatically from the AUTOEXEC.BAT script. Others require that

DOS be running first before the EISA configuration diskette is

inserted in the drive.



In either case, this utility operates by reading files describing

the particular piece of hardware and what can be changed on it.

The naming convention for these files is !vvvpppp.CFG where vvv is

an alpha vendor ID and pppp is a numeric product ID. The contents

of these files are in ASCII and they contain a series of nested

keyword=value pairs describing not only EISA add-on cards, but

also ISA cards, and the system motherboard.



Even though the ISA cards cannot be configured with this program,

the program can still detect conflicting options among the boards

whose files have been chosen through its menu interface and whose

defaults may have been modified. Therefore, you should run the

configuration program before any ISA board changes are made.



Since some boards are too complex to be adequately described by

the syntax of the EISA configuration program, executable .OVL

files are provided. If the EISA utility is run many times from the

same diskette, it can fill the disk with files, since it saves the

previous configuration in the event you want to restore a former

setting. In this case, it is easiest just to use a new diskette.



Hardware Terminations



The SCSI adapter board has connectors for both an external and an

internal cable. The external cable will normally connect to a CD,

second disk, or tape drive while the internal cable will be

attached to the primary disk (i.e. target 0). If multiple external

devices are present, they are "chained" together in series.

Regardless of the number of external devices, terminate the last

one on the chain with a small plug containing resistors.



There are also terminating resistors on the disk at the end of the

internal cable. The SCSI bus requires termination at both ends,

only. Having one end unterminated, or supplying extra termination

somewhere in the middle, can cause unpredictable results.



To check this, remove the card and look for 3 flat resistors

directly under the internal cable connection. If they are found,

use tweezers or a needle-nose pliers to remove the resistors from

the board. If the CD drive was the only external device, and if it

is no longer needed after installation, then to avoid having to

put the resistors back into the board, place a termination plug in

the external SCSI connector.