InnerhalbNach weiteren Dokumenten suchenSupport-Ressourcen |  Dieses Buch im PDF-Format herunterladen (128 KB)
Chapter 6 ExamplesThis chapter offers concrete examples showing how to:
6.1 Mounting a Root File System over NFSThe 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:
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:
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:
You can then verify that the directory is indeed available:
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
Make sure that the ChorusOS system can act as an NFS
client by setting the
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:
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:
6.2 Making a RAM Disk the Main System DiskYou 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:
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:
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:
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:
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 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:
The target is now independent of the host, using the RAM disk as the main disk:
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. 6.3 Creating a File System on a Target System Hard DiskIf 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:
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:
 Caution - 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:
After the disk is labelled, you can create file systems on the disk partitions:
Finally, before using the file systems, you should check them:
After you have checked the file systems you created, you can mount them into your existing file system hierarchy and use them. 6.4 Setting Up an NFS Server on the Target SystemIf 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:
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 Note - 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.
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:
You may also choose to mount the exported ChorusOS system directories from other target systems, for example. 6.5 Creating and Activating a Swap PartitionThe 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:
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:
After the disk is labelled, create a mount point for the swap partition, mount the partition as type swap and activate it:
The swap partition is now active. |
||||||||||||||||||||||||
|