从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)/

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

这一步没有捷径，只能逐个分区去试。我见过不少人在这个环节偷懒，凭印象就认定根分区是(hd0,gpt2)，结果后面一连串命令全部作废。多花一分钟做验证，能省下后面半小时的排错时间。

2.3 为什么根分区的判断如此关键

手工引导Ubuntu的核心逻辑就一条：告诉grub“根分区在哪”，然后让它加载根分区/boot目录下的内核文件。如果根分区判断错了，哪怕vmlinuz文件明明存在，grub也找不到。这就好比告诉了司机错误的片区，无论小区楼栋号多清晰，他也到不了你要去的楼。

更麻烦的是，在grub>这个阶段，我们没有任何辅助工具，既不能fdisk -l也不能blkid，唯一可用的就是靠眼睛看ls的输出。所以把这一步做扎实，是整个救援流程里最值得花时间的地方。

3. 从grub提示符手工引导Ubuntu：一条可照抄的命令链路

确认了根分区位置之后，引导流程就可以正式开始了。下面这套命令，我这些年反复用过，基本适用于所有常规安装的Ubuntu系统。

3.1 设置root变量

假设你确认根分区是(hd0,gpt2)，首先执行：

code复制set root=(hd0,gpt2)

这条命令的含义是：给grub内部变量root赋值，告诉它后续使用相对路径查找文件时，都从这块分区开始。这里有两个容易出错的地方：

• 不要在set和root之间多加空格，写成set root=是一个完整动作。
• 等号右侧的括号不要省略，也不要加引号。

执行之后，用ls验证一下：

code复制ls $root/

如果能列出/boot、/etc、/usr这些目录，说明root设置正确。如果输出error: unknown filesystem，说明这块分区本身不是Linux文件系统，回到第2节重新排查。

3.2 找到内核文件和initrd映像

接下来查看boot目录内容：

code复制ls $root/boot/

正常情况下，你会看到类似下面的文件名：

code复制vmlinuz-6.8.0-45-generic
initrd.img-6.8.0-45-generic
config-6.8.0-45-generic
System.map-6.8.0-45-generic

如果你的Ubuntu安装时没有单独划分/boot分区，那么内核文件就位于/boot/；如果划分了独立/boot分区，那么文件直接位于该分区的根路径下。这取决于当初安装时的分区方案，所以不要死记路径，一切都以ls输出为准。

选哪一个版本的内核也有讲究。系统里通常保留着多个内核版本，我的建议是：

• 如果只是做一次性救援引导，选版本号最新的稳定内核。
• 如果是怀疑新装的内核有问题导致无法启动，就选旧版本。
• 不要一次加载两个内核，grub不支持，也没必要。

3.3 加载内核与initrd

确认内核文件名之后，执行：

code复制linux /boot/vmlinuz-6.8.0-45-generic root=/dev/sda2 ro

这行命令做了两件事：一是让grub加载指定的内核镜像文件；二是给内核传递启动参数。其中root=/dev/sda2指定根文件系统设备，这里的设备名是Linux语法，对应grub里的(hd0,gpt2)。ro表示先以只读方式挂载根文件系统，这是Linux标准启动流程的一部分，目的是在挂载前让文件系统检查先跑一遍。

接着加载initrd：

code复制initrd /boot/initrd.img-6.8.0-45-generic

initrd全称initial ramdisk，是初始内存磁盘。它里面打包了内核早期启动阶段需要的一些驱动和工具，例如磁盘控制器驱动、文件系统驱动等。很多新手会漏掉这一步，结果内核加载后无法挂载根分区，系统停在initramfs的busybox界面。内核文件与initrd文件必须配对使用，这是基本的匹配规则。

3.4 执行boot命令

前面所有命令都没有报错之后，最后执行：

code复制boot

机器会开始加载内核。顺利的话，几秒后你会看到内核启动日志，然后进入initramfs阶段，最后到达登录界面或者图形界面。

3.5 这一步可能遇到的报错与对策

我把自己实际遇到的报错列出来，按出现频率排序：

报错1：error: file '/boot/vmlinuz-6.8.0-45-generic' not found

root设错了，或者内核文件名不对。用ls $root/boot/查看实际存在的文件名，不要凭记忆输入。还有可能是独立/boot分区的情况，这时候路径里不应该有/boot前缀——直接用/vmlinuz-6.8.0-45-generic。

报错2：error: you need to load the kernel first

在linux命令之前执行了boot，或者只执行了initrd没有执行linux。顺序必须是linux在先，initrd在后，boot最后。

报错3：error: invalid arch independent ELF magic

你把某个非内核文件传给了linux命令，比如文件名写错，把initrd文件当成了内核镜像。

报错4：error: disk 'hd0,gpt2' not found

分区编号写错了。用ls重新确认磁盘布局，注意检查当前机器是BIOS还是UEFI启动，两者模式下分区编号的呈现方式会有差异。

3.6 UEFI与BIOS模式下命令链路的差别

UEFI模式下，grub通常还要求你手动加载EFI系统分区，但如果core.img是从EFI文件加载的，EFI分区已经由固件告知grub了。真正需要手动干预的场景更多出现在BIOS模式下。多数时候，上面这套命令在两种模式下都通用。区别在于，UEFI机器上grub-install时建议指定--target=x86_64-efi，这个放到第4节细说。

4. 引导成功只是临时方案：把grub菜单修复回自动化状态

手工引导成功，说明系统本身没有坏，现在需要做的就是把开机流程恢复到自动状态。否则你每次重启还得蹲在grub>前面敲命令，这在生产环境里是不可接受的。

4.1 进系统后按顺序执行三件事

进入Ubuntu桌面后打开终端，依次执行：

code复制sudo update-grub
sudo grub-install /dev/sda
sudo update-grub

第一行update-grub扫描当前系统的内核列表、其他操作系统的引导项，重新生成/boot/grub/grub.cfg。第二行grub-install负责把grub的引导代码写入磁盘指定位置。第三行再次执行update-grub，是因为grub-install可能更新了部分模块路径，让配置文件与安装结果保持一致。

这里必须强调update-grub和grub-install的区别：前者只是重建配置文件，不把引导代码写进磁盘；后者才是真正安装引导代码。如果引导代码本身被Windows或者其他系统覆盖了，只跑update-grub没有任何作用，重启后照样进grub>。

在UEFI环境下，执行grub-install之后，还可以用efibootmgr确认固件里的引导项状态：

code复制efibootmgr -v

输出中会列出当前固件的启动顺序和各启动项。如果找不到包含ubuntu字样的启动项，需要用下面命令手动添加：

code复制sudo efibootmgr -c -d /dev/sda -p 1 -L "Ubuntu" -l \\EFI\\ubuntu\\grubx64.efi

参数说明：-d指定磁盘设备，-p指定EFI分区号，-L是显示名称，-l是EFI文件的路径。注意路径里的反斜杠要用双反斜杠转义。

4.2 双系统环境下最常见的两个坑

Windows和Ubuntu双系统的用户，在修复grub时通常遇到两类问题。

坑一：grub菜单里没有Windows入口

如果修复后grub菜单里只有Ubuntu，没有Windows Boot Manager，大概率是os-prober功能没有启用。较新的grub版本默认禁用了这个探测外部系统的功能。你需要编辑/etc/default/grub，确认或者添加这一行：

code复制GRUB_DISABLE_OS_PROBER=false

保存后重新执行：

code复制sudo update-grub

这次生成菜单时，grub会去扫描其他磁盘分区，发现Windows引导项并加入菜单。

坑二：修复grub之后Windows也进不去了

这种情况通常发生在同一块磁盘上的双系统环境。如果grub-install覆盖了主引导记录，而grub菜单里又没有正确识别Windows引导项，就会导致Windows无法启动。处理办法是进入Linux后先恢复os-prober，重新生成完整的grub.cfg。如果Linux也无法进入，那就需要从Windows安装U盘启动，进入命令提示符执行bootrec /fixmbr，但这个操作会同时去掉grub，属于把问题换了一个方向。

说实话，双系统grub修复最需要谨慎的场景就是这类同一个磁盘两个系统。我在处理时，通常会先用lsblk -f把整个磁盘的分区情况和文件系统类型记录下来，再决定grub-install的目标磁盘。分区表信息错乱的时候，贸然写入主引导记录，后果可能比原来的问题更麻烦。

4.3 为什么不建议马上重装系统

我在社区里看到很多人在grub>这个阶段直接选择重装。如果系统里没有重要数据，重装当然是最省心的。但如果系统上有长时间积累的开发环境、数据库、配置脚本，那花10分钟手工引导再修复，显然比重装后重新搭建环境要划算得多。grub提示符本质上是一个可修复的启动问题，而不是系统逻辑损坏的问题。

5. 复杂环境下的手工引导：LVM、全盘加密与USB键盘失灵

上面介绍的流程适用于普通的/dev/sda分区方案。但现实中还有不少进阶配置，比如服务器上常用的LVM、装系统时勾选了全盘加密，这些情况下的引导命令会稍有不同。另外还有一个经常被忽略但非常让人抓狂的问题：grub界面键盘不能用。

5.1 LVM逻辑卷管理的手工引导

如果当初安装时使用了LVM，ls输出的分区结构会和普通方案有明显差别。典型布局是：

• /boot分区是普通的/dev/sda2
• 根文件系统位于LVM卷组ubuntu-vg里面的逻辑卷root上

grub自身不认识LVM逻辑卷，需要先加载LVM模块：

code复制insmod lvm

加载后，ls可能会多出一个类似(hd0,gpt2)/ubuntu-vg-root的项。这时候引导命令变成：

code复制set root=(hd0,gpt2)
linux /vmlinuz-6.8.0-45-generic root=/dev/mapper/ubuntu--vg-root ro
initrd /initrd.img-6.8.0-45-generic
boot

注意这里的root=/dev/mapper/ubuntu--vg-root，这是LVM逻辑卷在内核中的设备节点路径。卷组名和逻辑卷名之间用两个连字符转义，这个细节非常容易写错。

如果/boot也放进了LVM逻辑卷，那linux和initrd命令里的路径还会再变。最简单的方法是先用ls把$root/根目录内容看清楚，确认内核文件就在/下还是/boot/下，再决定路径怎么写。

5.2 全盘加密（LUKS）的情况下怎么引导

如果安装时勾选了加密整个磁盘，那么根文件系统还被包了一层LUKS加密。手工引导时要给内核追加cryptdevice参数：

code复制linux /vmlinuz-6.8.0-45-generic root=/dev/mapper/ubuntu--vg-root ro cryptdevice=/dev/sda5:cryptroot

这里/dev/sda5是LUKS加密分区的实际设备，cryptroot是解密后映射到/dev/mapper/下的名称。内层结构可能是LVM，也可能直接是ext4，具体要看安装时的方案。引导过程中到initramfs阶段会提示你输入加密密码，这个环节需要等待。

说实话，全盘加密的场景手工引导难度明显高一个等级。我再怎么强调也不为过：这类机器建议提前准备好备份，并且在系统正常时就把/etc/crypttab和/etc/default/grub里的参数截图存档。否则真到grub>提示符时，靠记忆敲这些参数基本等于盲人摸象。

5.3 grub界面键盘失灵的应急处理

“grub界面键盘不能用”这个搜索词排得很高，说明这是很多人卡住的真实痛点。USB键盘在grub阶段没有反应，通常是因为主板固件在这个阶段还没有把USB控制器的控制权完全交接给操作系统，或者grub的USB驱动没有正确加载。

我能想到的应急办法按优先顺序排列：

1. 把USB键盘换到主机背面USB接口，特别是那些标着“BIOS/固件更新专用”的接口。
2. 有PS/2接口的话，找一只老式PS/2键盘插上。
3. 重启进BIOS，检查“Legacy USB Support”或“XHCI Hand-off”这几项，把它们开启。
4. 如果只是功能键失灵，可以试试按键次数稍重一些，有时候信号不稳定。

这些方法不一定每条都有效，但至少能提高你走出grub>的概率。等你进入系统修好grub后，还可以在/etc/default/grub里加上GRUB_GFXPAYLOAD_LINUX=text这行，降低grub图形界面对USB驱动的依赖，减少下次失灵的概率。

6. 三次真实救援复盘：从现象到定位再到修复的完整链路

技术文章写到这里，原理和命令都有了。但纸上得来终觉浅，我把几个处理过的真实案例复盘出来，你会发现实际排查过程和前面讲的理论路径高度重合，但多了不少现场判断的细节。

6.1 案例一：装了Windows 10后Ubuntu悄然消失

朋友打电话说笔记本电脑重装Windows 10之后，开机直接进Windows，找不到Ubuntu的任何痕迹。

我的判断是第一引导项被Windows Boot Manager接管了。让他进BIOS手动把引导顺序改成“Ubuntu所在硬盘优先”之后，重启确实不再进Windows了，但也没出grub菜单——直接掉进grub>。

当时的排查过程是这样：

1. ls显示(hd0,gpt1)到(hd0,gpt7)共7个分区，加上整盘(hd0)。
2. 逐个执行ls (hd0,gptN)/看目录结构。
3. (hd0,gpt1)下面是EFI目录，确认是EFI系统分区。
4. (hd0,gpt4)下面有/usr、/var、/etc，确认是根分区。
5. 执行set root=(hd0,gpt4)，ls $root/boot/看到vmlinuz-5.15.0-91-generic。
6. 依次执行linux、initrd、boot，成功进入系统。

进系统后的修复动作就是第4节里那套命令。重启后grub菜单恢复，Windows也能正常引导。

6.2 案例二：硬盘迁移后分区编号全部变化

我自己遇到过更典型的场景——把一块装好Ubuntu的SSD从旧机器拆下来，接到另一台机器上作为系统盘。开机没有意外地停在grub>。

原因是磁盘物理位置变了，原先(hd0,gpt3)是根分区，新机器上磁盘编号和分区顺序都变了，grub找不到原来预设的根分区。这在数据迁移、机器升级时特别常见。处理过程跟案例一基本一致：用ls重新确认分区身份，手工引导进系统后重新执行grub-install，让grub记住新环境下的引导路径。

6.3 案例三：手滑改坏grub配置文件的惨痛经历

第三次是给一台开发服务器升级grub主题，编辑了/etc/default/grub，顺手把GRUB_CMDLINE_LINUX_DEFAULT里面的参数改错了一个，执行update-grub之后没有仔细检查生成的配置文件，重启就进了grub>。

那次现场比较紧张，因为服务器上有几个容器在跑。还好只是配置文件问题，不是分区问题。用命令链路引导进系统后，先检查/etc/default/grub，把参数改回来，重新update-grub，问题解决。

这次的教训我会放在后面经验里说：修改grub配置之后，重启前一定要先检查一下update-grub的输出有没有语法错误，别急着重启。

6.4 我桌面键盘上一直备着一个引导修复U盘

经历过这些事故之后，我现在会在所有自己管理的Ubuntu机器上做三件事：

1. 备份/etc/default/grub为/etc/default/grub.bak，改出问题可以随时恢复。
2. 系统正常时把/boot/grub/grub.cfg压缩备份到/root/下。
3. 用lsblk -f记录分区信息，存到笔记软件里。

另外，个人强烈建议做一个Boot-Repair-Disk或者SystemRescue的启动U盘，放在抽屉里备用。Boot-Repair的自动修复功能解决过不少分区表和grub配置问题。但它不是万能的，LVM、LUKS、定制内核这些场景还需要手动介入。我的使用原则是：能自动修的用自动修，自动修不了的，手动命令链路至少能保证你不至于彻底进不了系统。

7. 这件事的底层逻辑与一点长期建议

回顾整个grub>救援过程，你会发现核心思路就一句话：给引导器提供它缺失的信息。grub不知道根分区在哪，你告诉它；不知道内核文件在哪，你告诉它；不知道从哪里加载initrd，你也告诉它。当这些信息通过命令行补全之后，引导流程就能继续往下走。

很多人有一个误区，以为grub>是系统“报废”的信号。实际上它更像是机器在说：我不知道接下来该启动什么，但我把选择权交给你了。这反而说明grub主体是完好的，系统文件大概率也还在。真正到了“grub不是提示符而是直接黑屏”或者“连grub字样都看不到”的程度，那才说明引导阶段更早就出了问题。

给一个我个人的长期建议：掌握这套手工引导命令，不只是在出问题时救急。它还能帮你理解Linux启动的完整链路——固件、引导器、内核、initrd、根文件系统各自负责什么，启动参数里root=、ro这些字段有什么用。这些知识在排查其他启动类问题时同样适用，远比死记几个命令值钱。

如果你在grub>提示符前卡住了，可以按照本文的顺序走一遍：先ls看清分区，再set root验证，然后linux、initrd、boot三连。进系统后不要着急收工，把update-grub和grub-install跑完，确保下次开机能自己起来。这趟流程下来，你的系统就回来了，你对Linux启动的理解也会更深一层。