Oberon/ETH Oberon/partition - 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.

Back to: Native Oberon Hardware Compatiblity List

Partitioning considerations

Summary

ETH Oberon is best hosted in a dedicated partition, but if one feels it too risky to partition a hard disk, on a working system hosting other operating systems, the alternative is to place Oberon in a large file in another file system such as FatFS or, if Linux is installed, in a LinuxFS. In any case, the implementation chosen will considerably influence how ETH Oberon is started. A whole palette of ways to start ETH Oberon is documented in Bootstrapping an OS on an x86-based PC, with application to ETH Oberon and further documents linked to it. Many of the themes tackled below are known and dealt with extensively in the context of the many other operating systems. Only the essential part is reminded here in a compact form. The hardware prerequisites are so minimal and so easily met and Oberon has such a small footprint that almost any machine can host it. Oberon fits admirably in an embedded system, such as is encountered in process control for the industry.

Oberon on CD-ROM

Neither partitioning nor installation are needed for running Oberon from the ETH Oberon CD_ROM. The CD edited by vis - Version 11 Nov 2001 - is bootable provided booting from CD-ROM is among the boot sequence options of the system setup on your machine. Oberon is immediately ready for use with its TUI. A RAM disk is available for saving data temporarily (approximately 50% of free RAM is allocated). The fact that the screen operates currently only in VGA mode is bigger handicap. Even so, this system is only apparently of limited capability, as:

to establish communication it suffices to copy Oberon.Text to RAM: and to edit the NetSystem section.
to save files it suffices to mount a diskette or, if free partition space is available, to create an AosFS partition to work with (do not forget that ZIP disks can also be used).
to save files it suffices to mount an existing FAT partition to gain access to it and exchange files, using the System.CopyFiles command for example.

Oberon in a file

No partitioning is needed for:

Oberon for Dummies which is installed in a large file on a FAT partition. It is an updated version of the software found on the CD-ROM included in the book Beginning Programming for Dummies. An easy-to-use installation program OberonInstaller.exe running on Windows is included. The program installs the big file and writes an Oberon boot file to a 1.44MB diskette, from which Oberon can then boot. This Oberon can co-exist with a partition-based Oberon installation at the same time as with other OSes.
Linux-based Native Oberon which is installed in a large file of the Linux file system.

Oberon in a partition

Installing Oberon in a partition requires:

partitioning a disk.
downloading the distribution software and installing ETH Oberon. The installation process is described in detail elsewhere. During the installation, the partition is formatted, thus creating an empty Aos file system (AosFS). Formatting can fail due to the presence of bad blocks. The reason and a workaround are dealt with in a subsequent section.

File system prefixes are used in place of the conventional drive letters "C", "D", etc. Knowingly, for other operating systems, the letter assignment differs from one OS to another and follows a rather complex pattern of rules for searching primary, secondary, visible/hidden partitions. Oberon sees all the partitions (cfr. Partitions.Show ) and partitions must be mounted to access them.

Partition size considerations

A complete installed system, as built from the downloable material, fits in a 60MB partition, leaving approximately 50% of free space. It is advised to keep the original files separated from user files which should at best be stored in an other partition created specially. How that is done and how the partition is accessed are explained in Multiple Oberon partitions on a machine.

ETH Oberon features file garbage collection (GC) on three levels, returning to the pool of free blocks the blocks of deleted files:

on-the-fly GC during an Oberon session.
conditional GC during system start-up. The configuration string "DiskGC" determines the amount of free space, in % of the partition size, below which garbage collection must take place. The values 10 .. 100 can be assigned. The default value is 10.
automatic GC during system start-up when less than a megabyte is available, or if the system was not shut down cleanly, e.g. when the machine is powered off abruptly.

Bluebottle features a similar file garbage collection but on-the-fly GC is not implemented.

File GC, when it takes place, has the side-effect that system start-up lasts noticeably longer than is usual. If the amount of free disk space is chronically too small, GC could take place at every start-up depending on the value assigned to "DiskGC". When no free space is left, a "Volume full" situation will bring the system to a grinding halt - cfr. ETH Oberon system stability. To recover, restart the system, delete unnecessary files and observe the amount of free space by executing System.Watch . If it happened during a system update , proceed with the installation piece by piece, downloading zip archives one at a time, extracting the files and deleting the archive immediately thereafter.

Bad block problem

The procedure responsible for formatting a file system, such as AosFS, does not handle bad blocks currently. The only workaround is to define a small partition that includes the conspicuous block(s). This partition will not be used.

Proposed homework for a volunteer: What needs to be done is to ensure that the bad blocks are ignored by the file system:

detect bad blocks in Partitions.Format
create a file that contains all these bad blocks. This part is file system specific.

If someone wants to attempt this, it is suggested to take the relevant Format code from Partitions.Mod and to rewrite it in a new module.

How to start Oberon

In practice, the manner in which Oberon is started is determined at installation time, and more precisely, in the last installation step using an Oberon-0 system. Note that, as the options are not exclusive, several may be chosen. Options not considered at installation time, may be still be implemented later on, without the need of repeating the installation or part of it. System administration tasks not involving Oberon are, in most cases, required to complete the chain of actions enabling a system start.

How to start another operating system

In case your machine is set up to startup directly into Oberon (the partition is marked as "active"), do this to start another operating system:

boot it from a diskette
activate the partition of that other operating system in anticipation of terminating an Oberon session by issuing these two commands:
1. Partitions.Deactivate [dev#part | ^] (* select Oberon partition *)
2. Partitions.Activate [dev#part | ^] (* select next OS partition *)
activate the partition of that other operating system using some other program such as fdisk (DOS, Windows, Linux), PQBoot (a PartitionMagic component), or some other commercial program.

Technical: Boot manager not supporting chaining

If you boot loader does not support "chaining" to boot a partition from the second drive, you can try to "patch" the boot sector of the Oberon partition. The byte at offset 24H in the boot sector should be set to 81H instead of 80H, to boot from the second hard disk. To make sure you are modifying the correct sector, check that the string "OBERON" appears at offset 3 in the sector. The patch can be applied:

using Oberon itself using the Partitions tool:
1. Inspect the boot sector with Partitions.ShowBlocks dev#part 0 1~
2. Store the boot record Partitions.PartitionToFile dev#part filename 0 1 ~
3. Edit the byte at offset 24H
4. Put the modified MBR in place with Partitions.WriteMBR dev#0 filename ~
or using a sector editor like Norton Disk Editor.

[Top]