Booting: Difference between revisions

From SprezzOSWiki
No edit summary
No edit summary
 
Line 13: Line 13:
* [http://www.pixelbeat.org/docs/disk/ Details of GRUB on the PC] by Pádraig Brady
* [http://www.pixelbeat.org/docs/disk/ Details of GRUB on the PC] by Pádraig Brady
* [http://duartes.org/gustavo/blog/post/how-computers-boot-up How Computers Boot Up] on Gustavo Duarte's blog
* [http://duartes.org/gustavo/blog/post/how-computers-boot-up How Computers Boot Up] on Gustavo Duarte's blog
 
{{Handbook}}
[[CATEGORY: SprezzOS Manual]]
[[CATEGORY: SprezzOS Manual]]

Latest revision as of 20:42, 5 February 2013

Firmware

BIOS

UEFI

Kernel

Disks

The kernel discovers block objects, and assigns them names based on the order of discovery. This order is dependent on disk timing, module loading order (or even linking order in the case of drivers built into the kernel). If an initramfs has not been provided, it is necessary to provide a root= option on the kernel command line identifying the boot device (and possibly partition). The root= option can take either a kernel device name, a label, or a UUID. Use of a label or UUID is recommended due to the unpredictable nature of kernel device naming. The label and UUID are properties of the target filesystem, not block device. GPT partition names, GPT partition UUIDs, and disk WWNs are not valid parameters. The syntax is that described in the manual page for findfs(8).

If the kernel cannot immediately mount its root filesystem, it will panic, bringing the machine to a halt. This is true even if not all devices have yet been "detected". The rootdelay parameter to the kernel can work around this bug to support root filesystems on e.g. USB devices or bad SATA connections.

systemd

Once the kernel has completed initialization (possibly requiring a trip through an initramfs) and mounted the root filesystem, it births /sbin/init into userspace. /sbin/init, by virtue of having PID 1, becomes the superprocess. When a process exits, any children that exist are reparented by the superprocess. The superprocess is the ultimate parent of all other processes, including system daemons, which the superprocess is typically responsible for launching and restarting as needed. The kernel panics if the superprocess terminates.

See Also

{{#switch:|subgroup|child=|none=|#default=

}}{{#ifeq:|Template|{{#ifeq:|child||{{#ifeq:|subgroup||{{#switch:booting

|doc
|sandbox
|testcases =
|#default = {{#switch:
 |plainlist
 |hlist
 |hlist hnum
 |hlist vcard
 |vcard hlist = 
 |#default = hlist
 }}
}}

}}}}}}