（欢迎来到新的“让我们讨厌微软”主题）
华硕笔记本电脑配备 500GB SSD 驱动器，150GB NTFS Windows 分区和 350GB Ubuntu 20.04 分区（几乎可以肯定它是 ext4）。双启动时 GRUB/Ubuntu 优先于 Windows。重要数据在 Ubuntu 分区上，而不是在 Windows 分区上。
经过 1 小时的 Windows 更新后，没有任何意外（没有断电或其他情况），计算机启动到 GRUB 命令行（“grub>”，而不是“grub rescue>”）。更烦人的是，插入活动 USB 密钥时也会发生这种情况（18.04，在另一台笔记本电脑上测试正常）。在提示符下使用“exit”时，Windows 可以正常启动。
以上就是概述，现在来看看具体细节。首先，插入 USB 密钥后，屏幕上会快速显示以下内容
Failed to open EFI\BOOT\grubx64.efi - Not Found
Failed to load image EFI\BOOT\grubx64.efi - Not Found
start_image() returned Not Found
一秒钟后出现“grub>”提示符
在“grub>”提示符下，ls 返回
(proc) (hd0) (hd0,msdos1) (hd1) (hd2) (hd2,gpt6) (hd2,gpt5) (hd2,gpt4) (hd2,gpt3) (hd2,gpt2) (hd2,gpt1)
ls (proc) 返回
Device proc: Filesystem type procfs - Sector size 512B - Total size 0KiB
实时 USB 为 hd0，正如预期的那样 ls (hd0,1) 返回
Partition hd0,msdos1: Filesystem type fat - Label 'Ubuntu 18_0', UUID 864E-2850 - Partition start at 1024KiB - Total size 15150080KiB
我不知道 hd1 是什么；这台电脑以前有一个 HDD，几年前被 SSD 替换了，也许这是它的踪迹。 ls (hd1) 返回
Device hd1: No known filesystem detected - Sector size 2048B - Total size 514KiB
hd2 是真正的硬盘。 ls (hd2) 描述设备
Device hd2: No known filesystem detected - Sector size 512B - Total size 488386584KiB
ls (hd2,xx) for xx= 6 to 1 描述分区
Partition hd2,6: No known filesystem detected - Partition start at 14684736KiB - Total size 341580800KiB
Partition hd2,5: Filesystem type ntfs, UUID84127C1A127C1380 - Partition start at 146205696KiB - Total size 598016KiB
Partition hd2,4: Filesystem type ntfs, UUID22FE5C86FE5C53DF - Partition start at 661504KiB - Total size 145543516KiB
Partition hd2,3: No known filesystem detected - Partition start at 645120KiB - Total size 16384KiB
Partition hd2,2: Filesystem type fat, UUID 0057-5017 - Partition start at 542720KiB - Total size 102400KiB
Partition hd2,1: Filesystem type ntfs, Label 'Rcupration' - Partition start at 1024KiB - Total size 541696KiB
hd2,6 似乎是 350GB 的 Ubuntu 分区。据我所知，它不应该显示“未检测到已知文件系统”，在另一台笔记本电脑中，grub ls 命令可以正确检测到 ext 结构。hd2,4 似乎是 Windows 分区。hd2,1 的名字很奇怪，因为法语中的重音符号不显示
当我尝试使用
set prefix=(hd2,gpt6)/boot/grub
set root=(hd2,gpt6)
insmod normal
normal
什么都没发生（我想如果它不能告诉文件系统，这是意料之中的事）。当我尝试启动密钥时，使用
set prefix=(hd0,1)/boot/grub
set root=(hd0,1)
insmod normal
normal
我得到了实时 USB 提示，但当我选择“尝试 Ubuntu 而不安装”或任何其他选项时，我得到了
error: /casper/vmlinuz has invalid signature.
error: you need to load the kernel first.
Press any key to continue...
然后返回实时键菜单，陷入循环。这有点奇怪，因为之前它警告我找不到 grubx64.efi，而且据我所知（更新 Windows 8 破坏了我的 GRUB) 它没有要求 shimx64.efi 的事实意味着安全启动被禁用，但那么这个签名是什么呢？ 无论如何，实时 USB 密钥上缺乏正确的启动使我无法使用常见的修复工具。
现在我仍然可以输入“exit”，然后 Windows 正常启动。在 Windows 上，我尝试下载 Testdisk。Testdisk 确实正确检测到了 Linux 分区，如下所示：
Partition Start End Size in sectors
1 P Windows Recovery Env 2048 1085439 1083392 [Basic data partition]
2 P EFI System 1085440 1290239 204800 [EFI system partition]
No FAT, NTFS, ext2, JFS, Reiser, cramfs or XFS marker
3 P MS Reserved 1290240 1323007 32768 [Microsoft reserved partition]
3 P MS Reserved 1290240 1323007 32768 [Microsoft reserved partition]
4 P MS Data 1323008 292410039 291087032 [Basic data partition]
5 P Windows Recovery Env 292411392 293607423 1196032
6 P Linux filesys. data 293609472 976771071 683161600
但是，当我进入该分区（使用 Advanced Utils）并尝试列出文件时，我得到了
Support for this filesystem wasn't enabled during compilation
只有 Windows 可以正常启动，所以我手头没有其他版本可以尝试在 ext4 分区上工作。另外，我刚下载了 .exe，并没有自己编译，因为我没有足够的经验来做这件事。
Testdisk 论坛上的某些帖子暗示，当某个分区被列出两次并且与上面的 3 相同时，就意味着存在问题。
所以...
我的主要目标是访问 Ubuntu 分区的文件，尽管修复昨天的一切确实很好。我看到了几种可能的途径：
- 以某种方式让 GRUB 启动 Ubuntu 分区，并将其读取为 ext4
- 让 GRUB 正确启动实时 USB 密钥（使用签名），然后从那里使用恢复工具
- 使用 Testdisk（在 Windows 上）修复 ext4 分区，以便 GRUB 可以正确查看它，或使用 Windows 上的其他类似工具
- 使用任何工具将 Ubuntu 分区读取为 ext4，取出文件，然后将计算机扔出窗外。
有人有想法吗？
无论如何，感谢您的阅读！
答案1
更新；从十六进制读取器判断，Linux 分区已完全损坏，无法在字节级别恢复。磁盘上任何地方都找不到非常短的文本字符串，我确信这些字符串存在于多个纯文本文件中。恢复工具（Photorec 和 R-Linux）根本无法检索任何文件，没有 jpeg，没有纯文本，什么都没有。虽然这可能是物理功能障碍，但其时间和范围（只有 Linux 分区，以及所有分区，而 Windows 分区可启动且功能完好）指向 Windows 更新中的错误软件。但是这个假设很难探究，所以我留下了我的问题、我的被破坏的分区，以及对未来双重启动的强烈警告（至少在没有坚固的备份设置的情况下）。