Oberon/ETH Oberon/betadocu - Wikibooks, open books for an open world

This document was originally hosted at the ETHZ. It remains under the ETH license and is in the WayBack archive.

Introduction to ETH Oberon / PC Native alpha and beta release

Download by anonymous FTP from: ftp://ftp.ethoberon.ethz.ch/ETHOberon/Native/Update/^[1]

Introduction
File system concept
Comparison of the Oberon file systems
File systems in the beta version
Partition management with Oberon
Disk image file
Partitions viewed by Linux-based Oberon
Oberon file system and foreign file systems
Multiple Oberon partitions on a machine
Oberon installation and installation updating
Configuration strings
Reconfiguring Oberon on start up
Backup / Restore methods
Archives
Beta version specialities
Bibliography

Introduction

This document is being revised as new versions of the PC Native Oberon system are being produced. The objective is to detail some of the important issues which can contribute to overcome possible installation problems encountered by new users and to explain how this operating system can coexist with other OSs. Contributions are always welcome. The installation procedure consists of a few interaction steps after booting the Oberon-0 boot diskette and need not be described in more details here. Many of the Oberon commands presented are effectively used during an Oberon installation but it is by no means indispensable to master the entire instrumentation to conduct a successful installation. The installation procedure makes use of only a small subset of all what is presented here.

Note 1: The first beta version appeared on 20.03.2000 and was updated on 25.04.2000, 26.05.2000 and finally on 08.12.2000. In addition, an alpha version, including several changes and extensions, was made available on 13.05.2001 and is being updated regularly since then. The respective Beta version and Alpha version change logs contain detailed chronological accounts of the modifications made up-to-now. This document places the accent on the alpha version, while the beta version specialities are relegated in separate sections. Readers using the beta version will notice a few major differences but will also get a preview of what the alpha version will bring, if they are tempted to upgrade from their current beta to alpha.

Note 2: To determine which version you are currently using, look at the date on the second line in the log, just after booting your system. If you have other Oberon partitions (type 76) on your machine, with an installed Oberon OS, look for the date in Kernel.Obj.

If you have further questions, read the FAQ dedicated to this alpha/beta version. To find out whether your machine can host Native Oberon or not, consult the Hardware Compatibility List.

This version of ETH Native Oberon introduces a new file system concept, a new generic driver concept, a number of new features and numerous improvements and corrections of the previous release.

File system concept

The new partition management applies to all kinds of mass storage devices: hard disks, storage devices with removable media like diskettes, ZIP disks and CD-ROMs, etc. This does not apply to ZIP drives attached to the parallel port. Most mass storage devices may host more than one partition, ZIP disks in principle too, but not diskettes. Oberon can produce ample information on all the existing partitions and free space in a computer system. All the devices will show up under the generic name "Disk" in displayed information as in this short example:

Disk: IDE0, 8063MB = 16514064 * 512, CHS: 16383*16*63, Maxtor 90845D4, mntcnt=1 
IDE0#00          0  16514064  8063MB --- (Whole disk) 
IDE0#01         63    819252   400MB   6 * DOS FAT16 >= 32M 
IDE0#02     819315   4176900  2039MB   6 DOS FAT16 >= 32M 
... 
 
 
Disk: Diskette0, 1440KB = 2880 * 512, removable, CHS: 80*2*18, mntcnt=1 
Diskette0#00          0      2880   1.4MB --- (Whole disk) [mounted]

Each partition can host a file system of which there are more than operating systems. With its new generic file system support, an active Oberon has access to the data of co-resident partitions hosting a supported file system (FS). The supported file systems are listed in the OFS.Alias section of Oberon.Text . They are:

AosFS - the (new) FS of the alpha / beta version of Oberon
NatFS - the PC Native Oberon FS used in earlier releases; the last one was release 2.3.6. The name stemms from "Native File System".
RamFS - the Oberon internal RAM FS residing in main storage, thus outside of the device / partition hierarchy and which must not be formatted. It is provided as a user convenience for storing temporary data that will be purged when Oberon is terminated.
FatFS - the DOS and Windows FAT FSs; that is, FAT12, FAT16 and FAT32. With the support of the various kinds of classical FSs, it becomes possible to exchange files between those FSs and Oberon and to access and manipulate files directly in them, amounting to performing Windows tasks in Oberon. Long filenames are supported. Use quotes to specify filenames containing spaces or characters that are not valid in Oberon names.

CAUTION: As always, before testing a new FS implementation, make sure that you do not risk corrupting a critical FAT partition. Exchanging files with a FAT-formatted diskette is safer.

These file systems perform anonymous file garbage collection on-the-fly. Previously, file GC was performed only when Oberon was started.

FileFS - the FS of an Oberon hosted in a FatFS. The possibility to install an "Oberon in a file of a FatFS" was provided for those not wanting to create a partition for the sole purpose of trying out the Oberon system. A good example is the "Oberon for Dummies" included on the CD-ROM which comes with the book "Beginning Programming For Dummies, 2nd Edition". In the early days of Native Oberon, this was known as "DOSBased Native Oberon". An Oberon system installed in a dedicated partition can access another Oberon in a file.
ISOFS - the ISO 9660 FS found on CD-ROMs
LinuxFS - the Linux FS. This FS can be accessed only from a Linux-based Oberon

Access to a file system is obtained by mounting it with the OFSTools.Mount command described later. It is essential that the file system declared in the command parameter matches the file system residing on the partition.

Each file system is characterized by a number of states:

Boot: the FS was automatically mounted at boot time. State revealed by OFSTools.Watch and by Partitions.Show detail
Removable: the FS is hosted on a removable disk.State revealed by Partitions.Show
ReadOnly: only read access is allowed on the FS. Controlled by the OFSTools.Mount command. State revealed by OFSTools.Watch

Case sensitivity in AosFS filenames is consistent with case sensitivity in the Oberon language. The maximum file size is now 2 GB and the maximum volume and partition size have been increased to 282 GB.

[Top]

Comparison of the Oberon file systems

The Oberon file system has only slightly evolved since its inception and the figures in the following tables essentially reflect the trend toward larger capacity media, both mass storage devices and RAM. The information given is extracted from "Project Oberon" (Chapter 7) [WG92] and adapted to the two Native Oberon file systems for which the exact figures were obtained from the source modules. We refer to the Project Oberon file system as CeresFS.

The implementation of files on a random-access store

The scheme chosen in Oberon favors short files (< 64KB) but to keep the on-disk structure small yet still allow large files, each file header conforms to the following schema:

the NatFS and CeresFS contain a sector table of 64 direct entries, each pointing to a data sector, and an extension table of 12 single indirect entries, each pointing to an index sector of direct data sector pointers.
the AosFS uses a sector table of 128 direct entries, each pointing to a data sector, and one double indirect entry pointing to a list of 1'024 index sectors, providing a total of 1'024 ^ 2 index entries.

    FS    Sector Sector Extens.  Index   Header     Max. file 
            size  table  table    size     size          size 
          (bytes)  size   size           (bytes)      (bytes) 
  AosFS    4'096    128     1  1'048'576    568  4'295'491'016 
  NatFS    2'048     64    12        512    352     12'713'632 
  CeresFS  1'024     64    12        256    352      3'210'912

The first data sector pointer points itself, the sector containing the header. The on-disk structure is similar to the internal organization of Unix files [Bac86].

Sector pointers are represented by sector numbers of type LONGINT. Actually, the numbers are multiplied by 29, the sector factor. This implies that any single-bit error leads to a number that is not a multiple of 29, and hence can easily be detected. The Scavenger program takes profit of this.

The file directory

The Oberon system uses a B-tree structure with the following characteristics for its file directory:

In a B-tree of order N, each node (called page) contains m elements (pairs), where N <= m <= 2N, except the root, where 0 <= m <= 2N.
A page with m elements has either 0 descendants, in which case it is called a leaf page, or m+1 descendants.
All leaf pages are on the same (bottom) level.

On a page, space must be available for 2N elements and for N + 1 references to descendants. Hence N is immediately determined by the size of a page and the size of elements. In the case of Oberon, names are limited to 32 characters (bytes), and the object is a reference to the associated file (4 bytes). Each descendant pointer takes 4 bytes, and the page size is given by the sector size (SZ) minus the number of bytes needed to store m (2 bytes). Hence N = ((SZ - 2 - 4) DIV (32 + 4 + 4)) DIV 2

     FS       SZ     N   DirPgSize 
   AosFS     4096   51      102 
   NatFS     2048   25       50 
   CeresFS   1024   12       24

The number of directory entries stored in the tree depends on the tree height. The maximum number is given by the expression: MaxElems = 2*N * SUM(i:=0..Height-1, (2*N+1)^i)

           Height   1        2         3         4 
     FS 
   AosFS          102    10'608 1'092'726  2.145 E+09 
   NatFS           50     2'600   132'650   6'765'200 
   CeresFS         24       624    15'624     390'624

Inside the directory page, a binary search among the elements is used (there are between N and 2*N elements in a page). Hence assuming you have more than 10608 files in an AosFS, the tree will have an height of 3 (3 directory pages are accessed in the worst case) and a maximum of 3 * 2LOG(102) = 20 comparisons are needed (this is small compared to the disk access time). Besides that, caching can make accesses faster (usually the root page of the file directory stays in the cache).

AosFS limit values

The maximum file size is 4.0GB because of its triple index structure, but its is effectively limited to 2.0GB because of the 31 bit value for Set and Pos parameters.

The maximum volume size or partition size is 282.48 GB, because BIOS imposes a limit of: 1'024 cylinders * 256 heads * 63 sectors = 16'515'072 physical sectors to divide by the sector factor (29) resulting in 569485 physical sectors of 512 bytes.

A typical workable Oberon partition for a full system starts at about 40MB. Cfr. ShowAosFSLimits

[Top]

File systems in the Beta version

Users of a Beta version, dating back to 08.12.2000 or earlier, must be aware that some of the FSs have somewhat different characteristics and that file manipulations in these FSs are performed in a different manner. As one can imagine, the FSs of the Alpha version described in the previous section are more generic, and this should motivate an upgrade to the Alpha version (which will eventually become the next Beta version).

DosBasedFS - the FS of an Oberon in a file (in a FAT16 partition). The facility to install Oberon in a large file of an existing FAT partition was re-introduced (beta001208) after a period of absence. Not needed anymore in the Alpha version.
FileFS - the FS of an Oberon in a file copied to Oberon (from its FAT16 partition). This facility was introduced as a palliative while the DOSBasedFS was missing (in beta versions issued prior to 08.12.2000). Its interest is limited in the Beta version.

[Top]

Partition management with Oberon

The Partitions module offers a rather complete palette of partition management functions, so that it becomes possible to install a newer version using an existing Oberon system without the assistance of another operating system. Most commands addressing a partition can operate on a partition of an arbitrary type. A few operate only on Oberon partitions: Format, UpdateBootFile, GetConfig, SetConfig.

A partition is addressed as "dev#part" where dev is the physical device designator such as IDE0, IDE1, Diskette0 (for the A drive) or Diskette1 (for drive B), and part is the sequence number of a partition on the device. Oberon collects the partition information from the partition table located in the first sectors of a device. A summary of the disk partitioning is displayed by executing Partitions.Show .

Partitions.Show ["detail"] ~

Displays a summary of the partitioning of all the mass storage devices for which a driver is installed: hard disks and storage devices with removable media like diskettes, ZIP disks and CD-ROMs. By default, a minimum of information is displayed but details are added when the parameter detail is specified. The amount of free space is also displayed for use with Partitions.Create.

Example Partitions.Show detail ~:

    Disk: IDE0, 8063MB = 16514064 * 512, CHS: 16383*16*63, Maxtor 90845D4, mntcnt=1 
    IDE0#00          0  16514064  8063MB --- (Whole disk) 
    IDE0#01         63    819252   400MB   6 * DOS FAT16 >= 32M 
    IDE0#02     819315   4176900  2039MB   6 DOS FAT16 >= 32M 
    IDE0#03    4996215    401625   196MB  79 Native Oberon or QNX Posix 
    IDE0#04    5397840  11036655  5388MB   5 Extended 
    IDE0#05    5397903    401562   196MB  76 |Native Oberon, Aos [mounted] 
    IDE0#06    5799528   2056257  1004MB 131 |Linux fs 
    ... 

     
    Disk: Diskette0, 1440KB = 2880 * 512, removable, CHS: 80*2*18, mntcnt=1 
    Diskette0#00          0      2880   1.4MB --- (Whole disk) [mounted]

The first line describes the disk:

type (IDE, SCSI, Diskette, ...) and position on the controller, e.g. SCSI0.0

size in MB

CHS is followed by the numbers for cylinders*heads*sectors. For a drive using LBA, the report will be "CHS: unsupported". Most ATA and SCSI drives use LBA. Some ATA drives supported both forms of addressing.

manufacturer and model

the number of times mounted mntcnt

In the example, Partition 0 is a virtual partition that spans the whole disk. Devices that do not have a partition table, like a diskette or a CD, have only a partition 0. The disk name of the first diskette drive is "Diskette0" and the partition's name is "Diskette0#00". A ZIP disk can, in principle, have several partitions, as it can feature a partition table.

Each subsequent line informs on the location, size and type of a partition or free space. The data is, for a part, extracted from the partition table located in the MBR.

Each partition is assigned a partition type (see column 5 in the example) which identifies the file system contained in the partition. The partition type of the ETH Native Oberon is "76" (decimal) (partition hosting the new AosFS). More than one partition with partition type "76" may exist on a machine. That is not the case for the previous Native Oberon which uses partition type "79" and distinct other values for further partitions. The file system used there is named "NatFS".

An active partition (see Partitions.Activate), is marked with an "*".

Depending on the installed hardware, the partition table is displayed after an appreciable time lapse. As an indication, it may take up to 10 seconds to scan and collect the information for a ATA/IDE device. This delay is well noticeable on older computers.

Partitions.ChangeType dev#part from to ~

Changes the partition type of the specified partition from the current type (e.g. "6" for a DOS partition) to the new type (e.g. "76" for an AosFS). After that, a file system must be established with Partitions.Format . Use after creating a partition with another OS, or for reusing an existing free partition.

Note that changing the partition type makes it unaccessible to other operating systems! If you accidentally change the type of the wrong partition, you can always change it back, provided you have not made other changes to it in the mean time.

Partitions.Format dev#part [ AosFS | NatFS [ FSRes [ BootFile]]] ~
Partitions.Format ^

Writes an empty file system on the designated partition, destroying any other existing file system. However, if an Oberon FS is detected and the system is operating in SAFE mode, the command is aborted and a warning is issued. Execute Partitions.Unsafe ~ (it appears in the system log) to authorize formatting. The second parameter is the file system type that will be adopted for the partition. AosFS is used by default, which legitimates the second command form. A partition must be formatted before it can be mounted.

The BootFile is the "kernel" of Aos. The file contains a statically linked image of the basic modules of the active object runtime, the dynamic module loader, at least one file system and at least one disk driver. This makes the partition bootable. BootFile is "Native.Bin" by default. FSRes is the amount of space that must be reserved for hosting the data. By default, 512 KB are reserved. Later on, after the partition was created, if the boot loader must be updated without a need of formatting the partition, you must use the command Partitions.UpdateBootFile. Currently, Native.Bin is missing and a warning is issued informing that the partition is not bootable. Boot your machine using the Oberon0 diskette to perform a partial installation or an installation update to access Native.Bin.

If a diskette is to be used solely as backup medium, set FSRes to 1 (0 will not be accepted) since the default value would amputate most of the available space.

A Partitions.Check command is executed implicitly. If the partition has been checked before, the check process can be safely interrupted by pressing the spacebar. This will speed up the format operation.

Partitions.Safe ~
Partitions.Unsafe ~

Partitions.UnSafe enables unsafe commands and issues a warning "Now in UNSAFE mode!" in the System.Log. Partitions.Safe disables unsafe commands. Partitions.Format is unsafe. Unsafe commands are disabled by default.

Partitions.UpdateBootFile dev#part [ BootFile ] ~

Updates the boot loader in an existing Oberon partition. This is necessary if you re-install Oberon in the same partition, or if you move a partition, with one of the many commercial tools available for that purpose, or if you upgrade an existing partition. BootFile is "Native.Bin" by default.

Partitions.Check dev#part
Partitions.Check ^

Checks the sectors of the specified partition, of any type, for readability and reports the outcome in the System.Log. This long-running command can be safely interrupted by pressing the spacebar.

Partitions.GetConfig dev#part ~
Partitions.GetConfig ^
Partitions.SetConfig dev#part { str = "val" } ~

The execution of GetConfig displays in the System.Log a valid, executable Partitions.SetConfig command enumerating all the configuration strings defined for the specified Oberon partition, provided the partition is bootable. If necessary, the configuration can be immediately edited in the log and written back to disk (or diskette) by activating that command. There is practically no need to construct a SetConfig command from scratch. The parameters are far too numerous to detail. The amount of information will depend on the release used, as it is progressively improved and extended. Obviously, these commands may only address an Oberon partition, which is susceptible to contain configuration data. The partition was possibly booted from a diskette, in which case, the relevant information is obtained by executing: Partitions.GetConfig Diskette0#0 ~

The configuration strings are used when Oberon is started by the boot loader and they can be also modified at that time.

Limitation: This command can only be addressed to a partition on a device using 512-byte blocks. A CD-ROM uses 2'048-byte blocks for example and a TRAP would be induced. The config strings can be inspected and modified only at start time.

Practical hint: during an Oberon installation, one has interest to execute Config.BootPartition menu ~ always, even when a boot diskette is going to be created. In case the diskette gets lost or damaged, create a new diskette quickly, leaving out the configuration part, and to recover the configuration, execute Partitions.GetConfig dev#part followed by Partitions.SetConfig Diskette0#0. In certain circumstances, it may be difficult to decide which display driver was selected initially.

Technical hint: The configuration data is stored in sectors 4 to 7 of the partition - cfr. Partitions.ShowBlocks command below.

Partitions.FileToPartition dev#part filename [block blocks] ~

Block copies a disk image file to the specified partition, of any type. block is the starting block number in the partition (this offset value starts at 0). blocks is the number of blocks to copy. Execute Partitions.Show detail to obtain the latter value. When the parameters are omitted, the entire partition is restored. It is strongly recommended to roll back the image file to a partition of the same size as the original one.

In particular, Partitions.FileToPartition Diskette0#0 Oberon0.Dsk ~ is used during an Oberon installation to create an Oberon-0 boot diskette from the disk image file Oberon0.Dsk.

Note: In versions prior to 13.05.2001, the syntax was: Partitions.PartitionFileTo dev#part filename [blocks] ~ which meant: write the first blocks to the partition.

Partitions.PartitionToFile dev#part filename [block blocks] ~

Block copies the specified partition, of any type, to the named disk image file which is then saved for backup purpose. block is the starting block number in the partition (this offset value starts at 0). blocks is the number of blocks to copy. Execute Partitions.Show detail to obtain the latter value. If block # 0, a negative blocks value will cause the remaining number of blocks (blocks - block) to be copied. When the parameters are omitted, the entire partition is saved/backed up.

The MBR of a disk can be saved to a file (MBR.Bin) by executing Partitions.PartitionToFile dev#0 MBR.Bin 0 1 ~

Note: In versions prior to 13.05.2001, the syntax was: Partitions.PartitionToFile dev#part filename [blocks] ~ which meant: write the first blocks of the partition.

Partitions.WriteMBR dev#0 filename ~

Write the MBR to the specified disk (be careful). The MBR data is read from the named file and the program verifies that the data contains a valid MBR signature "55 AA" at the end. The MBR may have been previously saved, with Partitions.PartitionToFile for example. The data in the file is best examined with Hex.Open .

Hint: This command must be considered as a technical utility, also paired with Partitions.FileToPartition. It can be used with any operating system and is useful to remove or to write a LILO boot record for instance. This command is not equivalent to Partitions.FileToPartition dev#part filename 0 1 ~ !!!

It writes only the boot loader code, the first 446 bytes, in the MBR, leaving the partition table unchanged. It is the equivalent of the DOS command fdisk /mbr . On the contrary, Partitions.FileToPartition not only writes the boot loader in the MBR, it also writes the partition table, which can be harmful.

Cfr. How It Works - PartitionTables.

Partitions.ShowBlocks dev#part block [blocks] ~

Displays arbitrary disk blocks, of a partition of any type, in hex. E.g. Partitions.ShowBlocks IDE1#0 0 1 ~ displays the MBR on the primary IDE slave disk.

Troubleshooting a boot problem with this command

If your Oberon system does not start properly and simply stalls and displays "OBE", the Native boot loader does not find the second sector. Execute: Partitions.ShowBlocks IDE0#02 0 8 ~ to write the first 8 sectors of the partition. Sector 0 (the first sector) should have "OBERON" close to the start, and 2-byte signature "55 AA" at the end. Sector 1 must have two AA 55 bytes at the start. Example:

      IDE0#02 0 
      00000000 EB 29 90 4F 42 45 52 4F 4E 00 00 00 02 02 08 00 .).OBERON....... 
      00000010 04 E0 00 00 00 F0 09 00 3F 00 40 00 40 23 03 00 ........?.@.@#.. 
      00000020 C0 90 0F 00 80 00 00 03 00 00 00 FA EA 31 00 C0 .............1.. 
      ... 
      000001F0 72 72 6F 72 21 07 00 6F 62 65 72 6F 6E 00 55 AA rror!..oberon.U. 
      IDE0#02 1 
      00000000 AA 55 66 A1 1C 00 66 A3 06 07 BB 00 08 B9 04 00 .Uf...f.........

It is important that the four bytes at offset 1CH in sector 0 designate the sector number of the boot sector. In the example: 40 23 03 00 (reversed in little-endian order) -> 00032340H = 205632 decimal

The last value must match what appears in the first column for the partition after executing Partitions.Show detail ~

      IDE0#02     205632   1020096   498MB  79 Native Oberon or QNX Posix [mounted]

Another thing to check is that the byte at offset 24H is the boot drive number (80H in the example). This should be 0 for diskette A:, 80H for the first BIOS disk drive, 81H for the second BIOS disk drive, etc. In practice, the rule is relaxed since the software will accept either 81H or 80H.

Your configuration should be visible from sector 4 to 7 (or it could be all zero if you always boot via noboot.exe).

Partitions.Activate dev#part ~
Partitions.Activate ^
Partitions.Deactivate dev#part ~
Partitions.Deactivate ^

Activates / deactivates the specified partition, of any type; that is, sets/resets the "active" marker of a primary partition (see "partition entry" in the partition table). In the list obtained with Partitions.Show ~, an active partition is marked with an "*". When no boot manager is installed, the active partition located on the first disk drive is automatically booted. This is true provided the partition hosts an operating and, for Oberon in addition, that the configuration strings have been written in it, during the installation or later.

The "active" marker has no meaning when:

an Oberon partition is booted with a bootable diskette, created during the installation or later.
a boot manager is used.

In both cases, any partition, primary partition or logical drive in an extended partition can be booted.

Active partition on a disk drive other than the first one: It can be booted too if the machine System Setup allows to change the boot sequence.

More than one active partition: The normal case is to allow only one active partition on a disk. If more than one is active, as can easily be achieved, it is expected that the first one found in the physical order is booted, but that can depend on the MBR code. One boot manager (?) was observed which did present a menu with the active partitions.

Partitions.Create dev#part sizeMB

Creates an Oberon primary partition (type AosFS = 76) of the specified size which will remain unformatted, except for the first sector which is filled with 0F6X. It cannot create a logical drive in an extended partition. Execution is possible only under the condition that no partition is mounted on the host device; that is, using Oberon-0 or using an installed Oberon but on another device with no partition mounted. Cfr. OFSTools.Unmount: the FS which is automatically mounted at boot time cannot be unmounted. The program verifies that the MBR is valid, i.e. has a "55 AA" signature at the end. This is only important to remember when a low-level formatted empty disk is installed. A valid MBR must then be written first. (* Not in Beta *)

Partitions.Delete dev#part type

Deletes a primary partition of the specified type. It was decided to have the user specify this, as it is more robust. Execution is possible only under the condition that no partition is mounted on the host device; that is, using Oberon-0 or using an installed Oberon but on another device with no partition mounted. Warning: The partition is unrecoverable! (* Not in Beta *)

Partitions.ShowAosFSLimits ~

Displays the AosFS limits in the System.Log.

Partitions.Eject dev#part
Partitions.Eject ^

Eject the media from the selected device. (* Not in Beta *)

[Top]

Disk image file

Cloning is the process of duplicating an installed operating system from one reference computer to one or more other computers. It consists in backing up all the data stored on the partitions of the reference computer and in restoring that data on a target computer. Cloning is used extensively at the ETH for installing the computer laboratories.

Oberon implements a simple sector-based cloning method in a pair of commands Partitions.PartitionToFile and Partitions.FileToPartition for cloning a single partition. The sectors of a partitions are copied to and from the intermediate file without knowledge of the underlying file system structure. The intermediate file is usually called a disk image file, or simply disk image. The advantage of the method is that it can not only be used for an Oberon partition but also for any existing operating system.

Usually, a disk image will reside on a server. For example, Oberon0.Dsk is a disk image, more precisely a diskette image, which resides on the ETH ftp server ftp://ftp.ethoberon.ethz.ch/ETHOberon/Native/[expired].

Cloning is also useful for moving a partition to another on the same or another disk on the same computer. Keep in mind that a third partition must offer enough free space for storing the disk image. Given that an Oberon partition is normally no larger that 50MB, this kind of cloning can be considered realistic and practicable too because it is fast. Partitions of other OSs are usually much larger and finding enough free space is probably out of question. Cloning is not apt to resize a partition - cfr. command OFSTools.GenCopyFiles.

Oberon0.Dsk

This image file is at the base of the installation or update of each Oberon system. With it and with the Partitions.FileToPartition command, an Oberon-0 boot diskette is created. Booting from this diskette, starts Oberon-0 which is a small ramdisk-based system for configuring and installing a real, full-fledged Oberon system. This boot diskette is a good example of Oberon system on a diskette.

The image file is created by a process completely described in the section "Installation diskette" in Native.Tool.

Oberon utility diskette

The Oberon Utility Disk is another example of Oberon system on a diskette. The image file is created by a process completely described in the section "Utility diskette" in Native.Tool.

Disk image format

A disk image can also be processed by other popular disk image programs. For example, the Oberon-0 boot diskette can also be created with:

the DOS program rawrite.exe or the DOS version of the OS/2 loaddskf

the Linux, Unix or BeOS program dd

the OS/2 program loaddskf

[Top]

Partitions viewed by Linux-based Oberon

Linux-based Native Oberon is an emulation of Native Oberon for Linux. The goal is not a tight integration in the Linux environment but binary compatibility with Native Oberon. This implementation does not change the module interfaces but partitions are viewed differently. This is due to the fact that Linux Oberon is installed in a LinuxFS file.

Partitions.Show [detail]

Displays a table of virtual partitions. When a Linux-based Oberon is started, the hosting file (default name: oberon.dsk) is viewed as a mounted virtual partition. To access a real Native Oberon partition execute:

Linux.OpenDisk path

Gives access to a Native Oberon (AosFS or NatFS) partition. path is its Linux identifier, e.g. /dev/hdb1. The partition will be viewed as virtual and its file system can then be mounted.

Example Partitions.Show detail ~:

    Disk: oberon.dsk / 61438 * 512 = 29MB / GetCHS: unsupported / mntcnt=1 
    oberon.dsk#00          0     61438    29MB --- (Whole Disk) / mounted
    Disk: Diskette0 / removable / GetSize: no media / mntcnt=0

Partitions.Check path
Partitions.Check ^

Same meaning as for Native Oberon.

All the remaining Partitions commands are not applicable in that context. The configuration is not changed with Partitions.SetConfig but by editing oberon.cnf.

Like in Native Oberon, a file system must be mounted prior to accessing it. You can mount a LinuxFS or a Native Oberon partition accessed with Linux.OpenDisk.

[Top]

Oberon file system and foreign file systems

File names are prefixed with a name identifying a specific mounted file system, as for example SYS, the prefix of the file system from which the system is booted (default prefix).

Example: The full filename of Oberon.Text on a newly installed system is SYS:Oberon.Text .

A NamePlate gadget displays the filename at the beginning and the prefix (or directory) at the end, so that the filename is always visible. The prefix may be hidden when the filename is long. A MM click on a NamePlate causes the full name to be displayed in the System.Log.

An Oberon system can access not only the data of its own file system type AosFS but also data in other Oberon partitions and foreign file systems. Access to other file systems is controlled by the commands of the OFSTools module.

OFSTools.Mount prefix [hashSize] [cachesize] alias (dev#part [",R"] [",X"]] | params ~ | ^ ) ~

Mounts a file system. The first parameter is the prefix under which the file system must be mounted. The prefix is determined at mount time; that is, it is not permanent. After mount, the prefix part of a name is used to find the correct file system, and the part after the prefix is passed on to the file system to interpret. It is not possible to have the same prefix for different partitions/volumes. The order in which multiple file systems are mounted is the order in which they are searched. The order can be changed with OFSTools.SetDefault and is revealed by OFSTools.Watch .

Example: OFSTools.Mount AOS AosFS IDE2#5 ~

After execution, a file "My.Text" residing in IDE2#5, the fifth partition on device IDE2, will be accessible with the name "AOS:My.Text".

The second and the third parameters are cache specifications. No cache is installed by default. Cfr. OFSTools.InstallCache command.

The fourth parameter is the file system type expected on the partition (AosFS in the example). The valid types are listed in the OFS.Alias section of Oberon.Text . Although it is conceivably possible for the system to work out the correct file system type to use, deducing it from the dev#part value, it was decided to have the user specify this, as it is more robust.

dev#part in the 5th parameter specifies the device and the partition to mount. It hosts either an AosFS, a NatFS or a FatFS file system. A FatFS may be a DOS or Windows FAT FSs; that is, FAT12, FAT16 and FAT32. Files can be exchanged between these FSs and that of an Oberon system using the familiar System.CopyFiles command. System.RenameFiles, System.DeleteFiles and System.Directory may be used too and files can be opened directly as usual. Further, the FAT.Tool allows access to the extended capabilities of the FAT file system that Oberon does not support, i.e. directories, file attributes, and so on. Also a DOS-formatted diskette or a ZIP disk can be mounted.

The optional ",R" parameter gives read-only access to the FS. For example, during the installation of a new Oberon system, you are invited to execute:

OFSTools.Mount SRC NatFS Diskette0,R ~

This gives read-only access to the mounted Oberon-0 diskette containing an archive of the Oberon modules to install. The diskette may be write-protected or not. Do not attempt to mount a write-protected diskette without specifying the ",R" parameter. A TRAP will occur.

Mounting a diskette causes the diskette LED to light and to stay lit until an Unmount command is issued. This should draw your attention because you must unmount the diskette before changing the medium.

The optional ",X" parameter is only for use when mounting a FatFS. This option forces the FAT driver to ignore the clean shutdown flag of the partition and to mount the partition for read and write. If the shutdown flag is not set, the partition is mounted read-only to prevent possible data corruption. This situation is reported in the Kernel log.

About the clean shutdown flag: The flag indicates that a partition was properly unmounted. If Oberon crashes, the flag will not be set for a partition which was mounted. It is a good idea to run a disk repair utility program, such as the MS-DOS Scandisk, on a FatFS: if Scandisk fixes an error, it sets the clean shutdown flag. If no error is detected, Scandisk does not set the flag, although it should.

params in the 5th parameter depends of the FS specified in alias, as is described below.

Practical hint: If you want a file system to be mounted when you start the system, you can place a Mount command in the System.InitCommands section of Oberon.Text .

RamFS size sectorsize ~

Mounts a file system residing in main storage, thus outside of the device / partition hierarchy and which need not be formatted. The RamFS parameter is followed by the size in sectors, followed by the sector size in bytes. This file system is provided as a user convenience for storing temporary data that will be purged when Oberon is terminated.

FileFS filename ~

Mounts an existing Oberon hosted in a file specified in the next parameter. Prior to this, the hosting FatFS must be mounted. This command variant makes it possible to exploit legacy data in former DOS-based Oberon systems.

Example:

OFSTools.Mount FAT FatFS IDE2#5 ~

followed by:

OFSTools.Mount DFS FileFS FAT:Oberon.Dsk ~

LinuxFS path ~ (Linux-based Oberon only)

Mounts a Linux file system found along the specified path. Refer to the special Linux section below.

Accessing the file system of an earlier Native Oberon release

First, use Partitions.Show to list all partitions, locate the target partition and select it. Then, execute: ::OFSTools.Mount NAT NatFS ^

Accessing a Linux file system from Linux-based Oberon

In Linux, determine the path to the file system. e.g. /home/userid
In Linux Oberon, mount the file system with: OFSTools.Mount prefix LinuxFS path

Accessing a Native Oberon sub-system from a Linux-based Oberon

In Linux, execute fdisk to determine the partition's identifier, e.g. /dev/hda5
In Linux Oberon, access the partition as a virtual disk with: Linux.OpenDisk /dev/hda5 and mount the file system (NatFS or AosFS) with: OFSTools.Mount prefix filesys /dev/hda5

OFSTools.Unmount prefix
OFSTools.Unmount ^

Unmount the partition mounted earlier under the named prefix. The file system on the media is updated and if it resides on a removable media, the media may be removed. Do not remove a media before it is cleanly updated! When you shut down the system cleanly with System.Reboot, System.Quit or Ctrl-Alt-Del, the mounted file systems are automatically unmounted first.

Also take care not to unmount a file system before all viewers displaying documents residing on that file system are closed, otherwise you will induce a series of TRAPs.

Important: The FS which is automatically mounted at boot time cannot be unmounted. The status (boot) is revealed by OFSTools.Watch .

OFSTools.SetDefault prefix
OFSTools.SetDefault ^

Set the FS with the named prefix as first FS to access by default. The remaining mounted FSs are left in their current order. The new complete path is displayed in the System.Log. Example: Path: WRK SYS

Later on, the order of the FSs can still be verified by executing OFSTools.Watch or System.Watch .

The order of the mounted partitions is important. In the example, WRK comes first, and then comes SYS. This means that when you load a file without specifying a prefix, the system will search through all the mounted FSs in their order, until the file is found. For example, if you load a file called "My.Text", and the WRK FS does not include such a file, then a file in SYS will eventually be opened, if it exists.

In contrast, when storing a file without an explicit prefix, the file is always stored on the first file system (WRK: in this case). To avoid confusion, it is best to always specify a prefix when creating a new file. The TextDocs gadget helps by always displaying the complete filename, including the prefix, in the NamePlate.

To direct the placement of files, as for instance when compiling new .Obj files, you may choose between:

Instruct the compiler to use a prefix (recommended):

Compiler.Compile \PUSR: {files} ~

Change the default file system with OFSTools.SetDefault
This is not recommended, as it affects all newly created prefix-less files.

To display all files on a specific file system, select the line in the System.Watch display and execute System.Directory ^ .

OFSTools.Watch

Lists the mounted file systems in their order, with their prefix, alias, partition id, size and amount of free space. (boot) indicates a file system automatically mounted at boot time. Cache performance information is displayed, if installed. A little more details are given compared to what System.Watch shows, but the latter command displays heap information in addition.

If free space is low, remember that there exists no direct Oberon tool to resize an Oberon partition. Cfr. Partition backup.

To give another example, a RAM-based system installed immediately after booting from an installation diskette Oberon-0:

    RAM: GCN2KFS on RAM0 (boot) 
         1072KB of 2048KB free

A 2MB RAM disk is created by default by Oberon-0. That means at least 3MB are needed for the installation. If needed, Oberon can run in less than 3 MB memory.

OFSTools.InstallCache prefix hashSize cacheSize ~

Installs a cache, of cacheSize blocks, for the FS with named prefix. 100 blocks give a good cache performance and takes about 200KB of memory. Use OFSTools.Watch to look at the cache performance. This command my not be used with a FatFS, since it uses a built-in data cache optimized for FAT.

OFSTools.RemoveCache prefix

Removes the cache installed for the FS with the named prefix. Does not apply to FatFS.

OFSTools.CopyTo dst src ( &file | { file [=> file ] } ) ~

Copies a bulk of files from the file system src to another dst. If a file system is the default one, it may be abbreviated as "". The two first parameters are followed:

either by the names of the files to copy. Optionally, each file can optionally be assigned a new name specified after "=4".
or by a single name prefixed with "&" which denotes an indirect list. The names of the files to copy are contained in the named file.

OFSTools.GenCopyFiles rem add ( "mask" | &file | { file [=> file] } ) ~

Generates a System.CopyFiles command which you can execute, after possibly editing it. The first two parameters specify prefixes. The third (and subsequent) parameters specify a list of files or a mask for selecting filenames. Every filename in the list is taken as source filename. The destination filename is generated as follows: the first parameter is a string to be removed from the filename's head; the second parameter is a string to affix to the trailing part.

The syntax is not too intuitive but the command is really powerful and useful for preparing a batch of filenames. The easiest way to see how the command works is to try it out. This is safe, as it does not have any effect itself, other than generating a text that you can review and execute.

Copy or resize a partition

Assume that valuable data is stored in SYS: and that BACKUP: is a free partition on a system. The power of the command OFSTools.GenCopyFiles SYS: BACKUP: "SYS:*" ~ is particularly impressive in these two usually non-trivial applications:

Backup a partition: A copy file by file captures the state of the system at a particular moment. One can then roll back the original system in the event of malfunctions caused by new software or the installation of new hardware. This is a easy technique for rolling back the system to a point where it worked properly.
Resize a partition: The copy process reorganizes automatically the files thus offering the possibilty to move the data to a smaller size partition, though the prime use will usually be for increasing the size.

Cloning offers the advantage that the image file can be ported to another system.

[Top]

Multiple Oberon partitions on a machine

Oberon can be installed in a primary partition or in a logical drive. Hence, more than four Oberon partitions may coexist on a single hard disk. But Oberon can also be installed on different hard disks, even of different type (EIDE, SCSI, USB). During the installation, you are invited to select a driver for the controller of the hard disk on which Oberon must be installed. Later on, when you decide to install Oberon on another disk, you must execute the relevant disk driver install command:

for an ATA/EIDE disk controller, execute ATADisks.Install ~ (takes about 5 seconds)
for an Adaptec 7xxx SCSI disk controller, execute Adaptec7.Install ~ (takes about 15 seconds)
for an NCR 810 SCSI disk controller, execute NCR810Disks.Install ~ (takes about 15 seconds)

This may also be done in the System.InitCommands section of Oberon.Text

Afterwards you will see the new devices in the Partitions.Show display. To see trace information displayed by these drivers, use System.OpenKernelLog .

Additional file systems

To create a new file system, you first have to create a partition by executing a Partitions.Create or a Partitions.ChangeType command. The next step is to format the partition with AosFS by executing a Partitions.Format command. After formatting the partition, mount it with an OFSTools.Mount command, e.g. with the parameters USR AosFS dev#part. If you want the file system to be mounted when you start the system, you can place this command in the System.InitCommands section of Oberon.Text . You can now access files on the new file system using names like: "USR:SomeFile".

You can also create Oberon file systems on removable media like diskettes and ZIP disks (driver available). In the case of removable media, you have to be careful to unmount the file system before removing the media again, to cleanly update the file system on the media. This is done using the OFSTools.Unmount command.

Suggestion for assigning partition prefixes

One should use a small number of partitions. The problem with having too many partitions is that they have to be preallocated, and one has to live with a bad allocation. If the SYS partition is too small to install a new release, what do you do? If it is too big, space is wasted. The recommended partition size starts at 40 MB for a complete release, leaving approximately 40% of user free space, but users may also elect to set their files apart in a HOME partition, as is explained below.

The Shark network computers at the ETH had three:

SYS: for read-only shared system files

RAM: for a ram disk

HOME: for the user's own files

On a PC, a recommended number is two:

SYS: for the installation

HOME: for the user's own files

It is recommended to make HOME: the default file system by executing OFSTools.SetDefault HOME ~ , at best when Oberon is started by adding it to the System.InitCommands section of Oberon.Text . To make this quite visible add System.Watch to that section too.

Files with identical names in different file systems

This may be the source of a serious problem, with .Obj files in particular. When a module X is loaded, the module loader simply tries to open file X.Obj (no prefix). The file system will search through the search path (in System.Watch order) until X.Obj is found, and module X will be loaded from that file system. If you have multiple copies of X.Obj on different file systems, the search path order determines which one is loaded. This can be to the least confusing and can also lead to a catastrophy with TRAPs and system lockup. The best is to name modules uniquely (by registering a prefix in the module registry on the Native home page), and to avoid duplicate .Obj files.

[Top]

Oberon installation and installation updating

The possibility to operate with multiple file systems simplifies the installation strategy. For the purpose of discussing various options, assume that an Oberon system is running on two file systems (SYS: and HOME:). Recall that when Oberon is already installed, no other OS is needed anymore for a further installation (except for creating another Oberon partition, as this beta version does not yet support this).

Installation of new release

To install a new release without impairing or destroying the working system, say for testing it, one creates an additional partition for the new release. Then, the current file system (SYS:), the new FS (also SYS:) and the user FS (HOME:) can be managed as two pairs: current + HOME and new + HOME. Obviously, with such a setup you do not risk to overwrite some of the SYS: files adjusted to your personal preference, but these particular files must also be customized in the new system. Modified files can easily be spotted by executing System.Directory SYS:*.Bak resulting in a list, which will probably contain some of these names:

EditKeys.Text

Mail.Panel

Mail.Sig.Text - (your mail signature)

MailMessages - (your mailbox)

News.Sig.Text - (your news signature)

Oberon.Text

System.Tool

System3.Tool

TextPopups.Text

and possibly a few more *.Tool file names that have been adjusted. Follow the installation instructions to install the new release and start it. Mount the old FS under a name of your choice, e.g. OLD. Most of the files listed above may be copied to the new FS, except Oberon.Text which must be merged with the new one, because some new settings may have been added in the new release. Open OLD:Oberon.Text and SYS:Oberon.Text and copy the old settings into the new text. It might be a good practice to highlight your private data in color.

A MailMessage.Bak file will only show up after having executed Mail.Collect or after having deleted 100 messages.

There remains to organize to start either system at will. Many alternatives are offered: make them bootable from diskette, from a boot manager or by activation. Whereas booting from diskette is always possible, the alternatives are conditioned by the boot manager or the partitions' position on the hard disk(s).

Upgrading an installed Oberon

If you re-install Oberon in the same partition or upgrade it, the risk of overwriting files exists in principle, but the install procedure takes care of creating a .Bak file for each file with suffix ".Text", ".Tool" or ".Mod". Only those files listed in the previous section are really 'critical' and could be lost by erroneous handling (*). The installation itself is simplified compared to a full installation. Indeed, a partition is already present, hopefully of a suitable size, and the FS is also present. Formatting the FS is thus not required. Instead, the boot loader must be replaced with Partitions.UpdateBootFile. After the installation, copy back the critical files from their .Bak version or from a special backup version. Do not simply copy Oberon.Text, because some new settings may have been added in the new release. Open Oberon.Text and Oberon.Text.Bak and copy the old settings into the new text. It might be a good practice to highlight your private data in color.

(*) E.g. by attempting another run of the installation before completing the current one. As a measure of precaution, you may thus backup them prior to the installation in any of the manners described in the next section.

[Top]

Configuration strings

Native Oberon uses configuration strings for setting low-level configuration options. These strings are ASCII string pairs (name, value) which are stored in a table on the boot device (diskette or hard disk). Permanent values for these strings are normally set during installation using the Install program in Oberon-0. The strings are read by low-level modules in the system using the Kernel.GetConfig procedure. Higher-level modules should use the more flexible Oberon.Text and the Oberon.OpenScanner procedure for accessing configuration information.

Cfr. Configuration strings

[Top]

Reconfiguring Oberon on start up

Sometimes it is necessary to temporarily override the setting of some config strings.The configuration of a starting Oberon system can be changed on-the-fly by holding down the Shift key or by activating Scroll Lock during booting. Within seconds the boot process is interrupted and the config strings with their name and current value are listed on the screen:

    OBERON loading... 
    BootVol=IDE0#9 
    MT=PS2 
    ... 
    OBL>

Enter "h" (for help) to recall the rules for replying to the Oberon Boot Loader (OBL) prompt (terminate each reply with a carriage return):

     name=val - set config string 
     name=    - delete config string 
     c        - continue booting 
     w        - write config to boot device

Enter a config string pair and terminate with a carriage return. Since version 2.23 the name strings are no longer case sensitive. To make the changes permanent, enter "w" and the configuration will be written back to the boot device. To continue with booting, enter a final "c".

If noboot.exe is used to start Oberon (via DOS or MS-DOS mode in Windows 95/ 98 (not ME)), the boot process is also interrupted but the editor of choice determined by a SET Editor= command is called to edit the configuration stored in the Native.Par file. When the editor is exited, booting is resumed. If no editor is defined, booting proceeds normally without giving an opportunity to modify Native.Par.

Obviously, config strings can also be changed by editing Native.Par whenever required. Only the size of the file containing Oberon (in the Linux file system) can be changed in Linux-based Native Oberon.

[Top]

Backup / Restore methods

PC Native Oberon offers a number of methods for backing up sensitive data.

File backup/restore to a mountable file system

Backing up in another file system (AosFS, NatFS, FatFS) is made possible by the mounting / unmounting facility described in Oberon and foreign file systems. A batch of files is best copied from one file system to a another using OFSTools.CopyTo. The same command is used to restore the files. Alternatively, the backup / restore operation can be conducted by executing System.CopyFiles. The command with a list of filenames is conveniently created by an OFSTools.GenCopyFiles command.

In spite of their limited storage capacity, diskettes are still a favorite backup medium, given the small average file size of Oberon modules and object files. Diskettes are exploited in the same way as hard disks, except that they feature a single partition of very small size, containing a mountable file system. Note that the AosFS can waste space in comparison with the NatFS and the FatFS. The classical drive letters "A" and "B" are not used anymore in commands, except in the Backup.Tool commands described next.

Since Oberon operates with long filenames, storing files to a FatFS may run unexpectedly fast into a capacity problem. The root directory in the file allocation table can contain 512 entries at most. In other words, there can be at most 512 files and folders in the root directory. To store long filenames and folder names, and their associated 8.3 aliases, one can run out of directory entries with fewer than 512 files or folders in the root directory. The work around is to move a batch of files to a work folder in the root directory.

Backup.Tool

Files are copied from a partition to a diskette using Backup.WriteFiles, and are restored to the partition using Backup.ReadFiles. Backup.Tool provides the details. For doing that, a diskette does not need mounting. Filenames are limited to the 8.3 format.

DOSBackup diskette

Files backed up on Windows Oberon using the DOSBackup tool can be restored on Native Oberon executing a DOS.BackupDirectory "a:/" command. This will produce a DOS.Copy command with the relevant filenames ready for editing before execution. The restored files will recover their Oberon names instead of the 8+3 names enforced by a DOS.ReadFiles command.

Backup on server via FTP

Oberon is inherently fit for communication, FTP in particular. A graphical user interface is at hand for uploading / downloading files to a remote server but the NetSystem.Tool provides down to earth commands to achieve the same goal.

Partition backup

Copy the partition to another one and restore it.

Partition cloning

Copy the partition to a disk image file and restore it.

[Top]