从grub>提示符手工引导Ubuntu：完整排查与修复指南

开机画面一闪而过后，屏幕中央停留着一个孤零零的提示符：

code复制grub>

第一次遇到的人多数会懵，以为系统损坏、数据全丢、必须重装。我见过不少用户在这个界面下直接放弃，格式化重来。实际上，grub提示符是引导器在“找不着北”的时候留给你的一个交互式救援入口，只要你还知道几条命令，就有机会把系统完整地带起来，甚至几分钟后就能把这个故障彻底修掉。

这篇文章就围绕“Booting Ubuntu from grub prompt”来写。我会从grub为什么要走到提示符这一步讲起，再给出可照抄的排查和手工引导链路，最后补充LVM、加密盘、USB键盘失灵这些边界情况，以及我处理过的几个真实案例。内容覆盖从新手到进阶排障的全部过程，适合任何正在grub提示符前卡住的Ubuntu用户。

1. 机器停在grub>却不继续引导：先搞清楚你处在引导流程的哪一环

grub>这个提示符看起来像是一个错误界面，但从系统引导的视角看，它更像是一个“降级控制台”。grub引导器本身成功加载了，只是它没有继续走正常的流程——读取/boot/grub/grub.cfg菜单配置文件——于是主动把命令行交到了你手里。

1.1 grub引导过程的两个阶段

要理解这个问题，必须知道grub的加载过程并不是一步到位的，它可以粗略分成两个阶段：

• 第一阶段引导代码：BIOS环境下写在磁盘主引导记录里（前446字节），UEFI环境下是EFI系统分区里的grubx64.efi文件。这个阶段做的事情非常有限，就是找到并加载grub的核心映像core.img。
• 第二阶段核心映像：core.img里面包含了文件系统驱动、分区表解析、设备管理这些模块。正常流程下，它加载完之后会去读/boot/grub/grub.cfg，把菜单渲染出来。

你现在看到grub>，说明第一阶段和第二阶段的衔接是成功的，core.img已经跑起来了，但它在找grub.cfg这一步上出了问题。所以系统并没有“完全坏掉”，只是缺少了“自动引导”的配置依据。这也正是我们能够手动输入命令救系统的根本原因——grub的核心模块都在，只是没人告诉它接下来怎么走。

1.2 是什么诱发了grub提示符

根据我这些年见过的故障现场，掉进grub提示符的诱因大致集中在下面几类：

这些原因看着各不相同，但本质只有一个：grub在启动时找不到它期望的配置文件，或者设备路径对不上。所以排查思路也很统一——先手动告诉它“根分区在哪里、内核文件在哪里”，把它引导起来，再回到系统内部把配置彻底修复。

2. 在grub命令行下“看见”磁盘：通过ls命令摸清现有分区布局

grub有自己的设备命名规则，和Linux系统内的设备名完全不同。很多人在这里犯了第一个错误——凭记忆输入(hd0,0)之类的老式写法，结果一路报错。

2.1 grub的磁盘与分区命名规则

grub里的磁盘命名和分区命名遵循一套固定格式，理解之后就不容易混：

• 物理磁盘从0开始编号，第一块硬盘是hd0，第二块是hd1。
• 分区从1开始编号。GPT分区表用gpt标识，MBR分区表用msdos标识。

举例来说，正常情况下Grub提示符下常见的分区看起来像这样：

code复制(hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3) (hd1) (hd1,msdos1)

这串字符的含义是：第一块硬盘有3个GPT分区，第二块硬盘有1个MBR分区。Linux系统里对应的设备名可能是/dev/sda1、/dev/sda2、/dev/sda3和/dev/sdb1，二者指代的是同一物理对象，但语法不能混用。

2.2 先用ls看全貌，再逐个分区验证身份

进入grub>之后，第一条命令必须是：

code复制ls

这个命令会列出grub当前能够识别到的所有磁盘和分区。如果输出结果里面什么都没有，说明grub的磁盘驱动没有工作——常见于比较老的grub版本配合新硬件，或者主板SATA模式设置异常。先解决驱动识别问题，后面的命令才有意义。

接下来，你要逐个查看分区的根目录内容，判断它的角色：

code复制ls (hd0,gpt1)/

输出结果的判断逻辑如下表：

| 分区目录内容 | 分区角色 |
| --- |