3 ms·
Ask HN: How does a computer read the OS from disk when booting up?
Whenever I read instructions like 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 past the boot sector ever read?
- akkartik 10y ago(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 10y agoThe 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_Interface https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_In...
- akkartik 10y agoMany thanks for the pointers! You're my favorite comment for the day (https://news.ycombinator.com/favorites?id=akkartik&comments=t https://news.ycombinator.com/favorites?id=akkartik&comments=...)