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.
This chapter describes how to set up and use local and network file systems supported by the ChorusOS operating system.
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.
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:
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.
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.
The following list explains the file system commands presented, and includes a brief description of df(1CC) and flashdefrag(1M).
Writes disk geometry and other information to a disk attached to the target system.
Displays information about file system use such as total file system size, available space, inodes used and inodes available.
Defragments a Flash memory device attached to the target system.
Formats a Flash memory device attached to the target system.
Checks the integrity of a UFS file system and attempts to fix any errors it finds.
Checks the integrity of an MS-DOS file system and attempts to fix any errors it finds.
Creates a special device driver file corresponding to a device attached to the ChorusOS system.
Mounts a file system at a specified mount point in the existing file system hierarchy.
Writes a UFS file system structure to a labelled disk attached to the target system.
Writes an MS-DOS file system structure to a labelled disk attached to the target system.
Activates a local swap partition that you have mounted.
Removes a mounted file system from the file system hierarchy.
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 SolarisTM operating environment, you can use the share(1M) command to share the file system.
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).
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 / |
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.
This chapter explains how to set up and support file systems and related hardware.
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.
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.
The ChorusOS product supports the following hardware, although not necessarily for all target platforms:
Flash device support is implemented using Flite 1.2. Flash support allows you to use only MS-DOS file systems on supported flash devices.
Supported hard disk drives must be connected to an IDE, ST506 or ESDI compatible disk controller.
RAM disk support allows you to create disk-like entities and use file systems in random-access memory.
Selected SCSI hard disk drives and SCSI-PCI I/O processors of the NCR53C8xx family are supported.
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.
The ChorusOS product supports the following file systems, although not necessarily for all target platforms:
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.
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.
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.
The ChorusOS product supports the use of the ISO 9660 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 |
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
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
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.
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 |
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.
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.
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".
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.
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.
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.
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).
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.
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 |
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.
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.
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.
The following procedure initializes the Flash memory device, erasing all existing data. Be sure to back up existing data on the device before proceeding.
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 |
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).
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.
Once you have correctly specified disk information in /etc/disktab, you are ready to use disklabel.
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.
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.
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.
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.
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 |
See "Activating a Swap Partition" for details on activating a swap partition.
This section explains how to check existing file systems for errors.
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.
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.
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.
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.
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.
The default version of NFS is version 3. To use NFS version 2, ensure you use the option
-o -2 mount |
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.
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 |
host% rsh target mount host:/export/chorus/root / |
Mounts the ChorusOS root directory, /export/chorus/root, on host as the root directory on target.
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.
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.
host% rsh target mount -t ufs /dev/da0a / host% rsh target fsck /dev/rda0a host% rsh target mount -t ufs -o update /dev/da0a / |
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 |
host% rsh target mount -t msdos /dev/hd0a / |
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 |
host% rsh target mount -t cd9660 /dev/cd0a / |
Use the mount command without any arguments to view all mounted file systems:
host% rsh target mount |
Use the umount command to remove mounted_fs from the file system hierarchy:
host% rsh target umount mounted_fs |
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 |
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 |
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.
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.
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".
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.
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 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.
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.
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 |
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".
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.
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:
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.
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
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.
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.