我仅用于数据存储的硬盘在过去的Ubuntu安装中仍然具有GRUB。

如何在不损坏驱动器其余数据的情况下从中删除GRUB？

背景

我有时会在具有各种引导顺序配置的计算机之间移动数据驱动器，因此我希望它是不可引导的，以避免必须将其容纳在每台计算机的BIOS设置中。

在仅连接数据驱动器的情况下打开计算机电源时，将显示以下内容：

error: no such device: fdf38dd4-9e9d-479d-b830-2a6989958503.
grub rescue> 

我可以从旧备份中/etc/fstab确认这是我最近重新格式化且不再存在的根分区的UUID 。这是数据驱动器的分区表和原始主引导记录。

请注意，我对不能解决我的主要问题的解决方法不感兴趣。我可以想到几种解决此问题的方法，但是在我不知道如何直接解决该问题的原则上，这使我感到困扰。每个安装过程都应具有相应的卸载过程。

您只需将磁盘的前几个字节设为0x00，就可以使设备无法启动。

通常（对于grub，grub2和ntldr iirc都是如此），驱动器的第一个字节将是x86 jmp指令。这甚至发生在disklabel之前，因为将执行传递给设备进行引导时，它只是将CPU设置为将设备信息作为代码吸收。如果代码无效，它将触发中断，BIOS处理该异常并转到下一个可引导设备。

例如，磁盘的开头以：

00000000  eb 63 90 d0 bc 00 7c fb  50 07 50 1f fc be 1b 7c  |.c....|.P.P....||

第一部分是eb 63跳转到当前IP的偏移量0x63（因此偏移到0x65）。

00000060  00 00 00 00 ff fa 90 90  f6 c2 80 74 05 f6 c2 70  |...........t...p|
00000070  74 02 b2 80 ea 79 7c 00  00 31 c0 8e d8 8e d0 bc  |t....y|..1......|

从这里继续执行。

该部门的末端如下所示：

000001b0  cd 10 ac 3c 00 75 f4 c3  ed db 96 d6 00 00 80 01  |...<.u..........|
000001c0  01 00 83 fe ff ff 3f 00  00 00 c1 07 a6 0e 00 fe  |......?.........|
000001d0  ff ff 83 fe ff ff 00 60  00 11 00 00 38 29 00 fe  |.......`....8)..|
000001e0  ff ff 82 fe ff ff 00 08  a6 0e 00 58 5a 02 00 00  |...........XZ...|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|

如果将磁盘格式化为MBR分区表，则只需要显示两件事：位于偏移处的分区表0x1be和55aa位于扇区末尾处偏移处的MBR签名0x1fe。 0x1be是十进制446。

以下内容（当然）会使设备无法启动。但这就是您想要的。如果您不想使设备无法启动，那么不要这样做，mmm-kay？我假设您的设备是/dev/sdz，仅仅是因为没有多少人拥有/dev/sdz，这降低了一些白痴新手盲目的复制粘贴命令的风险。

首先，将MBR复制到文件以进行备份。

sudo dd if=/dev/sdz of=/some/where/safe/preferably/not/on/dev/sdz/backup.mbr bs=512 count=1

接下来，制作该文件的副本：

cp backup.mbr backup.mbr.test

接下来，我们必须创建一个回送设备（这样内容就不会被截断。）并将更改应用于伪扇区0作为测试：

sudo losetup /dev/loop7 backup.mbr.test
sudo dd if=/dev/zero of=/dev/loop7 bs=446 count=1
sudo losetup -d /dev/loop7

hexdump 文件，并确保整个分区表是完整的：

sudo hexdump -C backup.mbr.test

您应该看到类似以下内容：

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 80 01  |................|
000001c0  01 00 83 fe ff ff 3f 00  00 00 c1 07 a6 0e 00 fe  |......?.........|
000001d0  ff ff 83 fe ff ff 00 60  00 11 00 00 38 29 00 fe  |.......`....8)..|
000001e0  ff ff 82 fe ff ff 00 08  a6 0e 00 58 5a 02 00 00  |...........XZ...|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200

现在，在十六进制转储的输出上0x1be可以看到80，这也可以00并且仍然有效。（这是在分区表中的“启动”标志，你可以不要管它，因为它是完全通过最现代的BIOS忽略...）字节的0x1bf，虽然几乎从来没有被0x00（这是最常见的0x01，但它可以采取其他值），您可以将其与您backup.mbr进行比较，以确保过去的一切都没有0x1be改变。

一旦对正确应用更改感到满意，则可以直接将文件复制到磁盘的第一部分。之所以要执行该文件而不是/dev/zero再次执行该文件，是为了防止错别字。如果您不小心忽略了count=1自己的工作时间，那么复制文件永远不会超过EOF。这样更安全。

sudo dd if=backup.mbr.test of=/dev/sdz

接下来hexdump，确保磁盘更改符合预期。

hexdump -C /dev/sdz | head

最多可比较0x200对backup.mbr.test，以确保它就是你想要的。

最后，如果由于某种原因导致任何问题，您可以通过以下方式简单地将MBR的备份复制回驱动器：

sudo dd if=backup.mbr of=/dev/sdz

希望这可以帮助。

警告：极度危险

您可以从Linux本身使用dd命令（它会删除分区表）：

 # dd if=/dev/null of=/dev/sdX bs=512 count=1

只需删除MBR，而无需分区表（请参见下面的注释）：

# dd if=/dev/null of=/dev/sdX bs=446 count=1

替换/dev/hdX为您的实际设备名称，例如/dev/hda。使用fdisk -l命令找出设备名称：

# fdisk -l

资源

1. http://www.cyberciti.biz/faq/linux-how-to-uninstall-grub/

我的经验

sudo install-mbr -i n -p D -t 0 /dev/sda

是，它成功地从中卸载了grub2 /dev/sda（安装了Windows 7），因此问题的第一部分“如何从/ dev / sda中删除grub？” 已回答。

但是，问题的第二部分是“如何还原/ dev / sda的MBR？” 由于install-mbr命令无法还原MBR，因此尚未得到答复。结果，Windows不再启动，并且Windows启动管理器报告有关损坏的MBR的错误，并要求用户使用Windows修复CD进行修复。

阅读有关该主题的Wikipedia文章后，我想提出一些其他解决方案：

1. 更改BIOS中的启动顺序:)

2. 最好和最安全的方法：用于fdisk从该驱动器上的所有分区中删除“ bootable”标志。大多数MBR都在寻找“可引导”分区以进行链式加载，因此，如果没有这样的分区，我希望GRUB不会做任何事情。还没有测试。

   如果上述方法没有帮助，请尝试安装标准MBR代码的免费克隆：

3. 安装mbr软件包并使用如下install-mbr命令：

   sudo apt-get install mbr
   sudo install-mbr -i n -p D -t 0 /dev/sda
   

鸣谢：如何：使用Ubuntu LIVE CD恢复Windows MBR

通过阅读Wikipedia文章，我有一个印象，唯一可以识别MBR的是其签名，该签名位于扇区的末尾（字节510和511）。MBR的前446个字节应该包含机器指令。只要存在MBR签名，BIOS就会将控制权转移到引导加载程序，而不管前446个字节的实际内容如何：

在与IBM PC兼容的计算机上，ROM BIOS中包含的引导固件将加载并执行主引导记录。[14] ...因此，MBR的开头应包含实模式机器语言指令。[14] BIOS将MBR从存储设备读取到物理内存中，然后将微处理器引导到启动代码的开头。

由于MBR的代码部分的大小受限制，因此它通常仅包含一个小程序，该程序会将其他代码（例如引导加载程序）从存储设备复制到内存中。然后将控制权传递给该代码，该代码负责加载实际的操作系统。

...

BIOS中的引导程序序列会将它找到的第一个有效MBR加载到地址为0x7C00的计算机物理内存中。BIOS代码中执行的最后一条指令将是对该地址的“跳转”，以将执行定向到MBR副本的开头。大多数BIOS的主要验证是最后使用0xAA55签名，尽管BIOS实施者可以选择包括其他检查，例如验证MBR包含有效的分区表，而没有条目引用超出报告的磁盘容量的扇区。

因此，我的理解是MBR 总是应该包含一个引导加载程序，并且将其前446个字节清零不会阻止BIOS尝试从磁盘引导-但在尝试执行无效代码时，它可能会使计算机挂起。

更新：另外，本文建议使磁盘在BIOS中看起来“不可启动”，您实际上应该在扇区的和处编辑MBR签名（使用任何磁盘编辑器）。我不确定这是否会影响OS在磁盘上看到分区表...但是至少您可以随时修改这些字节...

另一个更简单的解决方案。

就我而言，我有Debian linux，但想使用Mandriva，也可以为其他人使用

关闭您的电脑，然后删除您不想引导的启动磁盘（具有grub）

只需放入由mandriva iso或您要安装的其他变体制成的可启动USB，就有一些工具可以使iso文件中的可启动USB记忆棒使用google（或者您可以从cd rom中下载刻录的安装程序）

现在，大多数linux安装程序为您提供了一种选择，可以尝试，播放/用于评估或便携式linux，或者运行安装程序进行安装。在这一点上，我们只是等待（将光标向下移动，以便屏幕将等待，但不要按Enter或用鼠标单击）。

请注意，此时USB /或CDRom已启动并正在运行。现在是时候插回我们暂时删除的硬盘了，请稍等片刻（某些BIOS确实需要稍等片刻，这样就足够了）

由于大多数安装程序都包含分区工具，因此可以继续进行设置过程，您可以执行任何所需的操作。嗯，这是一个简单的解决方案，我只是作为一个初学者就摆脱了旧的linux设置

这是一个老问题，但是昨天发生在我身上的是，我是这样解决的：我关闭了计算机，物理上断开了连接的硬盘，再次启动计算机，然后

~ $ sudo update-grub

完成此操作后，我关闭了计算机，重新连接了硬盘驱动器，并且原来的Windows 7分区（自2年前就不存在了）最终没有出现。

我了解这是脚踏实地的解决方案，但它确实有效。有一天，我将完全擦除该硬盘驱动器，而GRUB的所有剩余痕迹都将消失。