mbr在操作系统之间如何变化？

如何解决mbr在操作系统之间如何变化？

Master Boot Record (MBR)会如何变化？我无法确定是否存在特定于基于Linux的操作系统的MBR，或者每个操作系统是否具有不同的MBR？如何比较操作系统的MBR？而且，如果我用 C 为Ubuntu编写一个代码，那么它也可以用于其他发行版吗？

我想知道MBR是否始终是跨平台的，这意味着它可以在类似Unix的系统和Windows上运行。如果没有，我想知道Windows的MBR和Unix的MBR有什么区别

解决方法

在“理想主义理论”中；对于双启动方案，MBR包含一个“启动管理器”，它可以执行以下操作：确定哪些分区是可启动的，选择一个分区（可能是通过向用户提供一个菜单来选择），然后加载选定分区的第一个扇区（选定操作系统的启动）部门）并将控制权传递给它。在这种情况下，MBR（以及磁盘第一磁道中的其他相关代码）由不属于任何操作系统的第三方实用程序拥有；并且绝不允许任何操作系统触摸/修改MBR（或第一个分区开始之前的任何其他数据）。

但是；在实践中，通常人们只安装一个操作系统，为了方便起见，操作系统安装程序提供了自己的MBR（这样，人们就不必担心安装第三方实用程序）；而且几乎每个操作系统都有讨厌/自负的倾向：“我们只关心自己和/或希望控制您安装的任何其他操作系统”。这导致操作系统忽略常识并相互破坏，和/或为双引导方案（Windows上的GRUB，“ boot.ini”）提供了自己的“反竞争”替代方案。

当制造商/固件开始关注安全性时，这种讨厌的废话（对用户而言）变得更加糟糕。该计划是要“测量”（在启动期间使用的所有代码（包括固件，MBR和操作系统的引导加载程序）（使用内置在TPM芯片中的高级cypto校验），以便操作系统（和其他软件-例如“远程证明”） ”）可以检测到恶意软件是否篡改了操作系统所依赖的任何代码（因为“花哨的校验和”会有所不同）。这意味着，如果您安装第二个操作系统（损坏/修改现有操作系统的MBR），则会更改该“花哨校验和”并破坏原始操作系统的身份，因此，在修复损坏并让原始操作系统重新启动之后，其他东西（取决于“法国校验和”）仍然坏了。

幸运的是； UEFI主要通过扮演“启动管理器”（并完全弃用MBR）的角色来解决此问题，其中（如果安装了多个操作系统）固件使用“ UEFI变量”来确定启动哪个，每个操作系统都可以UEFI系统分区中有其自己的不同引导加载程序，而不会发生冲突。可悲的是，令人讨厌/自负的“我们只关心自己并希望得到控制”的趋势仍然存在，并且操作系统正在尝试寻找破坏所有事物的替代方法（SecureBoot密钥管理，使用GRUB作为垫片，以便不同的操作系统可以抗衡用于控制GRUB的配置等。

主引导记录（MBR）如何更改？

除非安装操作系统，否则MBR不会更改。当您确实安装操作系统时，MBR可能会更改，也可能不会更改，具体取决于操作系统安装程序以及（在某些情况下）您告诉操作系统安装程序的操作。

我不知道是否存在特定于基于Linux的操作系统的MBR，或者每个操作系统是否具有不同的MBR？

Linux（内核）定义了一个“ Linux启动协议”，该协议允许任何人编写兼容的启动加载程序。用于从BIOS引导；共有3种常见的引导加载程序（LILO，GRUB和SYSLINUX）；但是大多数基于Linux的操作系统倾向于GRUB，并且大多数基于Linux的操作系统安装程序都倾向于将GRUB作为“启动管理器加启动加载程序”安装在MBR中。

我想知道MBR是否始终是跨平台的，这意味着它可以在类似Unix的系统和Windows上运行。如果没有，我想知道Windows的MBR和Unix的MBR有什么区别。

不幸的是，否-MBR应该是“操作系统中性/跨平台”（在某些情况下可能是-例如，如果用户不介意在自己的分区中安装LILO或GRUB，并且操作系统安装程序支持该操作），但大多数情况并非如此。如果要编写自己的MBR，则可能需要处理特定操作系统无法与其他操作系统协作的问题。