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.