
Ask HN: How does a computer read the OS from disk when booting up? - akkartik
Whenever I read instructions like http:&#x2F;&#x2F;os.phil-opp.com&#x2F;multiboot-kernel.html to load a minimal OS from scratch, I wonder how a computer finds the code for the OS to run. The OS resides on a file in the file system (&#x2F;vmlinuz, or kernel.bin in the above link), and the file system is an OS construct requiring device drivers for hard disk, SSD, CDROM or USB depending on what the BIOS is configured for and a bunch of other things. Surely there&#x27;s no way all those drivers fit in the boot sector of a drive? How is anything else past the boot sector ever read?
======
akkartik
(Reproducing OP text to linkify links.)

Whenever I read instructions like [http://os.phil-opp.com/multiboot-
kernel.html](http://os.phil-opp.com/multiboot-kernel.html) to load a minimal
OS from scratch, I wonder how a computer finds the code for the OS to run. The
OS resides on a file in the file system (/vmlinuz, or kernel.bin in the above
link), and the file system is an OS construct requiring device drivers for
hard disk, SSD, CDROM or USB depending on what the BIOS is configured for and
a bunch of other things. Surely there's no way all those drivers fit in the
boot sector of a drive? How is anything else ever read?

~~~
schoen
The BIOS traditionally has some kind of drivers for devices that are built
into the system (in the PC architecture, add-on devices can extend the BIOS,
so for example if you had a SCSI card, it would get a chance to have its own
onboard ROM, which could be mapped into the system address space and also run
initialization code during the system startup; that ROM could provide a basic
SCSI driver that would allow you to boot from SCSI-attached storage devices).

[https://en.wikipedia.org/wiki/Option_ROM](https://en.wikipedia.org/wiki/Option_ROM)

For a post-DOS operating system, the main role of the option ROM is providing
functionality, in the form of BIOS extensions, that allows the device
supported by the option ROM to be used during the boot process. Then the
operating system will need to have its own protected-mode drivers to use that
hardware post-boot.

In the Linux world you often see multi-stage bootloaders, where you have a
boot sector that knows how to load the next stage, which then knows how to
load the next stage. Each stage can have more knowledge about things like
filesystems than the previous stage. For some systems, you may indicate the
absolute offset on a disk from which a file should be loaded (so that you can
load it without knowing about the filesystem, assuming that it's stored
contiguously). For example, LILO had a table of hardcoded disk offsets for
images to boot, so if you moved where a kernel was physically stored, you were
supposed to re-run the bootloader installer.

I was once familiar with how this worked on BIOS but I'm not familiar with the
changes that UEFI has brought in. It might be useful to read

[https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_In...](https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface)

~~~
akkartik
Many thanks for the pointers! You're my favorite comment for the day
([https://news.ycombinator.com/favorites?id=akkartik&comments=...](https://news.ycombinator.com/favorites?id=akkartik&comments=t))

