问题描述
根据维基百科条目，引导加载程序是存储在ROM(主存储器(RAM)的一部分，不是它的一部分)中的小程序，它只能被读取而不能被擦除。我在这里有点困惑。这是否意味着我们购买的每个RAM都默认安装了引导加载程序？而且，我从一本书中读到，该书说硬盘上通常有一个名为MBR(主引导记录)的区域，其中包括引导加载程序……
那么这个引导程序到底在哪里？不同的操作系统是否将其引导加载程序存储在不同的位置？
最佳解决办法
ROM是RAM的独立芯片。它不需要电源来保留其内容，并且最初不能通过任何方式进行修改，而是来自工厂的硬连线。后来的PROM或可编程只读存储器取代了真正的ROM。这些芯片在出厂时都是空白的，并且可以使用特殊的程序写入一次，该程序基本上烧掉了芯片的位，导致其状态发生变化。然后将其替换为EPROM或Eraseable可编程存储器。这些芯片上有一个小窗口，如果你将紫外线照射到它们中，可以擦除它们，让它们再次被编程。然后用EEPROM或电可擦除可编程存储器替换它们。这些芯片有一个特殊的软件程序来擦除它们，以便它们可以重新编程。 ROM通常仍然用于统称所有这些类型。
主板有一些固定固件的ROM芯片，用PC称之为通常称为BIOS或基本输入输出系统，虽然现在用EFI固件替换它。这是CPU在开机时首先开始执行的软件。所有固件都执行硬件初始化，通常提供一些诊断输出，并为用户提供配置硬件的方法，然后定位并加载引导加载程序，引导加载程序又定位并加载OS。
使用PC BIOS，它只需加载并执行它决定从其启动的磁盘上的第一个扇区，这通常是检测到的第一个硬盘。按照惯例，硬盘的第一个扇区(称为主引导记录)包含一个DOS分区表，列出磁盘上分区的位置，并为引导加载程序留出一些空间。 Ubuntu使用GRUB引导加载程序，它在MBR中放置足够的代码来加载和执行/boot/grub/core.img。通常，此文件的副本放置在MBR之后的扇区中，但在第一个分区之前，这实际上是MBR加载的内容，因为找到/boot/grub/core.img的位置太难以在非常有限的空间中正确执行MBR。
grub核心映像包含基本grub代码，以及访问/boot/grub以便可以在其中加载其他模块所需的任何模块，以及描述可以引导哪些操作系统以及可以在哪里找到它们的grub配置文件。
英特尔Mac上使用的EFI固件可用作最新PC主板上BIOS的替代品，需要一个专用分区来保存引导加载程序文件，并且固件足够智能，可以找到这些文件并加载一个而不仅仅是加载和执行任何文件位于磁盘的第一个扇区。
次佳解决办法
ROM不在主存储器中：
ROM不是主存储器的一部分。它是一个独立的芯片，大部分时间都是内置中较大的IC。更多示例，您的PC可以包含多个ROM。这些都是在你的主板上建造的。
一般：
-
ROM的内存大小非常小。这些存储器是non-volatile，从某种意义上说，存储在ROM中的程序在电源关闭时不会被擦除。
-
ROM用于存储永久性程序，这些程序对于正确执行的硬件非常重要。
-
ROM的典型示例是BIOS芯片。存储极低级别引导和初始化硬件的程序
你提到过，你读过一篇文章，作者说，“ROM是主存的一部分”。这很令人困惑，因为通常Main Memory指的是易失性类型的存储器，例如RAM。但是，如果您对PC的整个存储空间使用主存储器术语，则ROM是该存储器空间的一部分。您应该注意，通常主内存将类型的内存排除为ROM。
Bootloader存储在哪里：
现代系统使用两级引导加载。在第一步中，从硬盘的扇区(更常称为boot-sector)加载一个小程序。这个小程序反过来从磁盘中的某些位置加载一个程序，称为bootloader。最后，bootloader加载操作系统。
在Ubuntu系统方面，过程如下：
-
打开PC后，BIOS(存储在ROM中)会自动运行并初始化PC硬件的各个部分。然后它检查定义的第一个Boot设备(通常是硬盘)中的特定扇区。该扇区是boot-sector，大小为512字节。
-
boot-sector中的程序加载到内存中(第1阶段)。这个小程序有一些信息，它应该将程序加载到内存中，以及该程序在磁盘或引导设备中的位置。它加载该程序。在Ubuntu中，它是
/boot/grub/core.img。 -
在第二阶段，OS-Loader，GRUB通过将内核和初始ram磁盘加载到内存并将hands-over控制加载到内核来加载Ubuntu。然后内核运行并加载所有必要的程序，如显示管理器，Gui等。
因此，我们可以清楚地说，引导加载程序既不存储在ROM中，也不存储在RAM中，它实际上存储在硬盘(或其他引导设备，如可引导CDROM，USB驱动器等)上，正好说是第一个扇区。硬盘，大小为512字节，通常称为boot-sector。这个引导加载程序加载OS-loader(在Ubuntu中，它是grub)，它也驻留在硬盘(即/boot/grub/文件夹)中，它的任务是加载操作系统(例如，Ubuntu)。
作为测试，删除硬盘(和所有其他启动设备)并尝试启动。您可以进入BIOS步骤，但在该步骤之后，您无法启动任何内容。很可能BIOS会说“找不到引导设备”或“找不到操作系统”或类似的东西。
希望这个答案会有所帮助。
有关更多信息，您可能需要访问以下链接：
第三种解决办法
兼容x86的处理器始终以so-called “real”模式启动，这是一种16位模式，可用1兆字节的可寻址内存。从该地址空间，640K可用于程序，并且上面的地址映射到不同的设备。
例如，从0xA000：0x0000开始的地址被映射到视频RAM，因此，在那里写入数据实际上会将数据写入视频适配器的内存，在屏幕上显示像素。
类似地，BIOS ROM从0xF000：0000开始，因此CPU在上电时，从该pre-defined地址开始逐个开始执行指令。 BIOS ROM包含初始程序，该程序通过执行“power-on自检”或POST开始。来自维基百科：
The BIOS software is built into the PC, and is the first code run by a PC when powered on (‘boot firmware’). When the PC starts up, the first job for the BIOS is the power-on self-test, which initializes and identifies system devices such as the CPU, RAM, video display card, keyboard and mouse, hard disk drive, optical disc drive and other hardware. The BIOS then locates boot loader software held on a peripheral device (designated as a ‘boot device’), such as a hard disk or a CD/DVD, and loads and executes that software, giving it control of the PC.2 This process is known as booting, or booting up, which is short for bootstrapping.
BIOS固件负责将第一个扇区从磁盘读入内存并将控制传递给一个小程序，该程序再次位于那里的特定地址。然后，MBR引导加载程序可以直接开始加载OS(如MS-DOS的情况)或加载”second stage”，这不仅限于单个磁盘扇区的范围。
使用multi-stage方法的引导加载程序可能非常复杂，文本或图形界面允许用户选择从哪个磁盘或分区加载操作系统。
因此，如果像Uri建议的那样，您对Windows引导加载程序和GRUB是否可以共存存在感兴趣，答案是：实际的MBR只能包含一个first-stage引导加载程序(来吧，整个扇区只有512字节)，但是引导加载程序的第二阶段可能能够从不同的分区”chain-load”操作系统。 Windows引导加载程序只能识别和加载Windows，而GRUB能够加载Linux或将控制权传递给存储在其中一个分区的volume boot record中的另一个引导加载程序，从而允许启动Windows或其他操作系统。后一过程称为chain-loading。
当你在装有Windows的计算机上安装Ubuntu时，GRUB将被安装到MBR中，你将能够启动Ubuntu和Windows。
但是，如果在Ubuntu之后安装了Windows，则GRUB将替换为Windows bootloader，您需要re-install GRUB才能再次启动Ubuntu。
第四种办法
您对ROM中的引导加载程序与MBR中的引导程序之间的冲突可能是由于引导加载程序被用于任何代码，这些代码可以解决如何在代码中加载最小值以使计算机执行某些有用的操作，包括每个在multi-stage启动状态。
因此，起始状态是拥有一台计算机，它是一个可编程设备，但不知道如何加载软件来运行，因为它没有加载任何软件。 (因此从它自己的引导启动)。
从历史上看，这个问题有几种不同的解决方案，但是现在我们从ROM中的一些代码(很可能是严格的EEPROM)开始，这足以使它看到不同的设备并依次尝试它们，直到它找到一个引导。
(这就是为什么许多系统会启动CD或DVD，如果您将操作系统安装程序磁盘放入hard-drive中，否则，BIOS [ROM上的代码，包括我们正在谈论的代码和其他一些low-level的东西设置为首先查看CD /DVD驱动器，然后设置为hard-drive，如果没有找到任何内容，推文通常会将其设置为忽略CD /DVD驱动器，除非手动请求，因此不会浪费时间旋转放在驱动器中的non-bootable磁盘)。
ROM中的此代码有时称为引导加载程序。
当它知道要查看什么驱动器时，它将查看MBR，其中包含有关主要部分的信息 – 如果您甚至没有，您如何在以后查看/或/boot或C：/(在Windows系统上)知道磁盘的哪个部分是哪个分区，不记得每个分区是如何安装的？ – 以及一些带有进一步执行指令的代码。 (顺便说一下，这解释了为什么某些操作系统 – 比如Windows – 只能安装在主分区上，这些分区的详细信息都在MBR中，而这是他们的引导加载程序读取的唯一分区信息，并且它不会将EBR加载到了解逻辑分区，只要它关注那些分区甚至还不存在)。
该可执行代码也称为引导加载程序。当我们想要区分它和接下来的内容时，它被称为主引导加载程序(因为除非我们制作自己的BIOS，否则我们忽略了ROM位，因为我们无法控制)。
该代码将非常小，因为它只能容纳大约400个字节，因此为了做任何真实的事情，它将加载更多的代码，这可能更大，因为它不必处理这个约束。
此代码也称为引导加载程序。当我们想要区分它和之前的内容时，它被称为辅助引导加载程序。
该代码可能是该过程的最后阶段。如果您只有一个操作系统，或者您的系统上的所有操作系统都使用兼容的boot-loaders(例如两个使用GRUB的Linux安装，那么无论哪个GRUB最后都可以提供引导到其中任何一个)，那么它会显示菜单(如果需要)在内核中加载，并将控制权交给操作系统。
如果您的操作系统与该引导加载程序不兼容，则可能会进行链式加载。例如。如果您在同一台机器上安装了Windows和Linux，那么用于加载Windows的GRUB选项实际上会加载另一个只知道Windows安装的引导加载程序，并将其传递给它。虽然这是该过程中的第三阶段，但它仍然被称为辅助引导加载程序，因为它既不知道也不关心在它之前运行另一个辅助引导加载程序。对于使用不同类型的辅助引导加载程序的Linux安装，情况也是如此。
大多数情况下，当我们谈论Linux的引导加载程序时，我们通常不是指ROM代码(它不是Linux的一部分，或者通过安装Linux而改变)。当我们进行update-grub时，我们正在更改辅助引导加载程序，它通常位于特定安装的/boot中。当我们进行install-grub时，我们正在更改它以及MBR中的主要引导加载程序，以便它有足够的代码来知道/boot的位置(可能会启动软件RAID)，并且当它本身就是加载和执行时执行。
所以，总而言之，当你说ROM是主内存*的一部分时，你是不正确的，因为它是独立的。 (实际上，RAM被视为ROM的反义词)。你说那里有一个bootloader和MBR都是正确的，因为它们是这个过程的两个步骤，有时候它们都被这个名称所调用。答案是“不同的操作系统将他们的引导程序存储在不同的地方吗？”是”mostly”，因为如果你不兼容的辅助引导加载程序将隐藏其他引导加载程序(如果你在安装Linux后安装Windows)或链接到另一个如果请求(如果你修复了这种情况，或者在Windows之后安装Linux)，但操作系统可以共享如果它们是兼容的辅助引导加载程序(如果你在另一个使用相同类型的辅助引导加载程序的Linux之后安装Linux，它可以看到其他Linux [有时软件RAID会混淆事情并使链式加载成为必要)。
*在以编程方式使用ROM和RAM的日子里，这是不同的。例如，在ZX Spectrum上，ROM将是16kiB并包含一个BASIC解释器，以及为您提供将其加载到其48kiB或128KiB(分页)或RAM中的起点(在这种情况下，它基本上是启动到那个BASIC解释器，然后使用它来启动磁带上的内容)，BASIC解释器中有一大堆函数可以使用RAM中的程序(为什么当计算机已经有一个已知位置时写一个trig函数？特别是当您只有48kiB用于运行所有自己的代码时)。这个ROM也以与RAM相同的方式可见，只是在不同的地址。在这种情况下，ROM与RAM一样是主存储器的一部分，但不可写。现在，一旦你超过了第一个启动阶段，你就会忽略ROM。