System Startup

Side note: Information about shutting down a system may be found at section about shutting down a system.

Initial code stored on chips

The purposes of the initial code are generally to initialize all of the hardware, perform some basic checks, and find and execute some other, more elaborate code (such as an operating system stored on physical media). Another common feature of the initial code is to provide some method of configuring how the code performs its other tasks.

Initial startup code (firmware)

Some (and perhaps nearly all) of this information is going to be specific to certain platforms, such as the Intel 80x86 hardware platform (used by many devices, including systems using an Intel 8088 CPU, Intel Pentium systems, and devices made by rivals such as AMD). Many systems using the newer x64 platform will also be similar.

“BIOS”: “Basic Input/Output System”

The BIOS code has been used in early computer systems.


“Complementary metal-oxide-semiconductor” is usually mentioned by its abbreviation, “CMOS”. Many computers use CMOS technology to store the firmware code's setup configuration data, so changing the firmware code’s setup configuration data is often referred to as setting up the CMOS's configuration data.

Typically such changes are made using a program that is often referred to as “CMOS setup”, or “firmware setup” (or a term reflecting the name of which type of firmware software is being used, like “UEFI setup” or “BIOS setup”). Both “CMOS setup” and “firmware setup” are names which are technically accurate, since the “setup configuration” that gets changed is the collection of bits storing the firmware’s configuration data, and this same setup/arrangement of bits is what will be stored by the CMOS technical component.)

(Besides the term “firmware setup”, this has also been known by more specific terms that identify the firmware. On a computer using firmware called UEFI, this software program has been known as “UEFI setup”, and on computers using the older firmware style which was commonly named “BIOS”, this has been known as the “BIOS setup” program.)

The BIOS will generally perform a “Power-on self-test” (“POST”) procedure.

At some point in the boot process, before code is run from a hard drive, the BIOS will check to see if any of the expansion cards have an “option ROM” with code that should run. After each expansion card has had any existing “option ROM” sequences started, the code will look onto one or more disks for a sector that contains a signature known as the “magic” signature.

If no boot code is provided, very old IBM computers would do something useful: run code from a ROM that provided an interface to the programming language named BASIC. (At least some Apple 2 computers also did this same sort of thing.) Other computers may provide a message about the problem, and may then either reset themselves (in the hope that things will be more successful when retried) or the computer prompt the user to press a key. The user may then reboot with either a simple key press, like tapping the space bar, or by performing the traditional “three-finger salute”.


Wikipedia's page on OpenBIOS says, “Most of the implementations provided by OpenBIOS rely on an additional lower-level firmware for hardware initialization, such as coreboot or Das U-Boot.”
Previously known as LinuxBIOS
Open Firmware
Wikipedia's article for Open Firmware
[#phenxtch]: Phoenix Technologies
Phoenix made PhoenixBIOS
Award Software International Inc. (see Wayback Machine @'s archive of says, “Award Software became part of Phoenix Technologies in September 1998 and we have joined our web sites”. In June 1997 (about fifteen months earlier), Award acquired a BIOS upgrade provider called Unicore. HighBeam Research noted, “With the acquisition, Award gains exclusive ownership of several products including MR BIOS(R), which is used in BIOS upgrade products”.
American Megatrends Incorperated
Other offerings
SystemSoft Corporation had assets purchased by Insyde Software.

The exact options provided will vary based on what version of BIOS code is being used. Typically the BIOS code shipped with a computer will only show options relevant to that system, although there may frequently be output (such as “N/A”) reported from sensors that don't exist.

Tech ARP's BIOS Optimization Guide (simlified/free edition) provides details about a number of BIOS options.

[Unified] Extensible Firmware Interface

The latest versions of EFI are called UEFI. The one change between EFI and UEFI which is probably most notable is which organization has been in charge of the specification. Wikipedia's article for “Unified Extensible Firmware Interface” states, “Intel developed the original Extensible Firmware Interface (EFI) specification.” Later, the article notes, “In July 2005, Intel ceased its development of the EFI specification at version 1.10, and contributed it to the Unified EFI Forum, which has developed the specification as the Unified Extensible Firmware Interface (UEFI). The original EFI specification remains owned by Intel, which exclusively provides licenses for EFI-based products, but the UEFI specification is owned by the UEFI Forum.” FAQ notes, “There will not be any future versions of the EFI specification”.

Linus's take on EFI (also quoted by KernelTrap news showing Linus's take on EFI, as archived by the Wayback Machine @ demonstrates an attitude about handling early pre-OS system startup code: the best thing for the code to do is to perform the minimal critical functionality necessary to then be able to run the operating system. EFI may violate that design, by providing features/complexity/bloat in the pre-OS environment.

Theo de Raadt's notes on (U)EFI) (other mirrors: Theo de Raadt's notes on (U)EFI), Theo de Raadt's notes on (U)EFI) indicate that this approach is quite dangerous to people's ability to run some types of excellent software.

Despite the nay-saying of those leaders of “open source” “operating systems”, computer manufacturers have embraced UEFI. Key reasons for this are likely support by Intel (who made EFI), Apple (who agreed to use it for x86-based hardware), and perhaps more significantly, Microsoft. With the 64-bit versions of Microsoft Windows Vista and newer operating systems, using UEFI was the one method of supporting GPT that was usable by Microsoft's operating systems. Microsoft still held significant sway in the computer marketplace (after being even more dominant around the turn of the millenium), and so computer manufacturers wanted to be sure to support at least that bootable firmware.

There are multiple versions of (U)EFI, and that seems to have at least some impact on compatibility. For instance, there is some software called the “UEFI SHell” that doesn't work with older versions of EFI. (So, in about two decades or less (by March 26 of 2016 when Tom Yan wrote that answer), (U)EFI seems to have not managed full backwards-compatibility as much as what BIOS seems to have managed over a matter of decades.)

Some implementations:

Some other offerings
Insyde Software
American Megatrends
An option may be the &dlquo;Aptio Setup Utility”, which shows “Copyright (C) 2010 American Megatrends, Inc.” (as shown by a screenshot seen on Stone Group page, “How to Access the EFI Shell to carry out Systems Diagnostics or Updates”).

Some software called the “EFI Shell”, and later named the “UEFI Shell”, has been released. Apparently some UEFI firmware may come bundled with this, and provide an option to boot this directly. However, not all systems that support UEFI will provide this option. What they should be able to do, though, is run the software, which can be started using removable boot media.

Apparently some computers have been known to include the UEFI shell as a pre-installed bootable option. If so, you may be able to interact with UEFI software to specify that you want to run the UEFI shell. An example of this is shown on Stone Group page, “How to Access the EFI Shell to carry out Systems Diagnostics or Updates”. On that page, a screenshot shows an “Aptio Setup Utility” screen where a &dlquo;Boot Manager” tab shows “internal EFI Shell” shows as a boot option (alongside other boot options, such as booting from a DVD-RW drive).

However, it is definitely true that not all computers have that option readily available. (Actually, maybe only a small minority do.) Therefore, for some computers you may need to add the software yourself in order to use it.

The easy way to avoid problems when trying to use some new bootable code is to ensure that SecureBoot is disabled. (Otherwise, you will need to ensure that authorized SecureBoot keys are in place for the boot code you use.)

One of the safest ways to pull this off may be to use some removable media. The rEFInd project provides images (which are not signed with SecureBoot) intended for a USB and/or CD, and those boot images contain the UEFI shell. Simply boot off of one of those images, and choose the option to run the UEFI shell.

Or, instead of downloading a package that contains UEFI shell, you can go through a bit more work to just get the shell software directly:

Arch Linux: UEFI page, “Obtaining UEFI Shell” section notes, “You can download a BSD licensed UEFI Shell from Intel's Tianocore UDK/EDK2 project”.

EFI-Shell at SourceForge

When booting, you may see a “Shell> ” prompt. A typical thing to do at this prompt is to quickly change the “current” location to a device, such as running the fs0: command. If doing so, the prompt will change (e.g., to “fs0:\> ”) and there might not be a way to get back to the locationless “Shell> ” prompt, short of restarting the shell. (However, even though that may be rather irreversible, that likely isn't a bad thing to do.)

Stone Group page, “How to Access the EFI Shell to carry out Systems Diagnostics or Updates” notes, &dlquo;EFI tools can only be used when the main operating system is not running. If you are not in a postition to be able to down the server, use operating system tools instead.”
Some UEFI Shell commands

It is helpful to know, right away, that many commands have built-in support for “paging” (which means to pause output after showing a full screen of information) by using the -b option.

Commands may include:

As shown in the bottom line of help, there is a -b option. That will act as a pager. i.e.: help -b
Some documentation hinted that using a command called ? (just the question mark) acts like the help command. (Experience suggests otherwise, and found that ? was just an unknown command.)
You may find that sometimes the terminal wants to show blue, but blue on black may not be very visible on some screens. In that case, try: cls -b cls -b in particular, try: cls 3 That (dark cyan background) might look rather ugly to some people, but at least function decently. Blue looks rather visible with “cls 3” or cls 6 (yellow). Green and bright white can look pretty visible when using cls 7 (dull/faded white).

David Tonhofer's answer to Silver Quettier's question about a USB device detected in “Intel EFI shell” shows some screenshots of the “UEFI Shell” software.

shows currently-detected data storage devices e.g., fs0 may be the first filesystem found
typing a filesystem name, followed by a colon, and pressing Enter goes to it After doing so, the shell prompt will change from Shell> to the filesystem name followed by a >
if that doesn't work, try: gdisk_x64.efi (or, simply, “ gdisk_x64 ”)
Loads PCI Option ROM






Same as map. (help mount showed the help text for map.)



Some indication existed to suggest this was only available in v2. However, some EFI 1.1 shell documentation mentioned it...



shows device info








run a file that is remote


Arch Linux: UEFI page mentions being “provides a basic text editor with an interface similar to nano, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.” Also, “Type Ctrl-E for help.”


modifies file, memory, or block device

HPE Community: EFI 1.1 Shell Commands (“DRAFT” document) (PDF file), UEFI Shell (section on &dlquo;Internal EFI Shell Commands”), Unofficial Command Reference for EFI Shell commands

Other hyperlinks that might be worth checking out: question on booting EFI shell has some hyperlinks ( AltLinux Rescue here mentions webclient (is that part of standard UEFI, or just softare found on Proliant machines?), handles HTTP and FTP and mounting ISO. ) EFI Shells and Scripting

An (untested, unverified) example of what to do with EFI Shell, if sufficiently prepared (having other required data available) - CHIPSEC (CHIPSEC on Bootable USB with UEFI Shell).

Besides the UEFI shell, other software may be available. e.g., Windows GPT FAQ (archived by the Wayback Machine @ mentions “Diskpart.efi Disk Partition Tool”. Also, Microsoft Support: Frequently asked questions about the GUID Partitioning Table disk architecture mentions “Diskpart.efi” (multiple times). These references probably refer to the Diskpart.efi which has probably been distributed by Intel (after being licensed by Microsoft). The UEFI Disk Utilities (Download Agreement) references “Microsoft EFI Utilities” including “Diskpart (Disk partitioning utility), Efifmt (EFI Format utility) and Efichk (EFI Check Disk utility) stored in a file named” (Text styling was added to that quoted text, based on an interpretation of text's intended meaning.)

Other firmware options

Coreboot, uboot, OpenBoot, LinuxBoot (which replaced “non-extensible reduced firmware” (“NERF”))

[#optrom]: Option ROM

Some cards may have code on an Option ROM. There may be various names for this sort of functionality, such as OpenBSD's “manual page” for i386 system bootstrapping procedures which call these “extension ROMs”. An option ROM will typically print some material onto the “default console output” (which is typically the video display screen), and may even allow for some interactivity.

As an example, circuitry which provides RAID functionality, often supplied by a card in an expansion slot, may allow users to see and optionally modify details about what hard drives are being used by each RAID volume. (That might be the most common example of where an expansion card provides interactivity directly. Other expansion cards can generally have configuration occur after an operating system loads. In contrast, this functionality on a RAID card may need to be provided in order to help get the operating system to be able to load successfully. The need for a successful configuration in order to load an operating system from the hard drives may be a key reason why the manufacturers provide this functionality. Many other devices may be configured from within an operating system more easily than RAID cards.)

Entering Firmware Setup

Some computers may provide multiple ways to enter the Firmware Setup program. Some may provide only one. Details in this section ahve been known to vary between different computers.

Some newer operating systems have provided a way to specify that the computer should reboot and enter the Firmware Setup program. However, this method may not work on some computers (even when running an operating system), and there are times when entering the Firmware Setup program may be desired when an operating system is currently unavailable. Therefore, even though it is good to know about a possible option involving an operating system, knowing about alternatives can also be quite useful.

During system startup

The firmware setup program is typically only reachable during the early stages while a computer boots. (However, TOOGAM has personally used an old pre-486 system which could have the CMOS be entered with Ctrl-Alt-Ins while in a DOS prompt, and then after making the change, the CMOS could exit back to DOS. So entering the BIOS setup is theoretically possible to do at some time other than the system startup. However, in practice, such an ability is exceedingly rare.) The keystroke or keystroke combination used to enter the BIOS setup program does vary between different machines. The most comon entry point would be Delete, although some other ones that exist are F1, F2, F12, F10, F11, F8, Esc, Ctrl-S, or holding both Ctrl and Alt and pressing either Esc, Ins, or Enter. Other combinations may involve holding Alt or Shift while pressing one of the previous combinations, or perhaps even something more elaborate such as holding multiple keys (which would typically be Alt, Shift, or Ctrl).

For some systems, pressing one of these keystroke combinations may cause the BIOS program to do something other than entering the BIOS setup program. For example, it may prompt the user regarding what media to boot from. (Examples may be choosing from various hard drives or removable media, or possibly booting with a boot image downloaded from the local network.) Choosing such an option may cause an alternate boot method for that one boot, and leave the general configuration unchanged, so when the system boots again it will use the configuration which is still saved in the CMOS. If such a prompt shows up but is not desired, try pressing Ctrl-Alt-Delete and then trying again to enter the BIOS setup program. Generally pressing Ctrl-Alt-Delete this early into the boot process (before any code is executed from a disk) will perform a “cold boot”, allowing another opportunity to go into the BIOS setup program.

Lifewire: “ BIOS Setup Utility Access Keys for Popular Computer Systems” provides some keys. iSunShare: Keys for various BIOS/UEFI also shows some details for certain computer types.

[#frmwfros]: Entering Firmware Setup from the operating system

Note: At the time of this writing, much of this has not been tested (recently) by the author of this text.

Credit: Thanks to's page: “How to Access UEFI BIOS Setup in Windows 8/10 New PCs” for some of these details.

Windows 8+ Command Prompt

You may need to get to a UAC-elevated command prompt.

Run: shutdown /r /o

Windows 8+: If logged out

(Requires keyboard. May require a rodent as well?)'s page: “How to Access UEFI BIOS Setup in Windows 8/10 New PCs”, section called “Method 4: By Holding down Shift While Choosing Restart Button” provides pictures.

Find the “Power” logo, which brings up a menu with options like “Shut down” and “Restart”.

Hold down the Shift key while clicking on "Restart".

Choose: Troubleshoot, Advanced Options, System Settings, Restart. This restarts the system to a "Startup Settings" screen. From here, one of the choices provided is “Press F10 for more options”. Utilize that option, and then “Launch recovery environment”.

Windows 8+: If logged in

You will need to be signed in for this approach. If you are already signed into the operating system, then despite the process being nine steps long, this may be one of the fastest methods. (Overall, this might not be quite as quick as pressing a hotkey at the right time of the startup process, although since that process can involve some guesswork, this more-surefire way may be faster if this is available.)

  1. First, perform the first part of these steps. Unfortunately, this process has changed a bit, so this will depend on what operating system is used.
    Windows 10

    Start, Settings, Update & Security, Recovery

    Windows 8 (or 8.1)
    Settings, Change PC Settings, General
  2. Then, choose these steps:
    • Advanced startup, Restart Now, Troubleshoot, Advanced options, UEFI Firmware Settings, Restart
Key areas of the disk
Boot blocks/partition tables

A “boot block” refers to a sector on a disk that contains data in a specific recognized format. This format is designed to provide some information about how the system should be able to “boot” (start up) and how data is laid out on the disk. This data may often contain one, or both, of two things. The first boot block that really gets used will typically contain both of these things. The first of these things is code meant to be run directly (generally before any full-fledged operating system is loaded). The second of these things is a “boot record” which contains a “partition table”. A “partition table” contains information about where one or more “partitions” on the disk are location. A “partition” is a group of sequentially-addressed sectors on the drive, which which is separate from other partitions. That simply means that none of the sequentially-addressed sectors in one partition should exist in any groups of any other partitions. (If such a thing happened, it could be considered an error by some software, and could easily result in data loss due to programs assuming that each partition is sufficiently separate.)

In general, code on a boot block is fairly minimal and it is designed to execute other code which is found in a partition. That additional code might even be another small chunk of code, located in another sector that uses the standard “boot block” format that provides only very little space for code. Eventually, some of the code that gets run will typically locate a large amount of code (that is typically stored in a file, located in a filesystem), and then runs that larger chunk of code.

Master Boot Record (“MBR”)

Traditionally, the first boot record on a hard drive is called the “Master Boot Record” (“MBR”). It is generally the main reference point to determine what “primary” partitions exist on a drive, and also includes the IPL code.

Details about what is included in this part of the disk may vary a bit based on which disk structure is being used. As a more specific example, traditionally the most common disk structure had been the classic MBR Partition scheme. The documentation about that disk layout contains details about what may be found in a boot block.

The term “partition table” generally refers to a specific data structure that is commonly found in boot blocks (used by the MBR Partition scheme). This format works for partitions on disks that are not larger than 2 TB. Traditionally, this information on a partition table is data that may be modified by using software that sets up MBR partitions.

Boot code
Initial Program Loader (“IPL”)

On a disk that relies primarily on MBR partition, the first boot code is on the MBR. Other boot blocks may exist in other locations. The main job of the code on an MBR's boot code is generally redirection. The code may or may not offer some sort of interactivity to allow the user to choose which operating system to load. If so, the code may be considered to be a boot manager. However, once the decision is made, then the code which is running will generally direct the computer to run other code on another sector on the disk which is called a “boot sector”. The boot sector may include, or redirect the booting process to, a boot loader?

[#dyndrvov]: Dynamic Drive Overlay (“DDO”) software

This sort of software has not been very common. However, if it does exist, it likely is the initial code that runs, and it will then run some other code that is generally designed to be the first code that gets run. The main purpose of such software has been to support hard drives which may be larger than what is supported by the BIOS. This was more useful in the days before BIOS code was easily updatable: In many cases older computers would have the BIOS code stored on a ROM chip and so if there was any way at all to update the BIOS, that method involved replacing a ROM chip. However, if the computer boots the DDO software and the DDO software then continues the boot process, the DDO software can make the large hard drive work even in cases where the ROM's BIOS code doesn't support the drive. The software that makes this work may be called a “software translation driver”.

Probably the worst part about using DDO software is that the data on the hard drive is stored in a layout which may not be a very well known standard. (At least in theory, the layout may be proprietary.) In theory, this is not a problem because the DDO software can successfully work with the non-standard layout being used, so other software should not have troubles dealing with the non-standard layout that is handled by the DDO. An example of where this may become a problem is if a system's main hard drive is about to become a secondary hard drive because the computer is getting an upgrade of disk space and the newer, larger, faster hard drive is going to become the primary hard drive. In general, this means that the newer hard drive should be booted. However, unless the DDO is booted, the information stored on the older hard drive is not easily accessible.

The next biggest problem about the DDO software is that the DDO software might not very compatible with many operating systems. On supported operating systems, the DDO software may use up some resources: there may also be a speed hit with DDO software, as well as memory being used up in order to support the DDO continuing to run. Specialized tools, such as data recovery software, may not be able to work with data that is encoded for support by a specific DDO.

Because of these problems, some general advice used to be: Use DDOs only when absolutely necessary. However, more modern common advice is: Avoid them altogether, except if trying to retrieve data from a drive which is already using a DDO. Even in that situation, the advice may be to retrieve whatever data is needed, and store that data onto a different drive so that continued use of the DDO is not needed any longer. If there seems to be a situation where it looks like using a DDO would be helpful, try to change the situation, possibly by using a newer hard drive (and a newer computer). Western Digital's Answer ID 1101: How to install Dynamic Drive Overlay (DDO) on a hard drive says, “Western Digital recommends using the Dynamic Drive Overlay software only as a last resort. If possible, you should upgrade your system BIOS or purchase a controller card to obtain the BIOS support you need to support your new hard drive.”

Perhaps the most widely used DDO software was “Disk Manager”, created by Ontrack Data International (which is described further in the glossary), and this software has been licensed to several hard drive manfuacturers. Ontrack's web page for Disk Manager says the software “Supports installation” of hard disk drives by several manufacturers “including Fujitsu, IBM, Maxtor, Quantum, Samsung, Seagate, Toshiba, and Western Digital.” At least one of these manufacturers (Western Digital. Others?) have released Disk Manager using the brand name of the hard drive manufacturer. Examples of some software that do or may support a DDO: (e.g. Ontrack Disk Manager and Micro House EZ-Drive, page about drive overlay software ). Possibly some software which is branded by the hard drive manufacturer, such as at least some versions of Maxtor's Maxblast (apparently, unconfirmed), Western Digital's Data Lifeguard Tools Samsung FAQ: Uninstalling Disk Manager's Dynamic Drive Overlay

Boot manager

The main task of the code on the MBR (or any alternative boot loader that may be used) is generally to determine which partition/volume boot record (“PBR”/“VBR”) to execute code from, and then to execute that code.

Traditionally the desired partition boot record to run code from is the boot record on the partition that has the “active” flag set.

This traditional code has been considered to be widely insufficient by many people who find the approach to be far more inflexible, compared to an interactive approach. OpenBSD FAQ 4: section on “Multibooting OpenBSD/i386” (and OpenBSD/amd64) (OpenBSD FAQ section 4.9) has a section called “Setting active partitions” which makes a compelling arguments on why this traditional approach may actually be more convenient. Namely the benefits have to do with compatibility, and the ability to fully start up a system without the user trying to interact during the small window of time that a user has to specify a specific (non-default) choice. (The attitude made a bit less sense on slower computers that had longer boot times; people often preferred the ability to make a last minute decision so that they could be spared from needing to wait a long time for the system to boot up.)

A boot manager is a program which is run early on during the boot process, and which can boot one or more different operating systems by selecting which additional boot code to run. Then, naturally, after the boot manager has selected which code needs to run, the boot manager runs whatever code has been selected. For example, GAG, the graphical boot manager presents the user with a graphical menu from a selection of pre-configured operating systems, and can choose to boot a floppy disk after the hard drive booted. Most boot managers do allow some sort of interactivity, allowing changes to be made at the time that the system boots. The term “boot manager” typically refers to a program that provide this level of interactive interaction. (Code that performs a similar process of helping to start up the system, but which does not allow any sort of interactivity, might often be called a “boot loader”.)

verify: OS/2 probably just read details which could be set by a command line program called “BOOT”. A change could be made by running this command line program named “BOOT” after the system had been started up fully.

Other boot managers may allow booting operating systems without requiring pre-configuration, and instead will simply boot the partition specified. Some boot managers try to fit in the MBR, while others use space that is allocated in a partition table. OS/2's boot manager required a partition of its own, although the NTLoader from Microsoft Windows (confirm this) uses an existing standard file system and uses configuration in the \BOOT.INI file. Some boot managers may use other sectors on the hard drive, which are unlikely to be allocated by any recognized standard “partition”. (This may be considered a violation of the design that expects data to be stored in partitions. However, for compatibility reasons, partitions often start at the beginning of a cylinder. That layout design truly does typically leave certain sectors unused. So, the boot managers who use this method typically do provide a comparatively nice experience by utilizing a resource (a certain small amount of disk space) that has commonly been under-utilized, while not using up a more precious resource (a partition table entry in a design where partition table entries may be fairly limited).

Stack Overflow page about x86 assembly instructions about a boot sector comment stated, “Here is a playable Tetris game written in assembly, and which fits into an x86 boot sector. I saw a variant of this which would boot your regular OS only if you could complete ten lines.” Presumably that could have been effective in preventing use of a specific computer by people who were relatively unfamiliar with technology. The code (for Tetris, not the variant for booting) was available: miKroTetRIS Boot sector (archived by the Wayback Machine @ (This software is no longer being hosted by the website where it was initially found. A mirror may also be found at TOOGAM's Software Archive: Mikrotet.)

Document about GRUB Boot Manager MBR/Boot Sector comments on the code.

There may also be some additional boot managers which have been more common, possibly containing additional features. For instance, some may contain only 16-bit code, which provides compatability for ancient computers that predate the 80386 CPU. Other boot managers might work better on new computer systems: some may be designed for 64-bit x64 systems (using BIOS and MBR), and others (such as rEFIt) may be designed for EFI systems.

Some boot managers

OpenBSD FAQ 13: “Using Drive: 0 Partition 3” error, archived by the Wayback Machine @ lists some boot managers including BootEasy, OS-BS.

Microsoft Windows Vista and newer come with “Windows Boot Manager (Bootmgr.exe)”, as noted by Overview of Boot Options in Windows Vista and Later. That is one of the components that performs some of the functionality of NTLoader, a component of Microsoft Windows Server 2003 and Microsoft Windows XP. More details, about “Windows Boot Manager” or “NTLoader”, are in the upcoming section about Microsoft Windows boot loaders.

[#btloader]: boot loader

The main job of a boot loader is generally to be able to properly load code into memory, including the kernel, and to be able to understand the filesystem well enough to find the kernel. There may also be some interaction with earlier parts of the system startup process.

A boot loader might have some ability to understand a file system that may be on a disk. This does not necessarily mean that the boot loader can fully understand all of the details of a filesystem. For example, the boot loader might not have all of the details that would be needed to implement a feature such as handling filesystem permissions, and might not even need to know how large a file is. The boot loader would simply need to be able to locate the boot code on the file system.

In some cases, the boot loader might not even need to fully understand how to locate a file in the file system. Instead, the boot loader may redirect the boot process to code that is at a specific location on the hard drive. This may offer less flexibility on where the boot code exists on the hard drive. (Various versions of DOS have had different restrictions regarding where the booted code may exist.)

In OpenBSD's case, the “first stage boot loader” gets installed by a specialized program (called “installboot”). When that program installs the boot loader, the program places a “hard-coded” (non-configurable) location inside the first stage boot loader. Then, the first stage boot loader uses that location to run the next code (which is OpenBSD's “second stage boot loader”). The next stage of the boot loader can be notably more advanced, understanding the file system and even checking a configuration file. If the second stage boot loader is moved to a different sector of the hard drive, possibly even if the hard drive is simply placed in a different computer that uses different hard drive geometry, then “installboot” may need to be run again to update the hard-coded location that is stored in the code of the first stage boot loader. This method may be considered particularly fragile compared to some other single-stage boot loaders, and the point of describing OpenBSD's behavior is not to recommend this approach. Rather, this implementation is simply being documented here as a demonstration of another method that could be (and, in fact, has been) used.

[#dosbtlod]: DOS Boot Loader
Older DOS options

Most versions of DOS, at least commercial software from the time that DOS was sold as an operating system that dominated the market, support just one possible filename for the boot loader. Most versions of DOS use \IBMBIO.COM except for MS-DOS which traditionally uses \IO.SYS. Note that despite the filename extension of .COM and/or the signature that makes the \IBMBIO.COM file look like an executable, this file is generally NOT an executable designed to work well if run from the command line.


Win9x may use other filenames instead of \IO.SYS, and another filename may even take precence over \IO.SYS. Possible filenames may include \JO.SYS, \IO.W40, \IO.DOS

After the DOS boot loader starts up, see: DOS kernel.

[#mswbtldr]: Microsoft Windows boot loaders
Windows 8

Windows 8 comes with two variations of the “Windows Boot Manager”. The new one is now named “Standard”. Another, named “Legacy”, is similar to what comes with Windows 7.

Using advanced options

To use the Advanced Options:

bcdedit /set {globalsettings} advancedoptions true

(To disable that, set to false instead).

How to enable the Advanced Boot Options menu at start up in Windows 8, by Scott St. Gelais from Geeks in Phoenix gets credit for sharing that command line. It also notes: “Warning! There is no default timer when the Advanced Boot Menu option is enabled in Windows 8 and the system will wait for user input every time it starts or restarts.”

Note, if you just want to boot a different way once, you can specify some changes that may be more short term: How-To Geek: Three Ways to Access the Windows 8 Boot Options Menu

Choosing the boot manager

To enable the Legacy style display output:

bcdedit /set {default} bootmenu legacy

(To disable that, set to “standard” instead of “legacy”.)

Booting in Windows Vista, Windows 7

Microsoft Windows Vista and newer come with “Windows operating system loader (Winload.exe)”, as noted by Overview of Boot Options in Windows Vista and Later. That is one of the components that performs some of the functionality of NTLoader, a component of Microsoft Windows Server 2003 and Microsoft Windows XP.

The “Windows operating system loader (Winload.exe)” will use the “system BCD store”. According to Microsoft's documentation (download page for “BCDedit_reff.docx”: BCDedit Commands for Boot Environment), a BCD store is: “A binary file that contains boot configuration data in Windows Vista and later versions. Boot applications use the system BCD store-which is on the system partition-during the boot process.” To see the contents of that BCD store, an administrator (that is not currently limited by UAC) can see the configuration using “BCDEdit/enum | more”. Or, Boot Configuration Data WMI Provider may provide another option.

Note: If the boot manager needs to be re-installed, this is not done from within the operating system's normal boot. First, Access the Windows Recovery Environment (“Windows RE”). Then use “ bootrec /fixboot ” to adjust the boot sector. If the boot manager isn't operating properly, going back into Windows RE again, and then using “ bootrec /rebuildbcd ”, can help (as noted by TeraByte Unlimited: Restore the Windows Vista/7/8 Boot Manager).

Operating system details

Note: Despite the commonly taught knowledge that the operating system is the first thing to load, there is strong reasoning to state that the operating system may commonly be the third thing to load. The things that come first include the initial startup code (the BIOS and the EFI, including any code started such as the POST by the BIOS and any code started by an “option ROM” on a card, such as the setup software available on some RAID cards), and then the initial booted code which may include a boot manager. However, the initial booted code may be considered by some to be part of an operating system, since it is frequently supplied by software that comes with an operating system, although it can also be supplied by independent third party software.

Operating system kernel
Choosing/specifying what kernel to load/use
Choosing a kernel in Microsoft Windows
Specifying a kernel in XP and Server 2003

In \BOOT.INI, see /kernel=filename (e.g. Microsoft KB 833721: Available switch options for the Windows XP and the Windows Server 2003 Boot.ini files and KB 170756: Available Switch Options for Windows NT Boot.ini File show /kernel=Ntkrnlmp.exe.)

[#doskern]: Kernel file in DOS

Most versions of DOS support just one kernel file. For the DOS bundled with 32-bit Microsoft Windows, the core kernel code is actually part of the main boot loader file. (More specifically, this is actually documented by the DOS Boot Loader sub-section.) Other DOS implementations use a single filename.

Most versions of DOS use \IBMDOS.COM except for MS-DOS which traditionally uses \MSDOS.SYS. Note that despite the filename extension of .COM, and/or the signature that makes the \IBMBIO.COM file look like an executable, the \IBMDOS.COM file is generally NOT an executable designed to work well if run from the command line.

Win9x actions

Win9x will also *require* the DOS configuration file that typically uses \MSDOS.SYS as the filename.

As noted before, Win9x may use filenames other than \IO.SYS for the kernel, as noted in the section about DOS's boot loader.

It is also possible to boot without a file that is using \MSDOS.SYS as the actual filename. Alternate filenames could include \WINBOOT.INI, \MSDOS.W40, \MSDOS.DOS.

(It is also possible to boot Win95/98 without a file named COMMAND.COM by using an alternate command line interpretor.)

More information about the \MSDOS.SYS file (or whatever it is named) is documented in the upcoming section, Win9x \MSDOS.SYS (and similar).

After processing that file, Windows ME does some interesting things other than the traditional \CONFIG.SYS processing. This will be discussed further (with a more detailed reference provided) by the upcoming section called Running the Microsoft GUI, which basically just refers to Windows ME trying to force GUI usage.

Hardware abstraction layers
HAL in Windows
Mount points

Mount points are names which may be used as a location that may be used to reference a file system's data. Processing mount points involves locating data (generally stored in a “file system”, using a name which will allow easy access to the data, and having the file system data readily accessible so that software will be able to quickly access the “objects” (such as files and directories/folders) on a file system.

The operating system typically makes the data of all detectable drives easily available to software. (Of course, the software's ability to simply have real useful access data resources, like files or perhaps even a drive, may be subject to limitations such as those imposed by security systems.) This process may actually occur at multiple times, so primary storage devices (like a hard drive) can be supported early on, and additional storage devices (like optical, USB, or other removable media) might be added at a later time. At least some of the mounting may be performed after the kernel has started to run code that is stored on a mounted file system. Some settings might be customizable; some of these details vary based on different implementations used by popular operating systems.

The operating system will “mount” at least one device that appears as direct local storage, such as a hard drive, and may load all of the drives that it recognizes based on the initial support provided by earlier code, such as a BIOS startup routine. After the operating system detects all such drives and loads at least some of the recognized file systems, the operating system may then continue following a routine which involves loading additional drivers. As an example, perhaps those drivers start enabling support for an optical drive and a network code. Those drivers may be needed to support mounting additional drives. For example, an optical drive using the Advanced Technology Attachment Packet Interface (a.k.a. ATAPI) standard may be inaccessible, initially, and remain inaccessable until after the hard drive is already mounted and the operating system locates the drivers that support the communications needed to support that drive. (This order of operations may be reversed by newer boot code which boots from a CD.)

Mount points in Unix

At some point, the operating system may run the “mount -a” command. The “ -a” switch causes mount to review the contents of a text file located at /etc/fstab so that mount can obtain details about what file systems should be mounted and what options should be used when mounting those file systems. (The filename fstab stands for “file system table”.)

(Further details about the file system table should be provided.)

Mount points in MS-DOS

Microsoft KB Q51978: Order in Which MS-DOS and Windows Assign Drive Letters

[#startcfl]: System startup configuration files
DOS (and compatible/similar)
[#configsy]: \CONFIG.SYS
Some commonly recommended settings

Though not required, it is a standard (often implemented) to specify a variable called COMSPEC. For instance,


or, better yet...


(That example won't work unless a file exists at that location. However, placing a copy of JP Software's command line interpreter is generally recommended. See: TOOGAM's software archive: JP Software.)

Standard DOS

There are various commands that may be specified in this file.

The most famous may be lines that start with “DEVICE=”, as that was the official typical way to install a “device driver”. (However, the technique of using a TSR was an alternative that many people found to be more pleasant. Also, device drivers could be loaded later, using third party programs. Details about that are avaiable from the compilation of programs from TOOGAM's Software Archive: DOS Starting.)


This section describes various supported filenames, and some differences in the supported configuration lines.

As an example of a variation, some versions of DOS can provide better results by using a command like “DEVICEHIGH=” instead of “DEVICE=”. However, this technique had no impact when using the default options of later Microsoft code. And older DOS releases might not even support the “DEVICEHIGH=” command at all.

The exact rules varied based on what operating system was used: OS/2 had additional commands beyond what was found in DOS. A lot of the information about the \CONFIG.SYS processing from Windows 98 were details that also applied to MS-DOS 6. The advantage to the Windows 98 documentation is that it is online (as noted in the upcoming section about Win95/98's \CONFIG.SYS processing). Additionally, a lot of other DOS releases also had a lot of similarities, and so a lot of that documentation may also apply to other versions of DOS.

Some other filenames

Some versions of DOS may support additional filenames. (Some of this may need to be verified.) DR-DOS may check for a \DCONFIG.SYS before using \CONFIG.SYS, FreeDOS may support (additional filename options?).


When the operating system is installed, some documentation for this file is placed in a %windir%\CONFIG.TXT file. This file may be viewed online: Microsoft KB Q232557: The Windows 98 Config.txt File.

On a side note, some documentation of various *.SYS files (that may be loaded from the \CONFIG.SYS file) may be in a %windir%\MSDOSDRV.TXT file. See Microsoft KB Q234868: Windows 98 Second Edition's MSDOSDRV.TXT file.

This operating system can load certain things into upper memory, and may do so automatically. Any DEVICE= line is effectively treated like a DEVICEHIGH= command unless there is a DOS= line which includes the noauto value, such as:


The most commonly used filename in Win95 and Win98 is \CONFIG.SYS (on C:), although other files may be used, at least sometimes, perhaps depending on what kernel file is used. For instance, a \CONFIG.W40 may be used. If using these alternate filenames, have backups and be careful while learning when some of these files may be automatically copied, overwriting some of the other potential filenames.

Windows Millenium Edition (“Windows ME”)

This operating system may alter the \Config.sys file by using a program called RegEnv32.

(If trying to disable this functionality, chances are there will also be a desire to learn about not loading up the GUI. See the section about automatically running the Windows GUI.)

There may be a file called config.nt. (This text currently has little further information, such as where that file may be, or how it is used.) Windows XP Documentation: The echoconfig command
OS/2 handling of CONFIG.SYS

OS/2 did have its own \CONFIG.SYS support, including commands that are not supported in DOS. Mark Crocker's Rexx Tips mentions “undocumented or poorly documented CONFIG.SYS statements used by OS/2.”

OS/2 could have a collection of settings regarding how to run a specific program. For DOS programs (and perhaps Windows programs?), some of those settings included being able to have custom CONFIG.SYS settings, such as loading drivers. So, a copy of a driver could be loaded for just one program (and be effectively unloaded, and therefore causing no effect, for other programs).

Loading software from the command line

A key reason why people often mucked around with settings in the \Config.sys file was to be able to load drivers. Some (actually, many) drivers were designed to be started during the operating system's startup procedure, and were not designed to be directly executed from a command line.

Some solutions have been created which allow loading such drivers from the command line. This may cause some overhead, and may also complicate an otherwise simple boot order (because these tools would generally not be able to be run during the CONFIG.SYS processing, unless using a driver that does load during the CONFIG.SYS which allows a program to run). On the plus side, this can allow starting drivers without requiring a reboot, more conveniently keeping drivers unloaded except for when they are needed, and possibly provide some features to unload drivers.

See: MDGx DOS Power Toys: Wrapper + FixWrap, and also see the section just above the “Wrapper + FixWrap” section, or this type of software. Also, TOOGAM's software archive: software related to starting software in DOS.

[#msdossys]: Win9x \MSDOS.SYS (and similar)

In Win9x, there is another text file which may be processed even before the \Config.sys file. There are multiple possible filenames for this text file. The most common filename for this type of file is \MSDOS.SYS (which is identical to the filename traditionally used for older versions of the MS-DOS kernel file).

TOOGAM's Software Archive: information specific to the MS-DOS software mentions some additional resources that discuss this configuration file. One of those resources is TOOGAM's software archive: a documented \WINBOOT.INI file that is highly commented and which will likely work, unaltered, in many cases. However, the file will need to be customized if Microsoft Windows was installed to another directory.

[#runwngui]: Running the Microsoft Windows GUI

In Windows 95 and Windows 98, the bundled MS-DOS 7 (or 7.1) may try to run the graphical interface.

This can be disabled by using a line in a text configuration file. The section about the \MSDOS.SYS file provides details about that text configuration file. Specifically, to do this, make sure there is an “[Options]” section after the “[Paths]” section that does exist by default. Then, make sure that “[Options]” section has the BOOTGUI=0 option.

Doing so has the desirable effect of not forcing the GUI. The GUI can still be automatically loaded from a batch file that is automatically started. The exception will be if “Safe Mode” is selected, and the batch file doesn't end up getting automatically started. As long as the user is familiar with that effect, and so knows to type win in such a case, then no ill effects are expected.

Windows Millenium Edition

Paragraphs have been written about this one aspect of this single operating system release, so the details are not in this more generalized section about computers starting up. Instead, the details are in a section with more details that are specific to Windows ME. See: Windows ME trying to force GUI usage.


BSD may process /etc/sysctl.conf.

Also, there may be a file called rc.conf which may or may not be intended to be edited. The reason to not edit the pre-populated rc.conf file is that another file may be intended to override rc.conf with customizations, and then the operating system makers don't have to worry as much about customizations being lost if rc.conf gets modified during a system update/upgrade. The supported file for storing customizations may be a file that doesn't pre-exist, but if a file is created at the supported location then that file will be effectively used. The location of rc.conf may vary among different operating systems.

In OpenBSD, the file to not edit (which comes pre-populated with data) is /etc/rc.conf while the file to go ahead and edit at will is the filename of /etc/rc.conf.local (which might not be a pre-existing file).

Drivers may often be commonly loaded at a standard point of the operating system's boot process. This will often be after the first set of mount points, so that drivers may be located on the filesystem. (Loading the drivers might begin to support additional mount points.) In DOS, drivers are loaded from a system configuration file, and the drivers may be passed parameters (similar/identical in concept to passing parameters from a command line).

At some point, and possibly multiple points, the operating system may place some restrictions upon itself. At least with BSD operating systems implementing “securelevel”, these restrictions are generally meant to help enforce security. See: OpenBSD Man Page for securelevel.

[#autoran]: Automatically started files

A GUI may be loaded automatically, or manually (including not being loaded at all). If it is done automatically, that is discussed in the Automatically started graphical environment section. This section contains more details about automatically started files. In some cases, some of the files in this section might be loaded after the GUI is loaded.

Automatically started files in Unix

There generally is some sort of method of automatically starting programs. Keep in mind that adjusting the system startup process can cause more difficulties than initially anticipated. In fact, following some details about what files are started, this guide covers some of the problems that occur during system initialization.

Details may vary based on the operating systems being used. e.g. OpenBSD initialization process may list some details for that operating system. Some relevant details may be provided in the documentation of a group of operating systems. So, if details seem insufficient when reviewing the documentation about an operating system, see if additional documentation is in the section about a group of similar operating systems, like operating systems derived primarily from old BSD code, or primarily derived from a specific flavor of Linux.

This may include some generalizations: if contrary details are in other documentation meant to apply to a more specific operating system, then those details are probably more likely to be applicable/accurate/correct.

The “init” command (which is started as part of the system startup process, and is often referred to as a command, but which is not necessarily (and probably is not) a command meant to be run from the command line, may run one or more “init scripts”. This may include files named *rc* (possibly including a file simply named rc located in or under the /etc/ subdirectory.

Common methods to run programs might include an rc.local file, using inetd (which may load configuration settings from the /etc/inetd.conf file), and/or using /etc/rc*.d directories.

OpenBSD “manual page” for inetd: the “super-server” details inetd, which basically listens to network traffic (e.g. TCP ports) and runs other programs as needed. Programs don't need to use inetd, but some programs do support being used by inetd (even if the programs also have support for directly listening to TCP ports).

OS specifics

Here are some more specific generalizations about which files typically get used.


The /etc/rc command may get started. OpenBSD's Manual Page called “afterboot” mentions “the master script /etc/rc. This script should not be changed by administrators.” Such a policy may not be true for all Posix systems, but this is true for some. The preferred way to customize the system startup, in such a case, is to use one or more additional files. A key reason for this may be so that operating system upgrades may be done easily without wiping out customizations. Details may vary amongst operating systems.

There may be a configuration file called rc.conf which, once again, may be something that should not be edited.

There may also be support for a file that is run (e.g. OpenBSD supports a /etc/rc.local file) and a configuration file (e.g. OpenBSD supports /etc/rc.conf.local file) that are designed to be edited. However, locations do vary: the precise full filename (including the path) meant to be customized in one operating system (e.g. FreeBSD) may be in a path that should not be edited in another operating system (OpenBSD). Therefore, become familiar with the information specific to the operating system being used before editing these file(s).

NIC initialization

Note: At least in OpenBSD, software/commands which are related to configuring the networking behavior of just one specific NIC, and which is software that might not be needed to be run for another NIC, is traditionally started from a file with a name similar to /etc/hostname.if0 (where “if0” actually refers to the name of a NIC). (For details about the names of available NICs, see the section about available NICs.) This file gets used when running “. /etc/netstart ” (which affects all NICs, or “. /etc/netstart if0 ” to (re-)initialize just one NIC.

The syntax of this file is described by the OpenBSD manual page for hostname.if (which is the literal name of the manual page: the “if” is part of what needs to be customized for the actual filename, but the manual page's title contains the literal text “if”). The most useful pieces to know is that a command may be run by placing an exclamation point at the beginning of the line (and then including the command and its parameters after that), and that there is a convenient variable called $if that may be used when this file is running. (By putting that reference in the text file, instead of the actual NIC's name, often the resulting text file will work for a renamed or new NIC simply by simply copying or renaming the file, and without need to adjust its contents.)


With more recent versions of OpenBSD, ClamAV may use some /etc/rc.d/ files. The older way to start ClamAV was to put something like this in the file:

[ -x /bin/mkdir ] &&
/bin/mkdir -p /tmp/clamd &&
/sbin/chown _clamav:_clamav /tmp/clamd

if [ -x /usr/local/sbin/clamd ] ; then
[ -S /var/clamav/clamd.sock ] && rm -f /var/clamav/clamd.sock
mkdir -p /var/run/clamd
chown _clamav:_clamav /var/run/clamd
/usr/local/sbin/clamd >/dev/null 2>&1

Implementations can certainly vary between different programs. A key point in this example is that the program's existance is tested for before an attempt to run it.


Files that may be used may include /etc/inittab and files in the /etc/init.d/ subdirectory.

(The following technical details have not been fully verified by the author of this text...) Zimbra's Performance Tuning Guidelines for Large Deployments: section about “Services to Disable” suggests using “ chkconfig --list ” and “ ps -ef

[#trmunini]: Problems running programs during startup:
Non-logged in environment

Note that programs running may be running as root. Also, they may not have had a standard login. A key way this can affect things is that the PATH environment variable may not be automatically set. Another variable that might not be set yet is TERM. These things can cause issues like programs not being found during the system startup, even though they work just fine when manually run later. Compensate for these sort of differences, as needed. A key thing to keep in mind is that running many programs may require specifying their full path. Also, custom scripts might start running okay, but they may fail to run a program if that program doesn't have the full path specified. (There is no particular reason this is limited to custom-made scripts, except that they might be less likely to be pre-tested for something like this, compared to scripts that come bundled with a downloaded package.)

Programs terminated at end of startup

The following behavior was found in OpenBSD: If a program is started as part of /etc/rc.local file, the program may start, but then be (undesirably) terminated. For instance, the /etc/rc.local file may run a script that starts Qemu as a background process. Then that script may show that Qemu did, in fact, start to run. However, when the script ends, then the Qemu session may be terminated. It is believed that a similar thing may happen if trying to run a shell.

The cause is not clearly known/identified/documented by the author of this text; perhaps a standard terminal is somehow not yet fully created?

A work-around has been to run the software within a terminal multiplexer: either in tmux or in screen.

Using tmux
env TERM=screen /usr/bin/sudo /usr/bin/tmux -f /etc/startup.tmx
/usr/bin/tmux -f ~root/startup.tmx

The configuration file could include:

new -d -s sessionName
neww -n FirstWindow 'echo Hello ; /bin/sh'
neww -n SecondWindow vi

(Side note: Those commands for tmux may be entered from within tmux, by pressing Ctrl-B and then : (a colon), and then typing the command.)

Make sure that a lacking PATH, during system startup, doesn't cause problems. For instance, if this configuration file runs a script file, reference the script file by name and also make sure that all programs it runs will be able to be found.

Make sure to follow the standard practice, after creating the script file, of making sure that it has the executable permissions that are desired. (This is discussed in the file attributes section. Basically, run chmod ug+x scriptFile ”.)

Using screen
screen -c config.rc -S customSessionName -m -d

Then the contents of config.tmx might look like this:

title windoNam

This example simply runs vi/

Additional documentation

“Understanding Init and Alternatives” lecture notes/outline by Rick Moen, on Rick Moen's Linuxmafia site

Automatically started files in Microsoft Windows
Multi-startup location checkers

There are multiple ways to quickly check multiple methods of starting up programs. For example:

WMIC Startup get /all

may show multiple registry entries. A graphical approach may be to use:

start MSConfig

Other pieces of software that likely check multiple locations may be Nirsoft WhatInStartup and Autoruns (by Sysinternals). (Older operating systems may have Nirsoft StartupRun, which might work in newer operatimgn systems but NirSoft recommends WhatInStartup.) AutoRuns looks in serveral places including software that is started at system startup, and other locations that third party software may commonly be loaded such as MS IE browser helper objects, Codecs, scheduled tasks, Sidebar Gadgets for Vista and newer, and can commonly show both standard executables and *.DLL files loaded from categories like “Winsock Providers”.

Process Explorer (see information about Process Explorer) may not have a section to list all software that automatically runs, but it might be able to help identify where a currently-running program got automatically started. On the View menu, choose “Select Columns...” and make sure “Autostart Location” is checked.

Startup folder

The easiest way for end users may be a folder called “Startup”. The entries may be loaded from multiple locations on the hard drive (with one possible location being user-specific and another possible location affecting multiple users), but regardless of where the shortcut link is located, it should be visible in the Startup folder when viewed using the Start Menu.


A method very common in modern versions of Microsoft Windows is to store information in the registry.

The most common location may be:

reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /s /z

There may be other locations as well. In addition to being under HKLM, the SOFTWARE\Microsoft\Windows\CurrentVersion\Run may be under HKU\ (under the user's SID). Near the Run key may be a RunOnce key.

Windows Startup Files
The methods of Windows 3.1 may still work even in later versions of Microsoft Windows.
Windows command line
In versions of Microsoft Windows that use a DOS-based startup sequence, DOS could pass a command line parameter to the program that started the GUI.
Automatically started file(s) in DOS

Most commonly, on the boot drive, \AutoExec.Bat will get run automatically.

Commonly a command line interpretor can also support having a specified batch file to run, and that can be done using the SHELL line in \Config.Sys on the boot drive. (That is not commonly done, but is commonly supported. So, it is commonly an available but unused option.)

[#sysgogui]: Automatically started graphical environment

Some operating systems start in a graphical environment. (For example, Ubuntu does.) Others do not. (For example, Debian does not.) Those that do may start in a text mode, but then automatically switch to a graphical environment.


In Windows 95, 98, and 98 Second Edition, if the BOOTGUI option specifies to start the GUI, then the GUI is started. This was effectively documented by Microsoft KB Q141721: How to Boot to a Command Prompt by Default. Microsoft KB Q142544: Windows 95/98 Command-Line Switches says, “ is called by Io.sys after the Autoexec.bat file is processed, and starts the Windows 95/98 startup process.”

User logins

This technically occurs after the system has been started: on many computer systems this is not automatic. However, since this happens before an end user can effectively make decent use of the computer, and this may automatically start some files, the process is similar to other detials in this section of documentation. So, this is covered here.

Unix logins
A program to log in with

Unix logins are traditionally handled by the login program. (However, is this not true if xdm is being used?)

In general, the login program checks for a username and a password. (A spawned program called login_passwd may actually do the password-checking for login, which may do other things to help set up a user's session.)

If the username and password are accepted, then the program looks for other details from the user's database, such as what the preferred command line “shell” program is. The login program may perform some tasks, such as setting environment variables, and then run the user's preferred shell command.

Some of these actions may be impacted by the presense of certain files. For instance, the /etc/login.conf configuration file may specify the location of a “nologin” file. If unspecified, /etc/nologin may/will be the default location. When the user's credentials are accepted, the login program may check the /etc/login.conf file to determine what login “class” a user belongs to, and what “capabilities” are assigned to users in that class. If the user does not have the the “ignorenologin” capability, then the login command will check for the presense of a “nologin” file. If that file exists, users without the “ignorenologin” capability will not be able to log in.

Another task, done when login actually logs a user in, is to set certain environment variables, such as TERM.

Welcome banners
[#hushlogn]: Hushed/Clean logins

Some programs will like a login that does not output anything. One example is rsync's FAQ about a “clean” shell. OpenBSD's manual page for rcp: section about “bugs” (from OpenBSD 5.5) also seems to indicate a problem with a non-clean login. OpenBSD's manual page for login notes that using a “.hushlogin” file “simplify logins for non-human users, such as uucp.” (This example is also seen in manual pages for other operating systems; its presense in OpenBSD's manual page does not mean that OpenBSD actually comes with the uucp command.) There may be more programs that like silence.

If a user has a ~/.hushlogin file, then that file's presense may affect the login program to cause certain actions, like outputting copyright information, to not occur. Another approach may be usable to hush a user's login, such as affecting the user's login class (see: OpenBSD manual page for /etc/login.conf file for an example).

However, just having that file there may not be sufficient: automatically executed script files could run programs that output. So, determining what files get automatically executed, and silencing them, may also be needed. As an example, many systems used to run the fortune command automatically. Usage of this often-humorous command is not recommended for a system-wide profile, as it can disrupt the ability for users to run certain programs. (However, having that be part of a user's default ~/.profile may be less of a problem, if users have the rights and generally have the knowhow to be able to edit that file.)

Usage of a file called ~/.hushlogin and/or a hushlogin value in the /etc/login.conf file (which is documented by a manual page for the /etc/login.conf file) may help such scenarios, while disabling any usefulness that comes from other actions like customizing the text of any system-wide messages.

Naturally, if an additional program is involved with a logon (such as SSH server software), and if that program outputs text (such as a “banner” that is output by SSH server), then that could also affect whether the login is considered to be hushed/clean.

The most centralized banner, likely to be seen, would be one placed in the system-wide script at /etc/profile as users may not have much/any real capability to silence that. Even before that runs, the login program may use a banner file which could be defined by the /etc/login.conf file (which is documented by a manual page for the /etc/login.conf file), or which may be at the default /etc/motd location.

Other banner locations could include sshd_config (which may be located in /etc/ssh/)

Unix files executed with user logons

Some files typically run may include /etc/profile and ~/.profile and a ~/.login file. Also, a file with a file path that starts with ~/. and then includes the name of the shell being used, and then the letters rc may be run. Specific examples include a ~/.kshrc file or a ~/.cshrc file. Users of bash may use the system-wide /etc/bash.bashrc as well as an individual's ~/.bashrc file.

A shell may decide, after executing any default scripts, to run $ENV (if that variable has been set).

Further info:

The section on individual operating systems may have more info.

Wikipedia's article on “Windows NT startup process”: “See Also” section refers to some startup processes for other platforms.

BCDEdit (Windows 7) documentation