This chapter offers concrete examples showing how to:
Use a directory located on the host workstation as a root file system for the ChorusOS target system
Prepare a RAM disk on the target system and populate it with all necessary files
Create a file system on a target system local hard disk
Set up a ChorusOS target system as an NFS server
Set up a swap partition.
The first thing to do before mounting the root file system over NFS is to build a root file system for your target if you have not done so already.
Change to the directory where you build system images and make root:
$ cd build_dir $ make root |
If the root directory that is built under build_dir cannot be exported through NFS, you must move or copy it to a directory you can export:
$ cp -R build_dir/root exportable_dir |
Next, you must export the directory so that it is readable by the ChorusOS target system. On a host workstation running the Solaris operating environment, you can export the directory by adding a line to /etc/dfs/dfstab, similar to the following:
share -F nfs -o ro -d "target root dir" /export/ChorusOS/root
In order for the directory to be shared, you must then restart the NFS server on the host workstation:
$ su Password: root password for host # /etc/init.d/nfs.server start |
You can then verify that the directory is indeed available:
$ showmount -e host /export/ChorusOS/root (everyone) |
After you have verified that the target system root directory has been exported correctly on the host workstation, you may prepare a system image that mounts the directory during system initialization.
Make sure that the mount command is built into the ADMIN
system actor by setting the ADMIN_MOUNT
feature to true:
$ configurator -c conf/ChorusOS.xml -set ADMIN_MOUNT=true |
Make sure that the ChorusOS system can act as an NFS
client by setting the NFS_CLIENT
feature to true and the IOM
buffer tunables to appropriately
large values:
$ configurator -c conf/ChorusOS.xml -set NFS_CLIENT=true $ configurator -c conf/ChorusOS.xml -set iom.nbuf=8 |
Add the necessary commands to configure the network interface and mount the directory to the system initialization script, sysadm.ini(4CC), located in build_dir/conf/sysadm.ini:
# # Set umask to 0 during system configuration. # umask 0 # # Prepare Ethernet and loopback interfaces so that you can access the # host workstation (129.157.197.144) where the root file system is # located. Target system IP address here is 129.157.197.88. # # Note that you do not have to use Ethernet as your network interface, # but Ethernet is simple to set up, so we have used it here to avoid # cluttering the example. # mkdev ifeth 0 mkdev lo 0 ifconfig ifeth0 129.157.197.88 netmask 0xffffff00 broadcast 129.157.197.255 ifconfig lo0 127.0.0.1 up # # Reset umask to default. # umask 22 # # During system initialization, the target mounts a pseudo / file # system, but you can mount a new root over the old one. So, mount the # root file system through NFS. # mount 129.157.197.144:/export/target/build/root / # # Display mount status to the console. # mount
Place the new system image where it can be downloaded onto the target and reboot the ChorusOS system. If you are using TFTP to download onto a PC target for example, then you might do so as follows:
$ cp chorus.bmon /tftpboot $ rsh target reboot |
After the system reboots, the mount information should appear on the console. You could also run one of the actors located under the root file system to verify that everything is functioning correctly:
$ rsh target arun /bin/ls /bin started aid = 22 arp.r domainname.r ls.r pax.r tclsh.r chorusNSinet.r fsck.r mkdir.r pppstart.r touch.r chorusNSsite.r fsck_dos.r mkfifo.r profctl.r umount.r chorusStat.r ftp.r mknod.r profex.r uname.r cp.r hostname.r mount.r rdbc.r ypbind.r cs.r ifconfig.r mv.r rm.r ypcat.r date.r inetNSdns.r netstat.r rmdir.r ypmatch.r dd.r inetNShost.r newfs.r route.r ypwhich.r df.r inetNSien116.r newfs_dos.r shutdown.r disklabel.r inetNSnis.r nfsstat.r sysctl.r |
You can use RAM to house the root file system. This example shows you how. It is assumed that you have already been able to mount a root directory through NFS. See "6.1 Mounting a Root File System over NFS" for details.
Before you get started, you must add RAM disk support to your system image. The following commands add that support, build the system image, copy the image to the download directory and reboot the ChorusOS system running on an x86 target:
$ cd build_dir $ configurator -c conf/ChorusOS.xml -set RAM_DISK=true $ configurator -c conf/ChorusOS.xml -set iom.ramdisk0.size=0x1600000 $ configurator -c conf/ChorusOS.xml -set iom.ramdisk.sizeMax=0x1600000 $ make chorus $ cp chorus.bmon /tftpboot $ rsh target reboot |
In order to use RAM to house the root file system, you must first label part of the available space using disklabel(1M). disklabel uses entries in disktab(4CC) to label the disk. The following disktab entry serves to label a 16 megabyte area of RAM as a disk:
# This label can be used for a 16 megabyte RAM disk. The corresponding # newfs command to be used with this RAM disk is: # rsh target arun /bin/newfs -o space -c 2048 -m 0 /dev/rrd0a rd16Meg:\ :ns#4:nt#4:nc#32768 \ :pa#32768:oa#0:ta=4.2BSD: \ :pc#32768:oc#0:tc=unused:
The default system initialization file, sysadm.ini(4CC), creates special files to access the RAM, so you probably do not need to create them yourself. The entries to create special files may appear as follows in sysadm.ini:
# Create special files for RAM disk mknod /dev/rrd0a c 13 0 mknod /dev/rrd0b c 13 1 mknod /dev/rrd0c c 13 2 mknod /dev/rd0a b 13 0 mknod /dev/rd0b b 13 1 mknod /dev/rd0c b 13 2
The above example creates both raw and block mode special files for two user-accessible partitions, a and b, and one partition, c, for use by the system only.
Assuming the special files exist, you can proceed to label the disk and so forth. The following commands label the disk, read the label, create a file system on the disk and check the file system:
$ rsh target arun /bin/disklabel -w -r rd0 rd16Meg started aid = 22 $ rsh target arun /bin/disklabel -r rd0 started aid = 22 # /dev/rrd0c: type: unknown disk: rd16Meg label: flags: bytes/sector: 512 sectors/track: 4 tracks/cylinder: 4 sectors/cylinder: 16 cylinders: 32768 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 3 partitions: # size offset fstype [fsize bsize cpg] a: 32768 0 4.2BSD 0 0 0 # (Cyl. 0 - 2047) c: 32768 0 unused 0 0 # (Cyl. 0 - 2047) $ rsh target arun /bin/newfs /dev/rrd0a started aid = 22 /dev/rrd0a: 32768 sectors in 8 cylinders of 1 tracks, 4096 sectors 16MB in 1 cyl groups (16 c/g, 32MB/g, 7680 i/g) super-block backups (for fsck -b #) at: 32, $ rsh target arun /bin/fsck -y /dev/rrd0a started aid = 22 ** /dev/rrd0a ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 1 files, 1 used, 15390 free (14 frags, 1922 blocks, 0.1% fragmentation) |
Once you have checked the new file system and it is ready to use, mount it in the current file system hierarchy. As the current root file system is located on the host workstation, create the mount point on the host and then mount the RAM file system there:
$ cd target_root_dir $ mkdir ram $ rsh target mount -t ufs /dev/rd0a /ram /dev/rd0a on /ram |
Next, populate the RAM file system with the contents of all file systems except the /dev, /image, /tmp and /ram directories. Create mount points for the /dev, /image and /tmp file systems:
$ rsh target arun /bin/cp -R bin etc lib ram/ started aid = 22 $ rsh target arun /bin/mkdir /ram/dev $ rsh target arun /bin/mkdir /ram/image $ rsh target arun /bin/mkdir /ram/tmp |
The RAM file system, mounted under the /ram directory, now contains everything needed
to serve as the main system disk. Take advantage of the fact that the mount command is built into the C_INIT
system actor.
Unmount the root file system.
The following commands unmount the root file system on the target and remount the RAM file system in its place:
$ rsh target umount /ram $ rsh target umount / $ rsh target mount -t ufs /dev/rd0a / $ rsh target arun /bin/fsck /dev/rrd0a $ rsh target mount -t ufs -o update /dev/rd0a / |
The target is now independent of the host, using the RAM disk as the main disk:
$ rsh target arun /bin/ls started aid = 22 bin dev etc image lib tmp |
Note that the ls actor used above is located in the RAM disk file system.
The following script is meant to run on the host workstation (or other system) and summarizes the above scenario:
#!/bin/sh # # Reboot the target and give it some time to come up. # rsh target reboot sleep 60 # # While the host 'sleeps', the target downloads the system image, and # executes system initialization commands in sysadm.ini, mounting # the root file system through NFS. # # # Label the RAM disk, then create the file system and check it. # rsh target arun /bin/disklabel -w -r rd0 rd16Meg MyRamDisk rsh target arun /bin/newfs /dev/rrd0a rsh target arun /bin/fsck -y /dev/rrd0a # # Mount the RAM file system and populate it with the rest of the root # directory. # rsh target mount -t ufs /dev/rd0a /ram rsh target arun /bin/cp -R bin etc lib ram/ rsh target arun /bin/mkdir /ram/dev rsh target arun /bin/mkdir /ram/image rsh target arun /bin/mkdir /ram/tmp # # Unmount everything, then mount the RAM file system at the root. # rsh target umount /ram rsh target umount / rsh target mount -t ufs /dev/rd0a / rsh target arun /bin/fsck /dev/rrd0a rsh target mount -t ufs -o update /dev/rd0a /
After adapting the above script for your environment, run it to make your ChorusOS target self-sufficient.
If your ChorusOS system has a hard disk drive that you want to use to support a local file system, you can use the ChorusOS system utilities to prepare the disk, and create and populate a local file system. It is assumed that you have already been able to mount a root directory through NFS. See "6.1 Mounting a Root File System over NFS" for details. It is also assumed that no valuable data has been written to the disk. If you have important data on the hard disk, you must back it up before trying this example.
Before you can prepare the disk, you must be able to access it. Set the appropriate feature or features, depending on whether the hard disk is an IDE or SCSI disk and depending on what file system type you plan to use (see Step 2 for details), build the new system image that supports a hard disk and reboot the target system with the new system image. For example, if you are using TFTP to download onto a target with an IDE disk, then you might do so as follows:
$ cd build_dir $ configurator -c conf/ChorusOS.xml -set IDE_DISK=true $ configurator -c conf/ChorusOS.xml -set UFS=true $ make chorus $ cp chorus.bmon /tftpboot $ rsh target reboot |
The default sysadm.ini(4CC) system initialization file contains commands that create special files for both IDE and SCSI disks, so you probably do not need to create any special files at this point.
In order to label the disk, you first need an appropriate entry in disktab(4CC). The following example disktab fragment could be used with an ST34311A IDE disk to create two partitions, one small and one large:
ST34311A:\ :dt=ST506:ty=fixed:se#512:nt#15:ns#63:nc#8944:sf \ :pa#60480:oa#0:ta=4.4LFS: \ :pb#8391600:ob#60480:tb=4.4LFS: \ :pc#8452080:oc#0:tc=unused:
The following step in this example initializes the disk, erasing all existing data. Be sure to back up existing data on the disk before proceeding.
Once the disktab file contains the entry describing the disk geometry, you can proceed to label the disk. For example:
$ rsh target arun /bin/disklabel -w -r hd0 ST34311A |
After the disk is labelled, you can create file systems on the disk partitions:
$ rsh target arun /bin/newfs /dev/rhd0a $ rsh target arun /bin/newfs /dev/rhd0b |
Finally, before using the file systems, you should check them:
$ rsh target arun /bin/fsck -y /dev/rhd0a $ rsh target arun /bin/fsck -y /dev/rhd0b |
After you have checked the file systems you created, you can mount them into your existing file system hierarchy and use them.
If your ChorusOS system has a local file system, you may want to export part of it through NFS to share files with other systems on the network. For the following example, it is assumed that you want to export file systems and that you have already been able to create a local file system in RAM. See "6.2 Making a RAM Disk the Main System Disk" for details.
Before you can use the ChorusOS system as an NFS server, you must set the appropriate features and tunables. For example, if you are using TFTP to download onto target, then you might do so as follows:
$ cd build_dir $ configurator -c conf/ChorusOS.xml -set NFS_CLIENT=true $ configurator -c conf/ChorusOS.xml -set UFS=true $ configurator -c conf/ChorusOS.xml -set NFS_SERVER=true $ configurator -c conf/ChorusOS.xml -set iom.kmemsize=0x80000 $ configurator -c conf/ChorusOS.xml -set iom.nbuf=8 $ make chorus $ cp chorus.bmon /tftpboot $ rsh target reboot |
Note that you can export only UFS file systems through NFS.
Once the ChorusOS system has support for NFS, you must configure at least /etc/exports for the target system:
# # Export everything to everyone. # / -alldirs -maproot=0:1
The directory you export must be local to the ChorusOS system. From this point on, it is assumed that you have already populated a local device file system. Again, see "6.2 Making a RAM Disk the Main System Disk" for an example of how to prepare a local RAM disk file system for use as the root file system.
The following commands enable name services, portmapping, the mountd daemon and three NFS servers for UDP and TCP clients. The name service is optional, but useful. The other services are required to provide NFS services.
$ rsh target arun /bin/inetNShost& $ rsh target arun /etc/portmap& $ rsh target arun /etc/mountd& $ rsh target arun /etc/nfsd -ut -n 3& |
At this point, you can mount the target system root directory on another system, such as the host workstation or another target. The following commands mount the file system on the host workstation:
$ su Password: root_password # mount target:/ /mnt |
You may also choose to mount the exported ChorusOS system directories from other target systems, for example.
The following example sets up a swap partition on a local IDE disk. It is assumed that you have already successfully completed "6.3 Creating a File System on a Target System Hard Disk" and that your system is properly configured to support UFS file systems on the hard disk. It is also assumed that no valuable data has been written to the disk. If you have important data on the hard disk, you must back it up before trying this example.
Before you can activate swap on the disk, you must configure the system image to support the virtual memory. Following "6.3 Creating a File System on a Target System Hard Disk", you can do so as follows:
$ cd build_dir $ configurator -c conf/ChorusOS.xml -set ON_DEMAND_PAGING=true $ configurator -c conf/ChorusOS.xml -set VIRTUAL_ADDRESS_SPACE=true $ configurator -c conf/ChorusOS.xml -set FS_MAPPER=true $ make chorus $ cp chorus.bmon /tftpboot $ rsh target reboot |
For the purposes of this example, it is assumed that the hard disk is bare and that you need to start by labelling the disk. In order to label the disk, you must first create an appropriate entry in disktab(4CC). The following example disktab fragment can be used with an ST34311A IDE disk to create two partitions, one small swap partition and one large partition to house a UFS file system:
ST34311A_S:\ :dt=ST506:ty=fixed:se#512:nt#15:ns#63:nc#8944:sf \ :pa#60480:oa#0:ta=swap: \ :pb#8391600:ob#60480:tb=4.4LFS: \ :pc#8452080:oc#0:tc=unused:
Once the disktab file contains the entry describing the disk geometry, you can proceed to label the disk. For example:
$ rsh target arun /bin/disklabel -w -r hd0 ST34311A_S |
After the disk is labelled, create a mount point for the swap partition, mount the partition as type swap and activate it:
$ cd target_root_dir $ mkdir swap $ rsh target mount -t swap /dev/rhd0a /swap $ rsh target swapon /swap |
The swap partition is now active.