Windows严重破坏了GRUB2，即使是一个活动的USB键也无法启动(2021年9月)
(欢迎来到一个新的“让我们恨微软”的帖子)
华硕笔记本电脑有一个500 is的SSD驱动器，一个150 is的NTFS分区和一个350 is的Ubuntu20.04分区(几乎可以肯定它是ext4)。带有GRUB/Ubuntu的双引导，具有Windows的优先级。Ubuntu分区上的重要数据，而不是Windows分区上的重要数据。
经过1小时的Windows更新后，没有发生任何事故(没有停电或其他任何情况)，计算机将引导到GRUB命令行("grub>"，而不是"grub rescue>")。更令人烦恼的是，当一个USB键被插入时(18.04，在另一台笔记本上测试良好)，也会发生这种情况。在提示Windows上正确使用"exit“引导时。
这是概述，现在是细节。首先，使用活动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是什么；计算机以前有一个硬盘，几年前就被SSD取代了，也许这就是其中的一个痕迹。ls (hd1)返回
Device hd1: No known filesystem detected - Sector size 2048B - Total size 514KiBhd2是真正的硬盘。ls (hd2)描述该设备
Device hd2: No known filesystem detected - Sector size 512B - Total size 488386584KiBls (hd2，xx)用于xx= 6到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 541696KiBhd2,6似乎是350 be的Ubuntu分区。据我所知，它不应该说“未检测到任何已知的文件系统”，在另一台膝上型计算机中，grub命令正确地检测到ext结构。hd2,4似乎是Windows分区。‘t 2，1有一个奇怪的名字，因为法语中的重音不显示
当我尝试从linux分区引导时，
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键，使我无法使用常见的修复工具。
现在我仍然可以输入“退出”，然后正常启动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 )并尝试列出文件时，我得到
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
Ask Ubuntu用户
发布于 2021-10-04 20:55:53
更新；从十六进制读取器判断，Linux分区在字节级别已经被彻底破坏，无法进行任何恢复。在磁盘上的任何地方都找不到非常短的文本字符串，而我知道这些字符串肯定存在于多个纯文本文件中。恢复工具(Photorec和nothing )根本不检索任何文件，没有jpeg，没有纯文本，什么也没有。虽然这可能是一种物理功能障碍，但它的定时和周长(只有Linux分区，以及所有这些，而Windows分区是可引导的和功能完善的)指向Windows更新中的错误软件。但是，这个假设并不容易探索，所以我只剩下我的问题，我的垃圾分区，以及对未来双引导的强烈警告(至少没有一个铁板一块的备份设置)。
https://askubuntu.com/questions/1365773
复制相似问题
腾讯云开发者
