Where is bootstrap loader present physically

Every hard disk has an MBR, and it contains several important pieces of information. First and foremost, the MBR contains something called the partition table, which is an index of up to four partitions that exist on the same disk, a table of contents, if you will. How small? Well, to put things in context, bytes is only 0. Given how tiny the bootstrap code section of the MBR is, the only useful purpose it can really serve is to look up another file from the disk and load it to perform the actual boot process.

On a correctly-created MBR disk, only one partition can be marked as active at a time. So the job of the bootstrap code segment in the MBR is pretty simple: look up the active partition from the partition table, and load that code into the memory for execution by the CPU as the next link in the boot chain. However, for legacy compatibility reasons, the MBR almost always loads the first sector of the active partition, meaning another only bytes.

On a disk that contains valid bootstrap code, the last two bytes of the MBR should always be 0x55 0xAA. For example, if the first boot device in the BIOS is set as the USB stick and the second is the local hard disk, if a USB stick without the correct boot signature is plugged in, the BIOS will skip it and move on to attempt to load from the local disk.

As covered above, the bootstrap code in the MBR will usually load a sequence of bytes from the start of the active partition. The exact layout of a partition depends what filesystem the partition has been created or formatted with, but generally looks something like this:.

Again, depending on the OS and filesystem, the exact layout of the partition will certainly differ. On modern filesystems for newer operating systems, the bootstrap code can take advantage of enhanced BIOS functionality to read and execute more than just bytes, but in all cases, the basic steps remain the same:.

Because of how little space is allocated for the bootstrap code in the partition bootsector, the code it contains normally ends with another JMP command instructing the CPU to jump to the next sector in the partition, which is often set aside for the remainder of the partition code. Depending on the filesystem, this can be several sectors in length, or however long it needs to be to fit this stage of the bootloader. The second stage of the bootloader, stored in the partition bootsector in the bootstrap section and, optionally, continuing beyond it, carries out the next step in the bootloader process: it looks up a file stored on the partition itself as a regular file , and tells the CPU to execute its contents to begin the final part of the boot process.

Unlike the previous bootstrap segments of the MBR and the partition bootsector, the next step in the boot process is not stored at a dedicated offset within the partition i.

This significantly more-complicated bootstrap code must actually read the table-of-contents for the filesystem on the partition, 7 The second-stage bootloader from older versions of file systems oftentimes placed complicated restrictions on the bootloader files they needed to load, such as requiring them to appear in the first several kilobytes of the partition or being unable to load non-contiguously allocated files on the partition.

This file is the last piece of the bootloader puzzle, and there are usually no restrictions as to its size or contents, meaning it can be as large and as complicated as it needs to be to load the operating system kernel from the disk and pass on control of the PC to the OS.

The actual bootloader files on the disk form the final parts of the boot loading process. When people talk about bootloaders and boot files, they are often referring to this final, critical step of the boot process. As such, almost all bootloaders separate the actual, executable bootloader from the configuration file or database that contains information about the operating system s to load. As discussed previously, there are many different bootloaders out there. Each operating system has its own bootloader, specifically designed to read its filesystem and locate the kernel that needs to be loaded for the OS to run.

Here are some of the more-popular bootloaders — and their essential configuration files — for some of the common operating systems:. Each of the popular operating systems has its own default bootloader. While a number of different bootloaders have existed for Linux over the years, the two predominant bootloaders were Lilo and GRUB, but now most Linux distributions have coalesced around the all-powerful GRUB2 bootloader.

COM that identifies hardware and generates an index of information about the system. COM can be found in the linked articles in our knowledgebase. Unlike BOOT. GRUB was the predominantly-used bootloader for Linux in the s and early s, designed to load not just Linux, but any operating system implementing the open multiboot specification for its kernel.

As these values could be changed by recompiling GRUB with different options, different Linux distributions had this file located under different names in different directories. GRUB 2 is a powerful, modular bootloader more akin to an operating system than a bootloader. The grub. As previously mentioned, the stage of the boot process is a little more involved than the previous steps, primarily due to the additional complexity of reading the filesystem.

So if, as Uri suggests, you're interested whether the Windows bootloader and GRUB can co exist together, the answer is: the actual MBR can only contain a single first-stage bootloader come on, the whole sector is just bytes , but the second stage of a bootloader may be able to "chain-load" operating systems from different partitions. Windows bootloader is only able to recognize and load Windows, while GRUB is able to load Linux or pass control to another bootloader stored in a volume boot record of one of the partitions, which allows to boot Windows or other OS.

The latter process is called chain-loading. The conflict between what you say about the bootloader being in ROM and it being in the MBR is perhaps due to bootloader being used for any code that works out how to do the minimum to load in code to make the computer do something useful, including each state in a multi-stage boot.

So, the starting state is to have a computer, which is a programmable device, but doesn't know how to load software to run because it doesn't have any software loaded.

And hence boot from pull itself up from its bootstraps. Historically, there were a few different solutions to this problem, but these days we start with some code in ROM mostly likely strictly EEPROM , which is enough to get it to look at different devices and try them in turn until it finds one that's bootable. Incidentally, this explains why some OSes - like Windows - can only be installed on a primary partition, the details of those partitions are in the MBR and that's the only partition information their bootloader has read, and it doesn't load the EBR to learn about the logical partitions, as far as it's concerned those partitions don't even exist yet.

That executable code, is also called a bootloader. When we care to distinguish between this and what comes next, it's called a primary boot loader because unless we're making our own BIOS we ignore the ROM bit as out of our control. That code will be very small as there's only around bytes for it to fit in, so to do anything real, it will load some more code, that can be larger as it doesn't have to deal with this constraint.

This code, is also known as a bootloader. When we care to distinguish between this and what came before, it's called a secondary boot loader. That code could perhaps be the final stage in the process.

It would if you've only one OS, or if all the OSs on your system use compatible boot-loaders e. In the case where you've an OS that isn't compatible with that bootloader, it may chainload. While this was a tertiary stage in the process, it's still called a secondary boot loader , because it neither knows nor cares that there was another secondary boot loader running before it. This would also be the case with a Linux install that used a different type of secondary bootloader.

Mostly when we talk about the bootloader in terms of Linux, we generally don't mean the ROM code it's not part of Linux, or changed by installing Linux. You were correct both in saying there was a bootloader there and in the MBR, because they're two steps of the process and both are sometimes called by that name. And the answer to "Do different OS store their bootloader in different places?

These days you pretty much ignore the ROM once you're past the first stage of booting. Make a minimal working example and run it on an emulator to understand those concepts:. This is a super simple "bootloader" that does a single hlt instruction. When you do this, it becomes clear that the bootloader is something that lives on a permanent storage disk like USBs or hard disks. In days of old, the boot program resided on punched paper tape similar to those used by telegraph machines or punched card media 'don't see both of them around anymore.

Sometimes if a paper tape or card reader was not available one would need to enter the binary IPL code directly into the processor via a console on the front panel. Nowadays the IPL code reside in pROMs which when executed in turn load and execute any secondary boot loaders tailored to load bootup the desired operating system.

The boot loader usually is in the first sector of the hard drive, usually called the Master Boot Record. Ubuntu Community Ask! Sign up to join this community. The best answers are voted up and rise to the top.

Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Learn more. Ask Question. Asked 9 years, 3 months ago. Active 2 years, 11 months ago. Viewed k times. Improve this question. Eliah Kagan k 51 51 gold badges silver badges bronze badges. Add a comment. Active Oldest Votes. Improve this answer. Faheem Mitha 7, 1 1 gold badge 13 13 silver badges 17 17 bronze badges. Here is a paragraph excerpted from Glenn Brookshear's Computer Science, An Overview A small portion of a computer's main memory where the CPU expects to find its initial program is constructed from special nonvolatile memory cells.

Such memory is known as read-only memory ROM According to him. I just want to know whether the so-called bootloader is installed on the ROM part of the main memory Sergey — xczzhh.

It is installed along with the OS. Unless you download and install an update from your motherboard maker, the ROM never changes. SuiciDoga, no, EFI applications which are basically limited to a few firmware upgrade utilities and boot loaders are stored in the EFI system partition of the hard disk.

Show 1 more comment. Generally : ROM are very small in memory size. These memory is non-volatile, in the sense, the program stored in ROM don't get erased with power shut down. ROM are used to store permanent programs, which are very essential your hardware to perform correctly. Where the program of very low level booting and initializing hardware are stored You mentioned that, You read an article where author said, "ROM is a part of Main memory". Where is Bootloader stored: Modern system use two stage boot loading.

Hope this answer will help. The Matt 4 4 silver badges 8 8 bronze badges. Anwar Anwar DavidSchwartz, It's been more than a decade now. Anwar, the link to Main Memory is dead. Sergey Sergey The k is from the segments below A, which are available for the real mode OS and programs to use. Thank you for the answer.