[#opnbsdgo]:

OpenBSD Startup Process

System startup process

Generalized process
System Startup Processes (Unix section) discusses booting Unix-like platforms.
Variations

The process of starting up may vary a bit. The following resources may provide some information about such variations:

bootstrapping

This can be platform-specific.

Bootstrapping on the i386 and amd64 platforms
Some overview info

The i386/amd64 platforms may actually be among the most difficult of boot sequences, namely due to the historical decentralized, non-standardized nature of the i386 platform. As they have also been very popular, their significance has been of notable importance.

A lot of the details of the system startup procedures discusses the general process for these platforms. Being familiar with that first may be a more sensible starting place. This section of documentation focuses more on the OpenBSD-specific portions.

This documentation mainly covers the early boot process introduced with OpenBSD 3.5.

OpenBSD/i386 “manual page” about the system bootstrapping procedures for the i386 platform and a similar OpenBSD/i386 “manual page” about the system bootstrapping procedures for the amd64 platform may be nearly identical. One will say i386 while another will say amd64, but beyond that they are more alike than different. With OpenBSD version 4.9 the only differences were in the “Cold Starts” section. Those man pages discuss the early process of the architecture. These documents state that “booting OpenBSD from the BIOS will eventually load the OpenBSD-specific” platform-specific “bootstrapping code.” The key word there is “eventually”. From the next sentence, it is clear that the bootstrapping code being referred to is the “second stage” boot loader, and two other parts of the disk may have code that is loaded and executed before the second stage boot loader gets loaded.

There is a “FILES” section towards the very end of the documents about booting the i386/amd64 architectures. (e.g. OpenBSD/i386 “manual page” about the system bootstrapping procedures for the i386 platform: section documenting related files) This “FILES” section lists some of the files used to help start up OpenBSD on these platforms.

MBR code

A copy of the code provided by OpenBSD which is designed to be loaded on an MBR is stored in the /usr/mdec/mbr file. It is designed to run code from the Partition/Volume Boot Record (“PBR”/“VBR”).

This is documented a bit by OpenBSD FAQ 14: section about how OpenBSD/i386 and OpenBSD/amd64 boot (OpenBSD FAQ 14.7), section 1. Part of that documentation says, “While OpenBSD includes its own MBR code, you are not obliged to use it, as virtually any MBR code can boot OpenBSD.” Sounds like there isn't much special there, although FAQ 14.7 does mention the information that can be gathered from the output of this code.

The code from /usr/mdec/mbr may be installed, without destroying partition tables, by using OpenBSD's fdisk program as follows:

fdisk -u -f /usr/mdec/mbr

Alternatively, -i may be used to be more destructive than -u.

[#obsdbtlf]: First stage boot loader

This is documented a bit by OpenBSD FAQ 14: section about how OpenBSD/i386 and OpenBSD/amd64 boot (OpenBSD FAQ 14.7), section 2. Additional documentation is at OpenBSD/i386's “manual page” for the primary stage boot loader “biosboot” and the very similar OpenBSD/amd64's “manual page” for the primary stage boot loader “biosboot”.

Purpose/design/goal

The primary stage boot loader is designed to be very small code which can easily be placed into the bootblock of a partition/volume. This bootblock is known as the Partition/Volume Boot Record (“PBR”/“VBR”).

The main job of the primary stage boot loader, which is code that was installed onto the command line, is to load the second stage boot loader. Whenever the first stage boot loader is installed, a location of the second stage boot loader is hard coded into the first stage boot loader. The first stage boot loader then relies on that hard coded value to be able to successfully execute the second stage boot loader.

Multiple names

The code stored on the PBR is referred to by OpenBSD FAQ 14: section on “Installing Bootblocks” (which is specific for i386 and amd64 platforms) (OpenBSD FAQ 14.9) as the “first-stage boot loader”. The files section towards the very end of the documents of booting the i386/amd64 architectures (e.g. OpenBSD/i386 “manual page” about the system bootstrapping procedures for the i386 platform: section documenting related files) calls that same code the “primary stage bootstrap”. A copy of the code stored on the PBR is stored in the /usr/mdec/biosboot file. As that code does get executed, some of the OpenBSD team's documentation refers to the code from that “biosboot” as if it were a program. However, the code isn't meant to be run from an OpenBSD command line.

[#obtldloc]: Location of OpenBSD's first stage boot loader

Some older versions of OpenBSD documentation may have referred to running this code directly, storing it in the MBR. OpenBSD/i386's “manual pages” for the primary stage boot loader “biosboot”: “NOTES” section (and OpenBSD/amd64's “manual pages” for the primary stage boot loader “biosboot”: “NOTES” section) notes that now this “is not recommended, and is not supported”.

The biosboot program is installed onto the “bootblock” of a hard drive partition with an FFS (not FFS2, but FFS1) file system. OpenBSD FAQ 14: section on “Installing Bootblocks” (which is specific for i386 and amd64 platforms) (FAQ section 14.9) is about installing software to the bootblocks. While the code may be getting placed onto one of the bootblocks, the name of the software that gets installed is called biosboot, presumably named after the file that the code gets copied from when this primary stage boot loader is installed. Calling the code “biosboot” will be a more clear name than trying to refer to this code by the name “bootblocks”.

The OpenBSD/i386 “manual page” for installboot: “Caveats” section (and the similar OpenBSD/amd64 “manual page” for installboot: “Caveats” section) notes that the second stage boot loader “must be on the drive/partition specified by” the disk device that the first stage boot loader is being installed to. What this specifically means is that, at this point of the boot process, “you cannot perform cross-device installboots.” (Booting cross-device like that may or may not be able to be done by code executed before the PBR code is run, such as software called a “boot manager”. Booting cross-device like that can be done after the second-stage boot loader is run, but trying to do that at the “first stage boot loader” portion of the boot process will not work.)

Working with the primary stage boot loader

Despite its name, the program called “biosboot” does not boot/run BIOS code, but rather this software is run from the system startup code. (The system startup code has traditionally been called the BIOS on computers using the i386 platform). The act of installing this “biosboot” (first stage boot loader) program is done with the installboot software. Details of this software are visible in OpenBSD/i386 “manual page” for installboot (and the similar OpenBSD/amd64 “manual page” for installboot), and running this software is also covered by OpenBSD FAQ 14: section on “Installing Bootblocks” (which is specific for i386 and amd64 platforms).

Despite its name, the installboot program is about installing the primary stage boot loader which is often called “biosboot”, not the second stage boot loader that may commonly referred to as “boot” (even by official documentation).

The purpose of the “biosboot” software is to then go ahead and run the second-stage boot loader. The main reason for the first-stage boot loader to exist separately is because it is extremely small, and so can fit in a partition, or on a disk, outside of the file system. This can make the code fairly useful during the early portions of a system startup process. (The second-stage boot loader may provide at least rudimentary support for the file system, and performing that task may take more bytes of code.)

The biosboot program isn't very interactive, but holding down a shift key can cause it to use CHS mode instead of LBA mode.

The program provides very little output (even in the case of errors), surely because the software is intentionally tiny (in order to comply with some very limiting technical requirements). Because of this small size of the the priary stage boot loader, the Diagnostics messages of OpenBSD/i386's primary stage boot loader “biosboot are fairly short. (The same, unsurprisingly, is true for the Diagnostics messages of OpenBSD/amd64's primary stage boot loader “biosboot”.) They are discussed a bit by OpenBSD FAQ 14: section on “Installing Bootblocks” (which is specific for i386 and amd64 platforms) (OpenBSD FAQ 14.9) section 2.

[#obscbtld]: Second stage boot loader

The main point of this program is to locate and then load the operating system kernel.

There are different variations.

The main version of this program is called “boot”, and this name is referenced by various pieces of documentation provided by the OpenBSD team. The OpenBSD/i386 “manual page” for boot/boot.conf (and OpenBSD/amd64 “manual page” for boot/boot.conf) notes that this software “provides a convenient way to load the kernel.”

More documentation is at OpenBSD FAQ 8: section on the OpenBSD Bootloader (which is specific to the i386 and amd64 platforms) (OpenBSD FAQ 8.9).

There are some variations called “cdboot” and “pxeboot”. These two files, as well as the main generic code in the file called “boot”, and some other files related to the very early parts of the system startup process, may be found in the directory /usr/mdec/.

Documentation: OpenBSD/i386 “manual page” for “cdboot”, the CD variation of second stage boot loader (and OpenBSD/amd64 “manual page” for “cdboot”, the CD variation of second stage boot loader), OpenBSD/i386 “manual page” for “pxeboot”, the Preboot Execution Environment (“PXE”) variation of second stage boot loader (and OpenBSD/amd64 “manual page” for “pxeboot”, the Preboot Execution Environment (“PXE”) variation of second stage boot loader).

This is documented a bit by OpenBSD FAQ 14: section about how OpenBSD/i386 and OpenBSD/amd64 boot (OpenBSD FAQ 14.7), section 3.

This program is (or can be) a bit interactive. As noted by the manual page (OpenBSD/i386 “manual page” for boot/boot.conf and the similar OpenBSD/amd64 “manual page” for boot/boot.conf), the software may check for the presense of a /etc/boot.conf file so that options may be used without requiring interactive actions. However, as noted by those manual pages, “holding down either Control key as boot starts” overrides the processing of this file, so interactive interaction is a possibility available to anyone with access to the system's local console. (The manual pages for boot/boot.conf may exist only for the i386 and amd64 architectures, and not in more generic collections of OpenBSD manual pages. The manual page may not be found from the online man pages unless one of these architectures is specified. Generically specifying no architecture results in the file not being found.)

This program is also at least a bit aware of file systems, so the contents of a root directory may be visible by using an “ls” command. (However, the OpenBSD/i386 “manual page” for “cdboot”, the CD variation of second stage boot loader: “BUGS” section (and the OpenBSD/amd64 “manual page” for “cdboot”, the CD variation of second stage boot loader: “BUGS” section) note that the command does not support ISO9660. So, don't expect this software to successfully list the contents of a boot CD, even if the boot loader was loaded from the CD.) The software might be able to show contents from a hard drive, which might be useful to locate another pre-available kernel. The program can attempt to load a file named /etc/boot.cfg (which may be a local file, or in the case of when pxeboot's code is being used, may be a remote file). The program may also locate the kernel to load based on a specified filename (as long as the file system is accessible by the program). If there are multiple kernels available (such as a single-core kernel and a multi-core kernel, or a new and fairly untested version), controlling this program is the easy way to specify which kernel to use.

Note that at this point some cross-device booting may occur. In fact, cross-platform booting might be possible. (When OpenBSD 4.2's official CDs were made, the i386 CD didn't boot on some systems. Theo noted the results of his investigation into that particular problem. The workaround was to use the OpenBSD/amd64 4.2 CD (OpenBSD 4.2 CD #2) which was able to run the boot loader on 32-bit i386 systems. That boot loader could then be used to boot the OpenBSD/i386 kernel from the first CD.)

By default, there may be no /etc/boot.conf file, but that file may be used if it exists. For instance, if the file states “set image bsd.mp” then that kernel file may be loaded.

In case that file does not specify a valid image (such as if the file does not exist), the boot program may simply try some expected filenames. OpenBSD FAQ 8: section on the OpenBSD Bootloader provides the automatically tried kernel filenames of /bsd and /obsd and /bsd.old (in that order). Otherwise, OpenBSD installation: section on booting from a different boot loader mentions filenames of /bsd.sp (which is mentioned by OpenBSD/i386 manual page for “boot_i386”: “Files” section and the corresponding OpenBSD/amd64 manual page for “boot_amd64”: “Files” section) or /bsd.rd that could be manually tried.

If the *.rd file from an OpenBSD installation is on a hard drive, and the second stage boot loader can locate that file, then the second stage boot loader can generally run that file which will allow installation of the operating system. This can often be done using the second stage boot loader from a different version of the software than the kernel. In fact, that is often an easy way to upgrade an OpenBSD system. There may be no need to create a bootable CD. The first step is to make sure that the kernel can be easily located (by copying the kernel to the root directory). Then, enter the second stage boot loader, even if that boot loader came from an older version of the operating system. Then use that second stage boot loader to load the desired (new version of the) kernel. If that kernel is the the *.rd file designed for installing the operating system, then this becomes an easy way to perform the operating system upgrade.

Below OpenBSD FAQ 14: section about how OpenBSD/i386 and OpenBSD/amd64 boot (OpenBSD FAQ 14.7) section 4 is some sample output, which shows the last output of the boot program being the line that says “[ using 386464 bytes of bsd ELF symbol table ]”.

Kernel

As seen by some sample output below OpenBSD FAQ 14: section about how OpenBSD/i386 and OpenBSD/amd64 boot (OpenBSD FAQ 14.7) section 4, the first output of the kernel is the “Copyright” information. After that is a blank line, followed by the first bit of output that gets stored in the “system buffer”. That output may identify the kernel being used: more details are in the later section about kernel actions.

Certainly more could be said about what happens after the kernel starts to run, such as checking the settings that can be altered from a “User Kernel Config” prompt, and eventually running the code called “init” (as noted by OpenBSD's “manual page” for “init”). However, that starts to get out of the realm of the topic of this section of text, which is very specific to the OpenBSD/i386 and OpenBSD/amd64 platforms. (For further details about the boot process, see the section that discusses using the OpenBSD Kernel.)

Other platforms

Other platforms may look different than OpenBSD/i386 and OpenBSD/amd64. For example, OpenBSD “manual page” called “boot_config” shows a boot loader with the “-c” command being used, and its output does not identify itself as OpenBSD/i386 (or OpenBSD/amd64). It does look a bit different.

The OpenBSD Kernel
Kernel files
...
Kernel actions
Early identity

The code may show a “Copyright” statement.

This may be done before the system starts logging output to the “system buffer”.

Version output
... ... http://www.openbsd.org/faq/faq8.html#SMP mentions some filenames.
Checking/changing the kernel config
Interacting with setting the kernel configuration

This may be impacted by the “User Kernel Config” (“UKC”) prompt. More details about that process may be worth checking into further...

When the kernel is loaded, it may be modified temporarily, as noted by OpenBSD “manual page” for boot_config, OpenBSD FAQ 5: section on “Boot-Time Configuration (OpenBSD FAQ section 5.8) and OpenBSD FAQ 5: section on verbose boot output (OpenBSD FAQ section 5.10).

If the boot loader (specifically for OpenBSD/i386 and OpenBSD/amd64 systems, the “second stage” boot loader is the portion of code that may do this) runs the kernel with a “-c” parameter, the kernel may run the “UKC>” prompt.

(Another option to modify this sort of kernel configuration, rather than just making such a temporary change, is to make a change which will remain in place. This is described by OpenBSD FAQ 5: section on “Using config” for kernel changes (OpenBSD FAQ section 5.9). OpenBSD FAQ 8: section about a hardware clock not being sync'ed to UTC (OpenBSD FAQ 8.25) also mentions this method.

Some kernel actions
Starting to use the system buffer

The kernel may/does start with printing the same text that is visible when checking the kern.version sysctl. This text identifies the kernel, including mentioning what version of the operating system the kernel was intended to be used with. The value of that sysctl may be viewed later by using the sysctl command. That initial output gets stored in the “system buffer”. (The term “system buffer” can be seen by OpenBSD's “manual page” for the dmesg program.) The system buffer is what can later be seen by the dmesg program, and which gets stored inside the /var/run/dmesg.boot when the system is started.

Starting to use the “system buffer” is not the very first thing that is done. For instance, a “Copyright” notice may be shown before the system buffer starts logging output. However, starting to output to the system buffer is a fairly early task, and so most of the system's early startup process will have output being logged to the system buffer.

If the kernel notices a problem, it may decide to run the kernel debugger, ddb. (The OpenBSD “manual page” for ddb notes that the program can be entered by changing a sysctl.)

Disk handling

At some point (when?), the operating system identifies the areas of the disk that it uses. This is done by reading the “disklabel”. Also, the root device gets mounted.

init

The OpenBSD “manual page” for init says “The init program may be passed parameters from the boot program”. (The “init” program is not something that is run from the command line.)

The init process needs to keep running, as noted by OpenBSD's manual page called “crash”'s section called “init died”. (Further details are in the second about OpenBSD “init” code.)

[#obsdinit]: Process control initialization: the “init” code

The OpenBSD “manual page” for init says, “The init program is the last stage of the boot process.” But quite a bit happens after the “init” program runs. So, this simply indicates that the system startup process includes more than what is being referred to as the “boot process”. Perhaps the term “boot process” is focused a bit on some of the platform-specific steps that happen at the start of the system startup process.)

(See OpenBSD man page for the “init” code.)

/etc/rc

Running /etc/rc as described by OpenBSD FAQ 10: section on starting “services” (a.k.a. “daemons”) (section 10.3) performs some processes.

Network configuration is generally handled by storing configuration inside /etc/hostname.* files. These files are documented by the OpenBSD manual page for hostname.if (documenting the format for files named /etc/hostname.*). These files are used when running “ . /etc/netstart ” (as done by the /etc/rc command).

The /etc/rc command will process a configuration file, which is called /etc/rc.conf. This file is also generally not to be overwritten.

For other system startup processes, OpenBSD FAQ 10: section on starting daemons (section 10.3) shows that system “services” (also known as (called “daemons”) are run before running the /etc/rc.local command.

There is some (rather undocumented?!?) support for /etc/rc.firstrun* file(s) to be processed (and overwritten) by /etc/rc

Initializing ports

According to OpenBSD manual page for the init command, “In multi-user operation, init maintains processes for the terminal ports found in the file” at /etc/ttys. (This file is discussed more by OpenBSD's manual page about the /etc/ttys file.)

Results of unclean filesystem

Sometimes, there may be a problem with accessing /dev/ when the system starts up. This can cause the OpenBSD machine to be pretty unresponsive. Looking at the console may show error messages like the following:

Warning: / was not properly unmounted
clock: unknown CMOS layout

(The “unknown CMOS layout” is simply referring to the SeaBIOS used by Qemu, and is not really an error.)

Then a bunch of text, including some errors... ........ one is:
sysctl: top level name sysctl in sysctl is invalid
ddb.panic: 1 -> 0
starting network

(Perhaps some further details may be visible by putting a command like sleep 5000, or a shell, into /etc/hostname.* files.)

chmod: /dev/ttypL: Read-only file system
chmod: /dev/ttypL: Read-only file system
chmod: /dev/ttypM: Read-only file system
(similar messages for other ttyp?-named devices)
chmod: /dev/ttypZ: Read-only file system
chmod: /dev/ttypa: Read-only file system
(similar messages for other ttyp?-named devices)
chmod: /dev/ttypz: Read-only file system
chmod: /dev/ttyp0: Read-only file system
(similar messages for other ttyp?-named devices)
chmod: /dev/ttyp9: Read-only file system
chmod: /dev/ttypA: Read-only file system
(similar messages for other ttyp?-named devices)
chmod: /dev/ttypZ: Read-only file system
chmod: /dev/ttypa: Read-only file system
(similar messages for other ttyp?-named devices)
chmod: /dev/ttypz: Read-only file system
clearing /tmp
...
rm [a-km-pr-zA-Z]*: Read-only file system
/etc/rc[450]: find: not found
starting pre-securelevel daemons:.
setting kernel security level: kern.securelevel:0 -> 1
/etc/rc[450]: mktemp: not found
creating runtime link editor directory cache
ldconfig: /usr/lib: No such file or directory
ldconfig: /var/run/ld.so.hints.OAXXzOd0QAD: No such file or directory
preserving editor files.
/etc/rc[450]: /usr/libexec/vi.recover: not found
starting network daemons:/etc/rc.d/sshd: /etc/rc.d/rc.subr[141]: basename: not found
/etc/rc.d/sshd: /etc/rc.d/rc.subr[154]: printf: not found
/etc/rc.d/sshd[9]: id: not found
/etc/rc.d/sshd[9]: [: 0: unexpected operator/operand
/etc/rc.d/sshd: need root privileges
/etc/rc.d/dhcpd: /etc/rc.d/rc.subr[141]: printf: not found
/etc/rc.d/dhcpd: /etc/rc.d/rc.subr[154]: printf: not found
/etc/rc.d/sshd[15]: id: not found
/etc/rc.d/sshd[15]: [: 0: unexpected operator/operand
/etc/rc.d/dhcpd: need root privileges
/etc/rc.d/sendmail: /etc/rc.d/rc.subr[141]: printf: not found
/etc/rc.d/sendmail: /etc/rc.d/rc.subr[154]: printf: not found
/etc/rc.d/sendmail[13]: id: not found
/etc/rc.d/sendmail[13]: [: 0: unexpected operator/operand
/etc/rc.d/dhcpd: need root privileges
/etc/rc.d/inetd: /etc/rc.d/rc.subr[141]: printf: not found
/etc/rc.d/inetd: /etc/rc.d/rc.subr[154]: printf: not found
/etc/rc.d/inetd[9]: id: not found
/etc/rc.d/inetd[9]: [: 0: unexpected operator/operand
/etc/rc.d/inetd: need root privileges
.
/etc/rc: /etc/rc.local[7]: touch: not found
NO WRITE ACCESS
/dev/wd0a (0123456789abcdef.a): UNEXPECTED INCONSISTENCY: RUN fsck_ffs MANUALLY.
R/W mount of / denied.  Filesystem is not clean - run fsck
mount_ffs: 0123456789abcdef.a on /: filesytem must be mounted read-only; you may need to run fsck
R/W mount of /extra denied.  Filesystem is not clean - run fsck
mount_ffs: 0123456789abcdef.l on /extra: filesytem must be mounted read-only; you may need to run fsck
R/W mount of /home denied.  Filesystem is not clean - run fsck
mount_ffs: 0123456789abcdef.k on /home: filesytem must be mounted read-only; you may need to run fsck
R/W mount of /tmp denied.  Filesystem is not clean - run fsck
mount_ffs: 0123456789abcdef.d on /tmp: filesytem must be mounted read-only; you may need to run fsck
R/W mount of /usr denied.  Filesystem is not clean - run fsck
mount_ffs: 0123456789abcdef.f on /usr: filesytem must be mounted read-only; you may need to run fsck
mount: statfs /usr/X11R6: No such file or directory
mount: statfs /usr/local: No such file or directory
mount: statfs /usr/obj: No such file or directory
mount: statfs /usr/src: No such file or directory
R/W mount of /var denied.  Filesystem is not clean - run fsck
mount_ffs: 0123456789abcdef.e on /var: filesytem must be mounted read-only; you may need to run fsck
starting network daemons:/etc/rc.d/cron: /etc/rc.d/rc.subr[141]: basename: not found
/etc/rc.d/cron: /etc/rc.d/rc.subr[154]: printf: not found
starting network daemons:/etc/rc.d/cron[9]: id: not found
starting network daemons:/etc/rc.d/cron[9]: [: 0: unexpected operator/operand
starting network daemons:/etc/rc.d/cron: need root privileges
.
DOW Mon DD HH:MM:SS GMT YYYY
...
Mon DD HH:MM:SS init: can't exec getty '/usr/libexec/getty' fr port /dev/ttyC1: No such file or directory
Mon DD HH:MM:SS init: can't exec getty '/usr/libexec/getty' fr port /dev/ttyC2: No such file or directory
Mon DD HH:MM:SS init: can't exec getty '/usr/libexec/getty' fr port /dev/ttyC3: No such file or directory
Mon DD HH:MM:SS init: can't exec getty '/usr/libexec/getty' fr port /dev/ttyC5: No such file or directory
Mon DD HH:MM:SS init: can't exec getty '/usr/libexec/getty' fr port /dev/ttyC0: No such file or directory
... Then after some time...
Mon DD HH:MM:SS init: can't exec getty '/usr/libexec/getty' fr port /dev/ttyC2: No such file or directory
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/console): Read-only file system
Mon DD HH:MM:SS init: can't exec getty '/usr/libexec/getty' fr port /dev/ttyC5: No such file or directory
Mon DD HH:MM:SS init: can't exec getty '/usr/libexec/getty' fr port /dev/ttyC3: No such file or directory
Mon DD HH:MM:SS init: can't exec getty '/usr/libexec/getty' fr port /dev/ttyC1: No such file or directory
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/console): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wskbd): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wskbd): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wskbd0): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wskbd0): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wsmouse): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wsmouse): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wsmouse0): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wsmouse0): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/ttyCcfg): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/ttyCcfg): Read-only file system
Mon DD HH:MM:SS init: can't exec getty '/usr/libexec/getty' fr port /dev/ttyC0: No such file or directory

...
Then after some time...




console
2
console
531
console...ttyCcfg
0

2351
console console ttyCcfg
ttyC0

Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/console): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/console): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wskbd): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wskbd): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wskbd0): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wskbd0): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wsmouse): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wsmouse): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wsmouse0): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wsmouse0): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/ttyCcfg): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/ttyCcfg): Read-only file system
Mon DD HH:MM:SS init: can't exec getty '/usr/libexec/getty' fr port /dev/ttyC0: No such file or directory
...............................
...............................
...............................
...............................
Mon DD HH:MM:SS init: can't exec getty '/usr/libexec/getty' fr port /dev/ttyC1: No such file or directory
Mon DD HH:MM:SS init: can't exec getty '/usr/libexec/getty' fr port /dev/ttyC5: No such file or directory
Mon DD HH:MM:SS init: can't exec getty '/usr/libexec/getty' fr port /dev/ttyC3: No such file or directory
Mon DD HH:MM:SS init: can't exec getty '/usr/libexec/getty' fr port /dev/ttyC2: No such file or directory
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/console): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/console): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wskbd): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wskbd): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wskbd0): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wskbd0): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wsmouse): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wsmouse): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wsmouse0): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/wsmouse0): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/ttyCcfg): Read-only file system
Mon DD HH:MM:SS init: /etc/ftab: chmod(/dev/ttyCcfg): Read-only file system
Mon DD HH:MM:SS init: can't exec getty '/usr/libexec/getty' fr port /dev/ttyC0: No such file or directory

In this case, keyboard input will be useless. (It may cause the display's contents to scroll up one line, but is otherwise pretty useless.) /dev/ttyC4 (which corresponds to the terminal shown when pressing Ctrl-Alt-F5) may not be generating errors because it may be turned off by default. (The reason for that is that the terminal may be reserved for use with X Windows.)

Ugh. The only way to deal with that solution is to reboot. (As the three-finger salute may also have no impact.

A way around this problem is to not let multi-user mode start up. Boot into single user mode. (To do that, reset the computer and when the boot> prompt shows up, type “boot -s” (without quotation marks, and then press Enter).

Then, upon the system being restarted, press Enter at the prompt that says:

Enter pathname of shell or RETURN for sh

Then run:

fsck

...or, to save some time, run:

fsck / /usr /var /tmp

Other directories, like /home and anything under /srv or /media or /mnt, may also need to be checked, but they can probably be done after the system is booted into multi-user mode. (However, either check all the drives or make sure that remote access is sufficiently working for a user before walking away from the ssystem. If a required key file is on /home then perhaps an intended administrator account won't be able to authenticate, even if the remote access server is able to start.)

Hopefully each drive that results in a prompt will result in the file saying:

MARK FILE SYSTEM CLEAN? [Fyn?] 

Be careful to check the question that is asked. If any other question gets asked, carefully weigh options before deciding. (The safest course of action may be to clone the drive before trying to make any changes.)

If the prompt does look just like the above, then say y to accept. If there is any other prompt, the safest thing to do would be to say no, and then mount the drive read-only, and copy off any needed data. That may be time-consuming. Another option, which may be far less safe (and more likely to cause data issues), is to use the fsck -p /tmp ”. Details may be in the section about testing and/or repairing filesystem volumes.

After all of the critical drives are cleaned, at the command prompt, simply press Ctrl-D twice, which will act the same as running exit, which will cause the system to continue booting (which will be faster than running reboot which would also work).

After the reboot, see if all drives are mounted. The list of drives may be referenced by viewing the filesystem table which is the data in the /etc/fstab file. Any drives that failed to be mounted should be checked. After they are marked clean, mount them (which can be done quickly by running “ mount -a ”).

Then, see if there is any indication why the system was restarted without properly shutting down the filesystem (which is why this whole situation occurred in the first place).