ChorusOS 5.0 System Administrator's Guide

Part II File System Administration for ChorusOS 5.0

This part of the ChorusOS 5.0 System Administrator's Guide contains information relating to the administration and management of the ChorusOS 5.0 file system.

It provides further detail on system image configuration, and on

setting up devices attached to the ChorusOS system to support file systems.
running NFS services on the ChorusOS system.
mounting and unmounting file systems on the ChorusOS system.
related tasks.

Chapter 3 Introduction to ChorusOS File System Administration

This chapter describes how to set up and use local and network file systems supported by the ChorusOS operating system.

Note -

In order to include file system support in your ChorusOS system, you must install the C_OS component of the ChorusOS product during installation on the host workstation. You must also configure(1CC) the host workstation directory where you build system images to include binaries from the C_OS component.

It is assumed that you build file I/O support and the C_INIT(1M) actor into your system image.

System Initialization overview

The C_INIT(1M) actor plays an important role in the part of system initialization that concerns file systems.

When a ChorusOS system is booted, the C_INIT(1M) actor creates a virtual root file system in order to be able to create two directories, /dev and /image. The role of these directories is as follows:

/dev

Contains special files.

The C_INIT(1M) actor mounts a pseudo file system in the /dev directory and populates this file system with special file nodes.

It does this even when no real file system, such as an NFS, UFS, or MS-DOS file system, is mounted. In fact, as physical device drivers in this release are managed at the level of the board support package (BSP) framework, it is necessary to link device drivers in some way into the input/output manager (C_OS) subsystem. Also, each driver managed by the C_OS component must be bound to the underlying physical device managed by the BSP.

In order to bind drivers managed by the C_OS component with physical devices managed by the BSP, the system needs to determine which drivers correspond to which devices. C_INIT(1M) therefore scans both the device tree built at boot time by the microkernel, and the system initialization script, sysadm.ini(4CC). Based on the information from the device tree and the system initialization script, C_INIT(1M) informs the C_OS component about the correspondence between device names and physical devices. C_INIT(1M) also creates the appropriate device nodes in the /dev directory.

/image

Contains the boot system image.

This makes it possible to execute actors included in the system image dynamically. This also makes it possible to store configuration files needed by actors loaded at boot time, such as sysadm.ini(4CC), which is used by C_INIT(1M).

The boot image is mounted as an MS-DOS file system.

File System Commands

The following list explains the file system commands presented, and includes a brief description of df(1CC) and flashdefrag(1M).

disklabel: Writes disk geometry and other information to a disk attached to the target system.
df: Displays information about file system use such as total file system size, available space, inodes used and inodes available.
flashdefrag: Defragments a Flash memory device attached to the target system.
format: Formats a Flash memory device attached to the target system.
fsck: Checks the integrity of a UFS file system and attempts to fix any errors it finds.
fsck_msdos: Checks the integrity of an MS-DOS file system and attempts to fix any errors it finds.
mknod: Creates a special device driver file corresponding to a device attached to the ChorusOS system.
mount: Mounts a file system at a specified mount point in the existing file system hierarchy.
newfs: Writes a UFS file system structure to a labelled disk attached to the target system.
newfs_msdos: Writes an MS-DOS file system structure to a labelled disk attached to the target system.
swapon: Activates a local swap partition that you have mounted.
umount: Removes a mounted file system from the file system hierarchy.

File System Initialization

File system initialization proceeds in the following manner. After creating the pdevfs file systems, C_INIT(1M) creates a /dev/console device to which it writes system console messages. It then creates the other special files that correspond to the devices attached to the device tree. It also creates special files to access the memory banks and mounts the contents of the system image in /image/sys_bank as a FAT file system. It mounts other memory banks under /image/bank_identifier as well, if others are available. Thus, several file systems are mounted immediately after the system comes up, by the system itself:

$ rsh target mount
root_device on / (pdevfs)
pdevfs on /dev (pdevfs)
pdevfs on /image (pdevfs)
/dev/bd00 on /image/sys_bank (msdos)

Next, C_INIT(1M) looks for sysadm.ini(4CC), the system initialization file. Usually, it finds the system initialization file in /image/sys_bank/sysadm.ini, although it does this by probing the memory banks for the file and using the first instance it finds. (If it finds more than one sysadm.ini file, it displays a warning on the system console.) Finally, C_INIT(1M) executes the commands it finds in sysadm.ini, such as commands to set up network connections and commands to create special files for access to local media, such as hard disks, RAM disks and flash memory.

At this point, you may mount a root file system containing actors to run on the target system. You do this without unmounting the pseudo root node. The ChorusOS system allows you to mount a new root while the pseudo root is still mounted.

Unless you build everything into your system image or mount a root directory on a local device connected to the target system, you probably mount build_dir/root on the host workstation as the root directory for your target system. You generate this directory on the host workstation using the make root command in the directory where you build system images.

The command to mount the root file system is usually included in the sysadm.ini(4CC) file. The following example demonstrates what happens, however, when you mount a new root file system manually after having exported it through NFS from a host workstation:

$ rsh target mount
root_device on / (pdevfs)
pdevfs on /dev (pdevfs)
pdevfs on /image (pdevfs)
/dev/bd00 on /image/sys_bank (msdos)
$ rsh target mount host_IP_address:/export/target/root /
host_IP_address:/export/target/root on / (nfs)
$ rsh target mount
root_device on / (pdevfs)
pdevfs on /dev (pdevfs)
pdevfs on /image (pdevfs)
/dev/bd00 on /image/sys_bank (msdos)
host_IP_address:/export/target/root on / (nfs)
$ rsh target ls /

Makefile        bin             etc             dev            image
lib             tmp
$ rsh target umount /
$ rsh target mount
root_device on / (pdevfs)
pdevfs on /dev (pdevfs)
pdevfs on /image (pdevfs)
/dev/bd00 on /image/sys_bank (msdos)

See the host workstation documentation for details about sharing this directory through NFS. If your host workstation is running the Solaris^TM operating environment, you can use the share(1M) command to share the file system.

Initialization Examples

These are typical commands of the sysadm.ini file.

Associate ifnet interface 0 to a specific Ethernet driver:
% mkdev ifeth 0 /pci/epic/epic100
The pathname is optional. For more information, refer to mkdev(1M).

Note -
In the ChorusOS operating system, hardware devices are identified by a path in a device tree; the mkdev command connects to the driver instance servicing the indicated hardware device.
Associate ifnet interface 0 to the first Ethernet driver found:
% mkdev ifeth 0

Define the IP address of ifnet interface 0:

% ifconfig ifeth 0 ip-address netmask ip-mask broadcast broadcast-addr

Define the IP address using the rarp protocol on ifnet interface 0:
% rarp ifeth 0
Associate a special device to a serial line driver:
% mknod /dev/tty01 c 0 0 % mkdev tty 0 /pci/pci-isa/ns16550-2
The third argument to mknod, 0, is the major device number identifying the serial line driver. The fourth argument to mknod, 0, is the minor device number identifying the hardware device at the POSIX level.

Mount a local file system by defining required devices, then mount the disk:

% mknod  /dev/sd0a    b  10   0
% mknod  /dev/rsd0a   c  9    0 
% mount  /dev/sd0a  /

Mount a remote file system:
% mount host-ip-addr:host-path /

Managing File Systems

You should understand in advance what you must do to set up file systems on a ChorusOS system and in what order to perform the necessary steps. The following list summarizes the stages of file system administration for ChorusOS systems.

Configuring the system image

You must include support for file systems in the system image in order to use the functionality described in this guide. Configuring the system image for file system support involves setting features and tunables to support the media and file system types you want to use, editing the built-in system initialization script to create special files for accessing the media, and then rebuilding the properly configured system image for use on the ChorusOS target system.

This stage is generally completed only once for a given system.
Preparing local media

Local media must be labelled in order to support file systems. If you have local flash memory, it must also be formatted before it is labelled.

This stage is generally completed only once for each device.
Creating file systems

You create new file systems on the available partitions on local media. This involves writing file system structures to devices attached to the ChorusOS system.

This stage is generally completed only once for a given system.
Checking and mounting file systems

Before mounting a local file system, you check it for errors. After the check is complete and any errors in the file system have been repaired, you mount the file system into the file system hierarchy. If the file system is being mounted over the network through NFS, you mount it without performing a check. Once mounted, the contents of the file system are available for use.

This stage is performed each time you use a file system.
(Optional) Exporting local UFS file systems through NFS

If you have local UFS file systems that you want to make available over the network, you export them through NFS. This stage involves editing several configuration files and starting the daemon actors that make your target system an NFS server. This guide assumes you have a working network connection that makes exporting through NFS possible.

File system export is often set up only once for a given system. Daemons may be started as part of system initialization.
(Optional) Unmounting file systems

If you need to remove a file system from the hierarchy, you unmount it. This stage may be performed during normal system use, but is usually performed as part of system shutdown.

This section of the ChorusOS 5.0 System Administrator's Guide includes instructions to guide you through each of these stages in the process of managing file systems.

Chapter 4 Configuring the System Image with File System Support

This chapter explains how to set up and support file systems and related hardware.

Note -

Before attempting to configure any of the features and tunables described here, check that they are supported by your target ChorusOS system. Consult the appropriate document in the ChorusOS 5.0 Target Platform Collection to determine which features and tunables your target version supports.

For descriptions of available features and tunables, see "Configuration Options". For more details concerning features, see ChorusOS man pages section 5FEA: ChorusOS Features.

Supported Systems

This section reviews the file systems and related media supported for the ChorusOS operating system. As stated in the note, support for specific ChorusOS file systems and hardware devices depends on the target family.

Supported Media

The ChorusOS product supports the following hardware, although not necessarily for all target platforms:

Flash memory: Flash device support is implemented using Flite 1.2. Flash support allows you to use only MS-DOS file systems on supported flash devices.
IDE hard disk drives: Supported hard disk drives must be connected to an IDE, ST506 or ESDI compatible disk controller.
RAM disk memory: RAM disk support allows you to create disk-like entities and use file systems in random-access memory.
SCSI hard disk drives: Selected SCSI hard disk drives and SCSI-PCI I/O processors of the NCR53C8xx family are supported.
SCSI CD-ROM drive: SCSI CD-ROM disk drives are supported.

The ChorusOS file system requires that you use special device driver files to read from and write to these devices. See "Special Device Driver Files" and special(7S) for details.

Supported File Systems

The ChorusOS product supports the following file systems, although not necessarily for all target platforms:

Network File System (NFS): NFS is the standard among UNIX operating systems for sharing file systems over the network. ChorusOS systems can support both NFS client access to shared file systems and NFS server capabilities to share local file systems with other systems on the network.
File Allocation Table (FAT) File System: Also known as the MS-DOS file system, this supports file allocation tables with 12, 16 or 32-bit entries, making it possible to support long file names.
UNIX File System (UFS): Also known as the Fast File System, this supports long file names and links, and is the required type for file systems exported through NFS.
ISO 9660 File System: The ChorusOS product supports the use of the ISO 9660 file system.
Swap File System: The ChorusOS product also supports the use of a swap partition on supported local hardware devices.

The following table summarizes which file systems are supported for which media.

Table 4-1 File System Support By Media


	MS-DOS	UFS	Swap	ISO 9660
Flash	X
IDE	X	X	X
RAM disk	X	X
SCSI	X	X	X
CD-ROM				X

Adding Support for File Systems and Related Hardware to your System Image

Adding Support Using the Graphical User Interface Tool Ews

To configure your system image with support for file systems and related hardware through the Ews graphical user interface, follow this procedure:

Open your system image configuration in ews:

host% cd build_dir
host% ews conf/ChorusOS.xml &

Use the hints in the following tables to set features and tunables for the file system support needed.

The following table lists the feature and tunable settings required for your ChorusOS system to support the media on which you use file systems.

Table 4-2 Media Support


To include support for...	Set...	Comments
Flash memory	FLASH=true	Flash memory supports only FAT (MS-DOS) file systems.
IDE hard disk drives	DEV_DISK=true	Enables support for hard disk drives connected to compatible IDE, ST506 and ESDI controllers.
RAM disk memory	RAM_DISK=true iom.ramdisk`X`.size=`size_in_hex` iom.ramdisk.sizeMax= `max_RAM_disk_size`	iom.ramdisk`X`.size, where `X` is a hexadecimal digit `0`, `1`, `2`, ..., `d`, `e`, `f`, takes a size in the same hexadecimal format as the value for iom.ramdisk.sizeMax. For example, if you want to have one 4MB RAM disk use iom.ramdisk0.size= 0x40000.
SCSI hard disk drives	SCSI_DISK=true	Enables support for SCSI-PCI I/O processors of the NCR53C8xx family.
SCSI CD-ROM disk drives	DEV_CDROM=true	Enables support for SCSI CDROM drives.

The following table summarizes the feature and tunable settings required for your ChorusOS system to support specific file systems.

Table 4-3 File System Support


To include support for...	Set...	Comments
FAT (MS-DOS) file systems	MSDOSFS=true iom.nbuf=8 (at least)
NFS client capability (for mounting NFS file systems)	NFS_CLIENT=true iom.nbuf=8 (at least)
NFS server capability (for exporting file systems)	NFS_CLIENT=true NFS_SERVER=true iom.nbuf=8 (at least)	The ChorusOS system can export only local UFS file systems through NFS. MS-DOS file systems cannot be exported through NFS.
Swap file system	FS_MAPPER=true ON_DEMAND_PAGING= true (except for PowerPC target family architectures)	Swap may only be used on local media. Only one swap device may be used. Swap is only available in the VM memory model, where VIRTUAL_ADDRESS_SPACE =true.
UNIX (UFS) file systems	UFS=true iom.nbuf=8 (at least)	UFS file systems cannot be used on flash media.
ISO 9660	ISOFS=true iom.nbuf=8 (at least)	File System used on CD-ROM media

The iom.nbuf tunable sets the number of buffer cache entries. These are the standard buffered entries used for input and output. The larger the value, the larger the cache available. The iom.nbuf tunable, and other tunables, influence the amount of RAM used by the system.

The iom.kmemsize tunable sets the amount of memory available to the microkernel through kmemalloc.

The iom.clusterssize and iom.nmbufs set the number of clusters and mbufs used for networking. The larger the value, the larger the number of network requests that can successfully be satisfied.

Save your changes to the system image configuration.

Build the system image.

Adding Support Using Configurator on the Command-Line

To configure your system image with support for file systems and related hardware through the configurator(1CC) command-line interface, follow this procedure:

Change to the directory where you build system images:
host% cd build_dir

Use the hints in the tables provided (see Step 2) to set features and tunables for the file system support needed.

configurator(1CC) commands to set features and tunables take the form:
host% configurator -c conf/ChorusOS.xml -set feature | tunable=value

Build the system image to include the modifications you have made:
host% make system_image_name

Special Device Driver Files

This section reviews the special device driver files required for file system support.

If your target is an NFS client only (all its files are physically located on another system, such as the host workstation), you can skip this section.

What Special Files Are

The ChorusOS system requires you to use special(7S) device driver files to access the hardware devices where file systems reside. This means that disk labeling and other operations on uninitialized and unmounted file systems must be done using special files.

Each disk partition corresponds to at least one special file. Unless you plan to use a raw partition directly -- without a file system-- you must be able to access each partition in both block (buffered) mode and raw (character) mode, so you must create not just one special file per partition, but two. Each special file:

Refers to either a block or a raw device. Block devices are used by file systems. Raw devices are used primarily for file system administration.
Has a major number. Major numbers are used by the system to select the corresponding device driver when several devices are configured. Major numbers are the same for all devices managed by a given device driver and a given access method (raw or block). For example, all devices corresponding to hard disk partitions using raw mode have the same major number.
Has a minor number. Minor numbers are not used directly by the system, but by the selected device driver. Minor numbers are different for each partition on a device. Their scope is limited to the device described by the major number, so special files with different major numbers may share the same minor number. One minor number corresponds to one partition.

Naming Conventions for Special Files

Special files normally reside in the /dev directory, which is mounted at boot time. By convention, special file names follow the form /dev/rsuffix for raw (character) mode and /dev/suffix for buffered (block) mode. See also "Supported Devices".

The suffix is made up of:

A string of letters referring to the device driver name, such as sd for a SCSI disk, rd for a RAM disk, hd for an IDE disk or flash for flash,
Followed by a digit representing the disk unit number, such as 0, 1, 2 and so forth (except for special files not related to file systems, such as tty device files),
Terminated by a single letter referring to the partition, such as a, b, ... h.

Caution -

Special care must be taken with partition c. Partition c represents the whole disk and therefore must not be used to support a file system.

Because file systems are based on BSD 4.4 as implemented in FreeBSD 4.1, the same limitations found in FreeBSD 4.1 apply to ChorusOS file system management. According to limitations imposed by FreeBSD, a disk can be divided into a maximum of eight different partitions for IDE and SCSI devices, two partitions for RAM and flash devices. Partitions can be left undefined. Partitions are named using a single character in the range from a to h, each letter corresponding to one of the eight partitions for IDE and SCSI devices. For RAM and flash devices, only partitions a and c are available.

Note -

The ChorusOS operating system differs from FreeBSD 4.1 in that the latter does not distinguish between raw devices and block devices. With the ChorusOS operating system both forms of special files are retained for backward compatibility. It is recommended to use the block device.

Creating Special Files

You create special files using mknod(1M) on the ChorusOS system. Generally, you create the special files you need at boot time by including commands in the system initialization file, sysadm.ini(4CC).

Note -

Unlike earlier releases that used special device driver files created on the host, the ChorusOS operating system only lets you create special files on the target.

Previous releases allowed you to create special files on the host because no /dev directory was available at boot time. As the ChorusOS product mounts a /dev directory at boot time, it is no longer necessary to create special files on the host.

Creating Special Files at Boot Time

To create special files at boot time using the sysadm.ini(4CC) file embedded in the system image, follow this procedure:

Change to the directory containing sysadm.ini:
host% cd build_dir/conf

Include commands of the following form in sysadm.ini using the C_INIT(1M) built-in command mknod(1M):

mknod /dev/name [b|c] maj_nbr min_nbr

where name follows the pattern described in "Naming Conventions for Special Files", b represents a buffered (block) device, c represents a character (raw) device, maj_nbr is the major number of the device and min_nbr is the minor number of the partition on the device. The following table lists memory devices by major number:

Major Number	Device	Mode
3	ISA/IDE disk	character (raw) and block (buffered)
4	CD_ROM disk	character (raw)
7	Flash device	character (raw) and block (buffered)
9	SCSI disk	character (raw) and block (buffered)
13	RAM disk	character (raw) and block (buffered)
15	SCSI CD-ROM	character (raw)
23	BPF	character (raw)
24	NVRAM	character (raw)

Note that RAM disk devices used for memory banks conventionally have major numbers 11 and 12 and are used internally by the system to make the contents of the memory banks, including the system image, available for use at boot time.

Build the system image to include modifications to sysadm.ini:
host% cd .. host% make system_image_name

Creating Special Files Manually

To create special files manually on a running ChorusOS target system:

Run commands on the target of the type:

host% rsh target mknod dev/name [b|c] maj_nbr min_nbr

Where name follows the pattern described in "Naming Conventions for Special Files", b represents a buffered (block) device, c represents a character (raw) device, maj_nbr is the major number of the device and min_nbr is the minor number of the partition on the device.

Chapter 5 Setting Up File Systems on the Target

This chapter explains how to set up file systems on devices physically attached to the target system, such as Flash memory, IDE disks, RAM disks and SCSI disks. If your target is an NFS client only (all its files are physically located on another system such as the host), you do not need to read this chapter.

Before you can perform the procedures in this chapter, you must first configure the system image. See "Configuration Options" and Chapter 4, Configuring the System Image with File System Support for details.

You must also boot the new system image on the target, and mount the root file system where many of the useful actors reside. This usually involves mounting a file system located on the host workstation where you built the system image. See "Mounting an NFS File System" for details.

Setting up file systems on the target involves:

Preparing the media on which you will use file systems.

If the media used is flash memory, you must first format(1M) the flash device.

You must label the media using the disklabel(1M) utility, which writes partition information onto the media based on entries in the disktab(4CC) file.
Creating file systems on the media.

The newfs(1M) and newfs_msdos(1M) utilities let you create an MS-DOS file system.

The utility lets you create a UFS file system.
Checking file system integrity.

The fsck_msdos(1M)utility lets you check an MS-DOS file system.

Thefsck(1M) utility lets you check a UFS file system.

Formatting a Flash Memory Device

You must format flash memory before you can label it. If your target does not have flash memory, you do not need to read this section.

Caution -

The following procedure initializes the Flash memory device, erasing all existing data. Be sure to back up existing data on the device before proceeding.

Formatting a Flash Memory Device

Make sure that you have configured your system image with the FLASH feature set to true:

host% cd build_dir
host% configurator -list features | grep FLASH
FLASH bool 'true'

Reboot the target system with a system image that supports Flash memory and includes the special files needed to access it.

Format the Flash memory using the format(1M) command:
host% rsh target format /dev/rflash0a

Labeling a Disk

This section describes how to label a disk using information in /etc/disktab and the disklabel utility.

Labeling consists of writing specific information, such as disk geometry in terms of cylinders, heads, sectors per track and partition overlays, at particular locations on the disk. Disk drivers use labeling information to access different areas of the disk, called partitions.

You can also use the fsck(1M) utility on PC/AT platforms to create 'slices' (DOS partition) if you want to share the disk with other operating systems. In this case disklabel partitions are created within those slices. See also fsck_dos(1M) and fsck_msdos(1M).

Setting Up Information About Disk Geometry

Information about disk geometry is found in /etc/disktab, which disklabel reads before writing a label to a drive. The ChorusOS operating system provides a sample /etc/disktab that contains several useful examples. The following key to the abbreviations used in /etc/disktab is included at the top of the file:

#
# Disk geometry and partition layout tables. 
# Key:
#
#   dt      controller type
#   ty      type of disk (fixed, removeable, simulated)
#   d[0-4]  drive-type-dependent parameters
#   ns      #sectors/track
#   nt      #tracks/cylinder
#   nc      #cylinders/disk
#   sc      #sectors/cylinder, ns*nt default
#   su      #sectors/unit, sc*nc default
#   se      sector size, DEV_BSIZE default
#   rm      rpm, 3600 default
#   sf      supports bad144-style bad sector forwarding
#   sk      sector skew per track, default 0
#   cs      sector skew per cylinder, default 0
#   hs      headswitch time, default 0
#   ts      one-cylinder seek time, default 0
#   il      sector interleave (n:1), 1 default
#   bs      boot block size, default BBSIZE
#   sb      superblock size, default SBSIZE
#   o[a-h]  partition offsets in sectors
#   p[a-h]  partition sizes in sectors
#   b[a-h]  partition block sizes in bytes
#   f[a-h]  partition fragment sizes in bytes
#   t[a-h]  partition types (file system, swap, etc)
#
# All partition sizes reserve space for bad sector tables.
# 5 cylinders are needed for maintenance including
# replacement sectors.
#
...

Entries in /etc/disktab consist of fields separated by colons (":") and follow the form:

label:option[=value|#value]...

Where label is a string identifier up to eight characters long with no whitespace, option is an option from the list of abbreviations above, and value is the value assigned to an option.

For detailed examples, see the root/etc/disktab file generated using make root in the build_dir directory where you build system images. Note that build_dir/root is normally the directory exported for use as the target root directory. See "Mounting an NFS File System" for details.

If you are unable to complete the disk geometry fields, boot the ChorusOS system image on the target system, and read the output concerning the disk driver displayed on the system console at boot time.

Using `disklabel` to Label a Disk

Once you have correctly specified disk information in /etc/disktab, you are ready to use disklabel.

Caution -

The following procedure initializes the local disk, erasing all existing data. Be sure to back up existing data before proceeding.

Boot the target system with a system image that supports the hardware you want to label and that includes the special files needed to access that hardware.

Update the disk label on the device, using disklabel as follows:
host% rsh target disklabel -w -r device label name
where device is an abbreviated form of the device name such as da0, label is the label found in /etc/disktab and name is an optional string identifier up to sixteen characters long with no whitespace.

Check that the disk label is correctly updated, using disklabel as follows:
host% rsh target disklabel -r device
where device is an abbreviated form of the device name such as da0.

Another way of using disklabel is with a protofile. A protofile is a text file describing one single disk and has the same format as the output of a simple disklabel disk.

For instance, to create a single partition on a new disk, you can type the following :

rsh target disklabel device > root/tmp/device_proto  
rsh target disklabel -R -r device /tmp/device_proto

If device is da0, for instance, this will create a single partition da0c that can be used with newfs:

rsh target newfs /dev/da0c

Of course, you can edit and modify the device_proto file between both of these operations to create additional partitions.

Creating a File System

This section explains how to create a file system on a disk. If you plan to use the disk partitions in raw mode and do not need a file system, you do not need to read this section.

Once the disk has been labelled, you can write a UFS or MS-DOS file system structure to any partition you have defined for the disk, except partition c.

Creating a UFS File System

Create the file system using the newfs command as follows:

host% rsh target newfs raw_device

where raw_device is a raw mode special file indicating a partition such as /dev/rda0a.

Creating an MS-DOS File System

Create the file system using the newfs_msdos command as follows:

host% rsh target newfs_msdos raw_device

where raw_device is a raw mode special file indicating a partition such as /dev/rhd0a.

Example 5-1 Creating a File System on a RAM Disk

You can pass extra parameters to newfs or newfs_msdos when creating a file system on a RAM disk in order to maximize available space. The following command could be used (on BSD type file systems only) to maximize space available on a 1 MB RAM disk:

host% rsh target newfs -o space -c 26 -m 0 /dev/rd0a

Note -

See "Activating a Swap Partition" for details on activating a swap partition.

Checking File System Integrity

This section explains how to check existing file systems for errors.

Note -

Before mounting a local file system with read-write access or as the root file system, and after any system crash, it is strongly recommended that you check the file systems you plan to mount.

Checking a UFS File System

Check the file system using the fsck command as follows:

host% rsh target fsck raw_device

where raw_device is a raw mode special file indicating a partition such as /dev/rda0a.

Checking an MS-DOS File System

Check the file system using the fsck command as follows:

host% rsh target fsck_msdos raw_device

where raw_device is a raw mode special file indicating a partition such as /dev/rhd0a.

If no errors are found, both fsck and fsck_msdos display information on the file system in use. In case of errors, both fsck and fsck_msdos attempt a recovery procedure, optionally requiring confirmation. If you want to run either command in non-interactive mode, use the -y option.

Chapter 6 Mounting and Unmounting File Systems

This chapter explains how to mount and unmount file systems.

Before you can use most of the procedures described in this chapter, you must first configure your hardware, system image and environment as described in previous chapters.

File System Commands

The mount command, which is a C_INIT(1M) built-in command, allows you either to add a file system at a given point in an existing file system hierarchy, or to view all mounted file systems. Once mounted, a file system is fully operational. Applications can access it using the API provided.

The umount command, another C_INIT built-in command, allows you to remove one or more mounted file systems from the file system hierarchy.

Caution -

The default version of NFS is version 3. To use NFS version 2, ensure you use the option

-o -2 mount

to mount commands.

Mounting the Host File System

To be able to download actors that are to run dynamically, mount an NFS root file system on the target. This root file system can be generated in the ChorusOS operating system build directory by the command:

% make root

This command populates the build directory with the root directory that contains binary and configuration files to be accessed by the target system.

As explained, at start-up, the C_INIT daemon reads the sysadm.ini configuration file and executes all the commands. This configuration file may contain instructions to mount the root file system. For example:

% mount hostaddr:chorus_root_directory /

If there are no root file system mount instructions in your sysadm.ini file, mount the root file system explicitly from the shell:

% rsh target mount hostaddr:chorus_root_directory /

where target is the name of the target, or its IP address, hostaddr is the IP address of the NFS host in decimal form (for example 192.82.231.1), and chorus_root_directory is the path of the target root directory on the NFS host (for example /home/chorus/root).

A message is delivered by C_INIT that depends on whether the /etc/security file exists in the target root directory /home/chorus/root. If /etc/security exists, C_INIT displays:

C_INIT: system in secured mode

If /etc/security does not exist, C_INIT displays:

C_INIT: notice - system not in secured mode

You can check that the root file system is mounted using:

% rsh target mount

Make sure that the file system containing the /home/chorus/root directory can be accessed by NFS from the remote ChorusOS target.

Mounting an NFS File System

Mount the file system under mount_dir on the host at mount_point on the target system:

host% rsh target mount host:mount_dir mount_point

Example 6-1 Mounting a Root Directory through NFS

host% rsh target mount host:/export/chorus/root /

Mounts the ChorusOS root directory, /export/chorus/root, on host as the root directory on target.

Note -

In some cases, you may receive a Permission denied message when trying to mount an NFS file system.

$ rsh target mount 129.157.197.144:/export/chorus/root /
can't access /export/chorus/root: Permission denied

This is the default for NFS version 3. If you are using NFS version 2, this is:

$ rsh target mount -o -2 129.157.197.144:/export/chorus/root /
can't access /export/chorus/root: Permission denied

This could happen if the target system is not a member of a netgroup(4CC) that has at least read access to the NFS file system you want to mount. On a system running the Solaris operating environment, you can use share(1M) to see which netgroups have access to the shared file system:

$ rlogin 129.157.197.144
$ share
-               /export/chorus/root   rw=netgroup   ""

See your Solaris system administrator for details about adding a system to a netgroup. This is so that you can configure your NFS server on your Solaris station so that it recognises the target and accepts the target as a client. For further information, see "Remote File-System Administration" in System Administration Guide, Volume 3.

Mounting a UFS File System

Note -

When you mount a UFS file system as the root file system, mount first mounts the file system read-only. Next use fsck to check the file system. If the file system check finds and repairs errors, fsck then calls mount with the update option to mount the file system read-write. If the file system check terminates without finding any errors, call mount with the update option to mount the file system read-write

Mount the file system on the partition block_device on the host at mount_point:
host% rsh target mount -t ufs block_device mount_point

If you have mounted the file system as the root file system, check it using the fsck command:
host% rsh target fsck raw_device
where raw_device is a raw mode special file indicating the partition you mounted as the root file system.

Example 6-2 Mounting a UFS File System as the Root File System
host% rsh target mount -t ufs /dev/da0a / host% rsh target fsck /dev/rda0a host% rsh target mount -t ufs -o update /dev/da0a /
Mounts the UFS file system on the first partition on the first SCSI drive attached to the ChorusOS system, target, as the root file system.

Mounting an MS-DOS File System

Mount the file system on the partition block_device on the host at mount_point:

host% rsh target mount -t msdos block_device mount_point

Example 6-3 Mounting an MS-DOS File System as the Root File System

host% rsh target mount -t msdos /dev/hd0a /

target

Mounting an ISO 9660 File System

Note -

The ISO 9660 file system is used when mounting a CD-ROM. Its use is not, however, restricted to CD-ROM.

Mount the file system on the partition block_device on the host at mount_point:

host% rsh target mount -t cd9660 block_device mount_point

Example 6-4 Mounting an ISO 9660 File System as the Root File System

host% rsh target mount -t cd9660 /dev/cd0a /

target

Viewing all Mounted File Systems

Use the mount command without any arguments to view all mounted file systems:

host% rsh target mount

Unmounting a File System

Use the umount command to remove mounted_fs from the file system hierarchy:

host% rsh target umount mounted_fs

Managing the `/dev`, `/image` and `/tmp` File Systems

In order to mount the /dev, /image and /tmp file systems automatically, thus providing access to special files and the contents of the system image for example, the C_INIT(1M) actor must find /dev, /image and /tmp mount points in the root file system.

If you create a file system that does not include these mount points, and then mount that file system as root (/), your target system will not have access to special files in /dev, nor to the contents of the system image under /image. Furthermore, function calls that rely on the presence of /tmp will not complete successfully.

Therefore, you should make sure /dev, /image and /tmp mount points are available in each file system that you use as a root file system.

Create a temporary mount point for the file system that you want to use as a root file system and mount it.

For example, if you have mounted an NFS file system located on the host workstation as the root file system, and you want to use an empty, existing IDEdisk UFS file system as the root file system:
host% cd target_root_dir host% mkdir mnt_tmp host% rsh target mount -t ufs /dev/hd0a /mnt_tmp /dev/hd0a on /mnt_tmp

Create the /dev, /image and /tmp mount points:

host% rsh target mkdir /mnt_tmp/dev
host% rsh target mkdir /mnt_tmp/image
host% rsh target mkdir /mnt_tmp/tmp

Copy the /bin, /etc and /lib directories to the RAM disk file system:
host% rsh target cp -R bin etc lib mnt_tmp/

Unmount all file systems on the target, including the root file system:
host% rsh target umount /mnt_tmp host% rsh target umount /

Mount the UFS file system as the root file system and make sure that /dev, for example, is accessible:

host% rsh target mount -t ufs /dev/hd0a /
host% rsh target ls /dev
bd0a    hd0d   hd1g   hd3b   ptyp1   rhd0e  rhd1h  rhd3c  rda0c  da0f
bd0b    hd0e   hd1h   hd3c   rbflash rhd0f  rhd2a  rhd3d  rda0d  da0g
bd0c    hd0f   hd2a   hd3d   rcflash rhd0g  rhd2b  rhd3e  rda0e  da0h
bd0     hd0g   hd2b   hd3e   rd0a    rhd0h  rhd2c  rhd3f  rda0f  tty01
bpf0    hd0h   hd2c   hd3f   rd0b    rhd1a  rhd2d  rhd3g  rda0g  ttyp0
bpf1    hd1a   hd2d   hd3g   rd0c    rhd1b  rhd2e  rhd3h  rda0h  ttyp1
console hd1b   hd2e   hd3h   rflash  rhd1c  rhd2f  rrd0a  da0a   zero
flash   hd1c   hd2f   kmem   rhd0a   rhd1d  rhd2g  rrd0b  da0b
hd0a    hd1d   hd2g   mem    rhd0b   rhd1e  rhd2h  rrd0c  da0c
hd0b    hd1e   hd2h   null   rhd0c   rhd1f  rhd3a  rda0a  da0d
hd0c    hd1f   hd3a   ptyp0  rhd0d   rhd1g  rhd3b  rda0b  da0e

Mounting a Root File System over NFS

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. Further examples are provided in Chapter 8, Further File System Administration Examples .

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, move or copy it to a directory you can export:

$ cp -R build_dir/root exportable_dir

Next, 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, 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 C_OS 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

Build and 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  ls /bin
arp            domainname     ls             pax            tclsh 
chorusNSinet   fsck           mkdir          pppstart       touch 
chorusNSsite   fsck_dos       mkfifo         profctl        umount 
chorusStat     ftp            mknod          profex         uname 
cp             hostname       mount          rdbc           ypbind 
cs             ifconfig       mv             rm             ypcat 
date           inetNSdns      netstat        rmdir          ypmatch 
dd             inetNShost     newfs          route          ypwhich 
df             inetNSien116   newfs_dos      shutdown 
disklabel      inetNSnis      nfsstat        sysctl

Activating a Swap Partition

This section explains how to activate a swap partition on a local disk that has already been labelled. The ChorusOS product supports a single swap partition on a local disk, unlike earlier releases that supported swap over NFS.

In order to use a swap partition on a ChorusOS system, label the partition as a swap partition using disklabel. See "Using disklabel to Label a Disk". After the partition is labelled, mount a swap directory using the mount command. Finally, activate the swap partition using the swapon command.

Note -

Swap cannot be deactivated.

After you have performed the procedure once, you can mount and activate the swap partition during system intilization by including the necessary commands in the sysadm.ini file that you build into the system image.

Preparing and Activating a Swap Partition

Make a directory on the target to use as the mount point for the swap partition unless you have already done so:
$ rsh target ls swap_dir /swap_dir: No such file or directory $ rsh target mkdir swap_dir

Make sure the partition you intend to use for swap has been correctly labelled using disklabel. See "Using disklabel to Label a Disk".

The partition you intend to use for swap should be labelled as type swap.

Mount the swap directory:
$ rsh target mount -t swap block_special_file swap_dir
Where block_special_file represents the partition you labelled as type swap.

Activate the swap partition using the swapon(1M) command:
$ rsh target swapon swap_dir

A detailed example of creating a swap partition is also provided in "Creating and Activating a Swap Partition".

Chapter 7 Sharing Target File Systems Over NFS

This chapter explains how to set up an NFS server on the target system, allowing you to share files located on devices attached to the target with other systems on the network. If your target is an NFS client only (all its files are physically located on another system such as the host workstation), or if you do not intend to export target file systems, you can skip this chapter.

Before you can perform the procedures in this chapter, you must first configure the system image. See Chapter 4, Configuring the System Image with File System Support for details.

Note -

The NFS server can only export UFS file systems. For details about creating a UFS file system on the target, see Chapter 5, Setting Up File Systems on the Target.

For a detailed example, including instructions on setting the appropriate features and tunables, see "Setting Up an NFS Server on the Target System".

Setting Up the Target as an NFS Server

Setting up the target as an NFS server involves:

Editing the network and NFS configuration files, exports(4CC), hosts(4CC), networks(4CC) and netgroup(4CC).
Starting the inetNShost(1M) name server on the target.
Starting the NFS daemons, rpcbind(1CC), mountd(1M) and nfsd(1M), on the target.

A detailed example is provided in "Setting Up an NFS Server on the Target System".

Setting Up the Configuration Files

Unless you build the following files into your system image, they probably reside in build_dir/root/etc, which you generate using the make root command in the directory where you build system images.

Make sure /etc/exports specifies all the file systems located on the ChorusOS system that you plan to export through NFS. Entries in the /etc/exports file follow the form:
```
export_dir options
```
where export_dir indicates a file system to export, and options allows you to specify whether any directory under export_dir can be mounted by another system, which users, groups or netgroups have access to export_dir, whether the directory should be exported read-only and so forth. See exports(4CC) for details.

Make sure /etc/hosts contains the IP addresses and hostnames of NFS clients. Entries in the /etc/hosts file follow the form:
```
IP_address hostname [other_hostname ...]
```
where IP_address is the IP address of the system, hostname is the hostname of the system and other_hostnames are alternate hostnames. See hosts(4CC) for details.

Make sure /etc/netgroup is readable by everyone, and contains descriptions of all netgroups -- sets of hosts, users and domains -- used in /etc/exports. Entries in the /etc/netgroup file follow the form:
```
netgroup (hosts,users,domains)
```
where netgroup is the name of the group, hosts specifies the hostnames of the systems in the group, users specifies the users in the group, and domains specifies the domains that belong to the group. See netgroup(4CC) for details.

Make sure /etc/networks contains correct information about available networks. Entries in the /etc/networks file follow the form:
```
network_name network_number network_aliases
```
where network_name is the primary name for the network, network_number is the IP network number prefix, such as 127 for loopback or 192.33.15 for a specific class-C network, and network_aliases are alternate names for the network. See networks(4CC) for details.

Starting the NFS Daemons

The rpcbind daemon must be running to handle conversion of RPC calls, the mountd daemon listens for remote mount requests from other systems and the nfsd daemon provides remote NFS services to NFS client systems.

Make sure that /sbin is visible from the target system:
host% rsh target ls /sbin
If you have not yet mounted a root file system, such as host:build_dir/root, see "File System Commands".

Run the rpcbind daemon:
host% rsh target sbin/rpcbind

Run the mountd daemon:
host% rsh target sbin/mountd

Run the nfsd daemon:
host% rsh target sbin/nfsd -ut -n 3
The above command creates three servers for TCP and UDP clients.

Check that NFS is one of the TCP/UPD services available from the target. On a host workstation running the Solaris operating environment, the following example displays the registered RPC services available on the target:
host% /sbin/rpcinfo -p target

Chapter 8 Further File System Administration Examples

This chapter builds on the file system administration examples provided in the previous chapters and offers a series of progressive, detailed worked examples showing you how to

Prepare a RAM disk on the target system and populate it with all necessary files. See "Making a RAM Disk the Main System Disk".
Create a file system on a target system local hard disk. See "Creating a File System on a Target System Hard Disk".
Set up a ChorusOS target system as an NFS server. See "Setting Up an NFS Server on the Target System".
Set up a swap partition. See "Creating and Activating a Swap Partition".

Making a RAM Disk the Main System Disk

You can use RAM to house the root file system, as shown by this example. It is assumed that you have already been able to mount a root directory through NFS. See "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 4 megabyte area of RAM as a disk:

# This label can be used for a 4 megabyte RAM disk. The corresponding
# newfs command to be used with this RAM disk is:
# rsh target newfs -o space -c 26 -m 0 /dev/rd0a

rd4MegBSD:\
	:ns#32:nt#1:nc#256 \
	:pa#8192:oa#0:ta=4.2BSD:ba#8192:fa#8192 \
	:pc#8192: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 disklabel -w -r rd0 rd4MegBSD
$ rsh target disklabel -r rd0
# /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 newfs /dev/rd0a
/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 fsck -y /dev/rd0a
** /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  cp -R bin etc lib ram/
$ rsh target  mkdir /ram/dev
$ rsh target  mkdir /ram/image
$ rsh target  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 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 ls
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:

#! /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  disklabel -w -r rd0 rd16Meg MyRamDisk
rsh target  newfs /dev/rrd0a
rsh target  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 cp -R bin etc lib ram/
rsh target mkdir /ram/dev
rsh target mkdir /ram/image
rsh target 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 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.

Creating a File System on a Target System Hard Disk

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 "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:

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:

$ rsh target disklabel -w -r hd0 ST34311A

After the disk is labelled, you can create file systems on the disk partitions:

$ rsh target newfs /dev/hd0a
$ rsh target newfs /dev/hd0b

Finally, before using the file systems, you should check them:

$ rsh target fsck -y /dev/hd0a
$ rsh target fsck -y /dev/hd0b

After you have checked the file systems you created, you can mount them into your existing file system hierarchy and use them.

Setting Up an NFS Server on the Target System

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 "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 the target, then you can do this:

$ 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

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 "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  inetNShost&
$ rsh target  sbin/rpcbind&
$ rsh target  sbin/mountd&
$ rsh target  sbin/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.

Creating and Activating a Swap Partition

The following example sets up a swap partition on a local IDE disk. This example builds on "Activating a Swap Partition". It is assumed that you have already successfully completed "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 "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 labeling 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  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/hd0a /swap
$ rsh target swapon /swap

The swap partition is now active.

Part II File System Administration for ChorusOS 5.0

Chapter 3 Introduction to ChorusOS File System Administration

System Initialization overview

File System Commands

File System Initialization

Initialization Examples

Managing File Systems

Chapter 4 Configuring the System Image with File System Support

Supported Systems

Supported Media

Supported File Systems

Adding Support for File Systems and Related Hardware to your System Image

Adding Support Using the Graphical User Interface Tool Ews

Adding Support Using Configurator on the Command-Line

Special Device Driver Files

What Special Files Are

Naming Conventions for Special Files

Creating Special Files

Creating Special Files at Boot Time

Creating Special Files Manually

Chapter 5 Setting Up File Systems on the Target

Formatting a Flash Memory Device

Formatting a Flash Memory Device

Labeling a Disk

Setting Up Information About Disk Geometry

Using disklabel to Label a Disk

Creating a File System

Creating a UFS File System

Creating an MS-DOS File System

Example 5-1 Creating a File System on a RAM Disk

Checking File System Integrity

Checking a UFS File System

Checking an MS-DOS File System

Chapter 6 Mounting and Unmounting File Systems

File System Commands

Mounting the Host File System

Mounting an NFS File System

Example 6-1 Mounting a Root Directory through NFS

Mounting a UFS File System

Example 6-2 Mounting a UFS File System as the Root File System

Mounting an MS-DOS File System

Example 6-3 Mounting an MS-DOS File System as the Root File System

Mounting an ISO 9660 File System

Example 6-4 Mounting an ISO 9660 File System as the Root File System

Viewing all Mounted File Systems

Unmounting a File System

Managing the /dev, /image and /tmp File Systems

Mounting a Root File System over NFS

Activating a Swap Partition

Preparing and Activating a Swap Partition

Chapter 7 Sharing Target File Systems Over NFS

Setting Up the Target as an NFS Server

Setting Up the Configuration Files

Starting the NFS Daemons

Chapter 8 Further File System Administration Examples

Making a RAM Disk the Main System Disk

Creating a File System on a Target System Hard Disk

Setting Up an NFS Server on the Target System

Creating and Activating a Swap Partition

Using `disklabel` to Label a Disk

Managing the `/dev`, `/image` and `/tmp` File Systems