WARN: This document has not been reviewed recently and many details may be
stale.

This document aims to detail, at a high-level, everything that happens between
machine power on and software components running on the system.

Outline:

- [Kernel](https://fuchsia.dev/fuchsia-src/concepts/process/everything_between_power_on_and_your_component#kernel)
- [Initial processes](https://fuchsia.dev/fuchsia-src/concepts/process/everything_between_power_on_and_your_component#initial-processes)
- [Component manager](https://fuchsia.dev/fuchsia-src/concepts/process/everything_between_power_on_and_your_component#component-manager)
- [Initial system components](https://fuchsia.dev/fuchsia-src/concepts/process/everything_between_power_on_and_your_component#v2-components)
- [Legacy component framework](https://fuchsia.dev/fuchsia-src/concepts/process/everything_between_power_on_and_your_component#v1-components)

## Kernel

The process for loading the Fuchsia kernel (zircon) onto the system varies by
platform. At a high level the kernel is stored in the


[](https://fuchsia.dev/docs/glossary#zircon-boot-image)


, which holds
everything needed to bootstrap Fuchsia.

[Once the kernel (zircon) is running on the system](https://fuchsia.dev/docs/concepts/process/userboot#boot_loader_and_kernel_startup) its
main objective is to start [userspace](https://en.wikipedia.org/wiki/User_space), where processes can be run.
Since zircon is like a [microkernel](https://en.wikipedia.org/wiki/Microkernel), it doesn't have to do a whole
lot in this stage (especially compared to Linux). The executable for the first
user process is baked into the kernel, which the kernel copies into a new
process and starts. This program is called [userboot](https://fuchsia.dev/docs/concepts/process/userboot).

## Initial processes

Userboot is carefully constructed to be [easy for the kernel to
start](https://fuchsia.dev/docs/concepts/process/userboot#kernel_loads_userboot), because otherwise the kernel would have to implement a
lot of [process bootstrap functionality](https://fuchsia.dev/docs/concepts/process/program_loading) (like a library
loader service) that would never be used after the first process has been
started.

Userboot's job is really straightforward, to find and start the next process.
The kernel gives userboot a handle to the ZBI, inside of which is the


[](https://fuchsia.dev/docs/glossary#bootfs)


image. Userboot reads through the ZBI to find the bootfs image,
decompresses it if necessary, and copies it to a fresh


[](https://fuchsia.dev/docs/glossary#virtual-memory-object)


. The bootfs
image contains a read-only filesystem, which userboot then accesses to find an
executable and its libraries. With these it starts the next process, which is
[component manager](https://fuchsia.dev/docs/concepts/components/v2/introduction#component-manager).

Userboot may exit at this point, unless the userboot.shutdown option was given
on the [kernel command line](https://fuchsia.dev/docs/reference/kernel/kernel_cmdline).

Component manager, the next process, is [dynamically linked](https://en.wikipedia.org/wiki/Dynamic_linker) by userboot. This
makes it a better home than userboot for early boot complex logic, as it can use
libraries. Because of this component manager runs various FIDL services for its children,
the most notable of which for boot purposes is bootfs, a [FIDL-based filesystem](https://fuchsia.dev/reference/fidl/fuchsia.io)
backed by the bootfs image that userboot decompressed. It also finishes parsing the ZBI and
decommits unnecessary pages, and uses the extracted information to host item, item factory, and
argument services.

Component manager marks its process as [critical](https://fuchsia.dev/reference/syscalls/job_set_critical), which means that if
something goes wrong and it crashes, the [job](https://fuchsia.dev/docs/reference/kernel_objects/job) that it is in is killed. As it runs in
the root job which has the special property that if it is killed the kernel force restarts the
system, component manager crashing will cause a reboot.

## Component manager

[Component manager](https://fuchsia.dev/docs/concepts/components/v2/introduction#component-manager) is the program that drives the
component framework. This framework controls how and when programs are run and
which capabilities these programs can access from other programs. A program run
by this framework is referred to as a


[](https://fuchsia.dev/docs/glossary#component)


.

The components that component manager runs are organized into a tree. There is a
root component, and it has two children named bootstrap and core. Bootstrap's
children are the parts of the system needed to get the system functional enough
to run higher-level software that includes the user experience.

The root, bootstrap, and core components are non-executable components, which
means that they have no program running on the system that corresponds to them.
They exists solely for organizational purposes.

![A diagram showing that fshost and driver manager, are children of the
bootstrap component and core and
bootstrap are children of the root component](https://fuchsia.dev/static/fuchsia-src/concepts/process/images/v2-topology.png)

## Initial system components

### Background

There are two important components under bootstrap, fshost and driver manager.
These two components work together to bring up a functional enough system for
the


[](https://fuchsia.dev/docs/glossary#session-component)


, which then starts
up all the user-facing software.

#### driver manager


[](https://fuchsia.dev/docs/glossary#driver-manager)


is the component responsible for finding
hardware, running drivers to service the hardware, and exposing a handle for
[devfs](https://fuchsia.dev/docs/development/drivers/concepts/device_driver_model/device-model) to Fuchsia. Devfs is being deprecated in favor of services,
which a driver exposes directly. (see [Driver Communication](https://fuchsia.dev/docs/concepts/drivers/driver_communication))

Drivers are run by


[](https://fuchsia.dev/docs/glossary#driver-host)


, which are child processes that
driver manager starts. Each driver is a dynamic library stored in either bootfs
or a package, and when a driver is to be run it is dynamically linked into a
driver host and then executed.

The drivers stored in packages aren't available when driver manager starts, as
those are stored on disk and drivers must be running before block devices for
filesystems can appear. Before the filesystems are loaded, only drivers in the
Zircon Boot Image (ZBI) can be loaded and run. The Driver Index is a component
that knows where all of the drivers live in the system. The Driver Index will
let Driver Manager know when base packages have finished loading and it has
found base drivers.

#### fshost

Fshost is a component responsible for finding block devices, starting
filesystem processes to service these block devices, and
[providing handles](https://cs.opensource.google/fuchsia/fuchsia/+/main:/src/storage/fshost/meta/base_fshost.cml?l=73&drc=fe4110848aaad498a65278ac05d65fd8201f5ca2) for these filesystems to the rest of
Fuchsia. To accomplish this, fshost attempts to access the /dev handle in its
namespace. This capability is
[provided by driver manager](https://cs.opensource.google/fuchsia/fuchsia/+/main:/src/devices/bin/driver_manager/meta/driver-manager-base.shard.cml?l=83&drc=2deafe53a4a1626b5be2263c13e3dd57024be7db).

As fshost finds block devices, it
[reads headers from each device](https://cs.opensource.google/fuchsia/fuchsia/+/main:/src/storage/lib/fs_management/cpp/format.cc?l=60-61&drc=de246ad54cb9d6aab36ab29b48fdae69820c814e) to detect the filesystem
type. It will initially find the


[](https://fuchsia.dev/docs/glossary#fuchsia-volume-manager)


(fvm) block, which
points to partitions for other block devices. Fshost will
use devfs to cause driver manager to run the fvm driver for this block device,
which causes other block devices to appear for fshost to inspect. It does a
similar thing when it discovers a [zxcrypt](https://fuchsia.dev/docs/concepts/filesystems/zxcrypt) partition, as the disk will
need to be decrypted to be usable. Once fvm and zxcrypt are loaded, fshost will
find the appropriate block devices and start the [minfs](https://fuchsia.dev/docs/concepts/filesystems/minfs) and
[blobfs](https://fuchsia.dev/docs/concepts/filesystems/blobfs) filesystems, which are needed for a fully functioning system.

### Startup sequence

Component manager generally starts components lazily on-demand in response to
something accessing a capability provided by the component. Components may also
be marked as "eager", which causes the component to start at the same point its
parent starts.

Once running, fshost attempts to access the `/dev` handle from driver manager,
which causes driver manager to start. Together they bring up drivers and
filesystems, eventually culminating in pkgfs running. At this point fshost
starts responding to requests on the `/pkgfs` handle, and component manager
proceeds to start the rest of userspace.

TODO(https://fxbug.dev/42053321): This diagram is no longer accurate as of
https://cs.opensource.google/fuchsia/fuchsia/+/124f955ae0d1db1c7e991684c7e8a9b4528d6806.

![A sequence diagram showing the startup sequence between fshost and driver
manager.](https://fuchsia.dev/static/fuchsia-src/concepts/process/images/boot-sequence-diagram.png)

## Boot complete

At this point, the system is ready to launch additional components through FIDL
protocols and services, or by directly launching them with services provided by
component_manager.
[](https://issues.fuchsia.dev/issues/new?component=1439230&template=1881640&description=Issue+on:+https://fuchsia.dev/docs/concepts/process/everything_between_power_on_and_your_component.md "Report a bug or suggest improvements on this page") [](https://cs.opensource.google/fuchsia/fuchsia/+/main:docs/concepts/process/everything_between_power_on_and_your_component.md "View the source code of this page") [](https://ci.android.com/edit?repo=fuchsia/fuchsia/main&file=docs/concepts/process/everything_between_power_on_and_your_component.md&cloneRepo=fuchsia/fuchsia:refs/heads/main&fullPath=fuchsia/docs/concepts/process/everything_between_power_on_and_your_component.md "Edit the source code of this page")