deepin的uefi又没有损毁，只是windows把它的放在了第一位吧。

如果deepin也这样来修复，不就会出现两个系统争第一的情况了吗？

我是因为其他目的，将主板BIOS恢复到legacy模式并恢复出厂设置后，再恢复成uefi模式启动发现这个问题的，后来又自己在uefi BIOS中手动删除了deepin和Windows boot manager启动项进行测试，发现win系统只要能进入到bcd菜单这一步，就会自动检查主板uefi启动序列中有没有Windows boot manager项，如果没有就会自动添加并列为第一启动项，如果有（但无论其在第几启动序列），则不会对uefi启动序列做任何修改。而deepin就没有这个自我保护设计，从开机启动到显示grub菜单期间，都不会检查主板uefi启动序列中还有没有deepin启动项，所以只要主板完全恢复出厂设置清空了所有后加的uefi启动项，再重新启动电脑并进入一次win系统，然后再重启就会直接启动win或进入win的bcd菜单，而不会进入到grub菜单了，也就无法启动deepin了。

你说的调整uefi启动顺序与uefi启动序列中deepin项丢失不是一个概念，uefi中的deepin启动项都没了，又没有设计自我恢复去保护，还怎么调整啊？只能自己手动添加，虽然并不难，但终究不如自动恢复方便。

不会争第一的。win系统和deepin系统都只是在安装系统首次修改uefi启动序列时会争第一。安装好以后再启动，win系统只检查有没有其启动项而不管是不是第一了，如果没有才添加并设为第一项。deepin则不检查uefi中还有没有deepin启动项，没了就没了。

我不是非常理解你的问题。

你清空所有uefi启动项之后是如何进入windows的？如果以相同方式进入deepin会发生什么？

清空后，第一次开机依然会进入到grub菜单（应该是机器自动搜索到esp分区里deepin目录里的grub64.efi或者shimx64.efi等启动文件产生的），进入grub菜单后，里面有安装系统时自动生产的deepin启动项也有Windows启动项，选择进入deepin系统后，不会对主板uef启动序列i和grub菜单有任何影响，如此后一直选择进deepin系统，则每次开机都可进入grub菜单选择deepin系统，但如果选择进入Windows，只要一次，以后再开机就不会再进入grub菜单而是直接进入Windows了，因为win系统在主板uefi启动序列中添加了直接指向Windows启动管理器的启动项，所以不会再自动搜索esp分区上的deepin目录中的启动文件了。我不知道这样有没有说清楚，你可以自己动手删了uefi启动序列中deepin和Windows bootmanager两个启动项实验一下看看，应该就能明白了。

第一次那个应该叫硬盘启动。我猜应该是认bootx64.efi，这通常认为是硬盘的默认启动项。

那么你直接把硬盘启动调到windows boot mgr前面就行。

是的，这样确实可以。但这个默认的boot64.efi并非某个操作系统专用，任何系统都可能修改或用同名文件将其替换，如果在安装deepin系统之后又有其他系统把这个文件换了就不行了，所以终究不如win系统自我检查恢复其专用启动项保险。

因为这次丢失deepin启动项的经历，我又专门测试了esp分区被破坏的情况下deepin系统的启动和引导修复。

发现如果esp分区被删除后再重建，用deepin的liveCD中的修复工具是无法修复引导的，错误提示为：boot/efi分区看起来不像是一个efi分区。

我搞不清这是为什么，因为重建的esp分区就是在liveCD里用分区工具建的，也设置了分区标识为boot-esp，而且重建esp分区后，用U盘启动进入winPE，用dism++或其他工具都可以正常修复win系统的引导。因为无法修复deepin的引导，最后我只好用备份还原工具从备份文件中恢复esp分区，开机才能重新进入grub菜单，但这个操作其实已经不是引导修复，而是备份还原了。

一般来说linux将自己置为默认启动项的方法就是替换bootx64.efi，而windows似乎就是修改uefi启动菜单。我不太喜欢自动修复这个想法。efi分区和uefi启动菜单不是不小心就能破坏的东西，用户在破坏之前就应该知道破坏的后果。

不过livecd里面的引导修复工具确实应该具备这样的功能。livecd里面的系统修复工具好久没更新了，感觉官方都不想理livecd了。

添加uefi启动项这一步在linux下是这么操作的：

efibootmgr --unicode --disk /dev/$disk --part $Y --create --label "deepin" --loader /EFI/BOOT/BOOTx64.EFI

其中$disk是efi分区所在磁盘，$Y是efi位于磁盘上第几个分区，--loader后面的参数替换为引导文件相对于efi分区根路径而言的路径。现在暂时只能用这个凑合一下了。

我的想法跟你不一样，esp分区在硬盘不出故障的时候确实很少会被破坏，但主板uefi条目是容易被清空的，比如电脑出了硬件故障送修时，维修人员就很可能恢复出厂设置。而且我认为既然deepin在安装时会自动添加一个deepin启动项，就应该能自我保护这个启动项，而不要依赖默认的boot64.efi，win系统就是这么干的，这对完全不懂uefi BIOS设置的人比较友好。

当然自我保护修复uefi条目中的deepin启动项时，还要考虑把Windows boot manager启动项也恢复，不然Windows一启动检测到uefi中没有其专属启动项又会自动修复并将其作为第一启动项，而且不会考虑硬盘上有没有其他系统。

修复windows boot manager不可能，作为windows的一部分，这东西也受windows版权保护，不能随便分发。而且凭什么deepin要这样迁就windows啊。。。

至于deepin是否应该自动修复，我持保留意见。维修人员的工作是把电脑修成没坏之前的样子，不是给你一台全新的电脑，那叫换不叫修。重置了bios就不管了这属于没修好。系统自检没办法面面俱到，这个需求是否值得每次启动的时候花时间去检测一遍，我个人是持保留意见的。

你说的也有道理。

但我觉得这不是迁就Windows，而是要和Windows针锋相对。我想，既然win系统这么简单粗暴修改启动项做自我保护，deepin就也应该自我检查修复，不劳用户操心。

时间也应该不是大问题，因为我发现win系统在开机进入bcd菜单前，连具体启动的系统都没进时，就完成其专属启动项的修复了。而且修复只是在检测到没有专属启动项时才修复，有的话就直接跳过了。

版权问题我不太明白？既然安装deepin时可以自动搜索硬盘上有没有Win系统并在grub菜单中生成一个指向Windows boot manager的启动项没有版权问题，那么修复uefi启动项时添加一个win启动就应该也没版权问题啊。

倒是另外一个问题比较复杂，就是有没有其他系统也如win系统一样粗暴修改uefi启动条目是不是要考虑，如果考虑太多的话，就不如不干这事了。

如果只是添加一个uefi启动项确实是没有版权问题的。

但是如果是esp分区损毁的情况，windows boot manager已经不存在了，你需要重新安装windows boot manager，此时就会出现版权问题。

那问题就不复杂，esp分区损毁的情况下，就只能从U盘启动修复引导了，这种情况与uefi后加条目被清空不一样，因为esp分区里的boot64.efi文件都没有了，自然也谈不上自我检查修复deepin的uefi启动项了。

这个情况下，能自己安装双系统的都应该会用pe里的工具修复Windows引导，也应该会用liveCD里的工具修复deepin的引导。

但我今天测试格式化esp分区重建后 ，不知道为什么用liveCD里的工具修复deepin引导一直失败，用pe里的dism++修复Windows引导就没问题，你帮我想一想是哪个啥问题。

我手头没有efi启动的deepin

这个错误提示看起来是挂载错误了。这个挂载操作我没怎么看懂，他把/dev/sda7挂载到了/boot，又试图把/dev/sda1挂载到/boot/efi。你的磁盘分区情况是怎么样的？你试试手动挂载一下？

/dev/sad7是我单独划分出的一个boot分区，大小2G，挂到/boot是正确的，/dev/sad1就是ESP分区，是删除后重建的。

我感觉liveCD里的修复工具有BUG，因为我将esp分区删除再重建后，用liveCD中的工具修复引导都是失败的。但如果用备份还原工具将esp分区还原，系统可以正常启动，进入系统后在终端执sudo update-grub命令可以正常修复，但其实在系统已经启动的情况下，执行这个命令不能叫修复，最多叫更新，因为此前系统引导就是完好的，这个命令只是重写了一遍罢了。而且用备份还原工具恢复esp分区后（引导也一起恢复了），用liveCD里用工具修复依然失败，只有在新安装系统后进入liveCD时可以成功执行引导修复，但新装系统引导是完好的，可以修复没意义，在损毁的时候能修复才有意义，所以这个工具肯定有BUG。

引导修复工具要做到系统根目录所在分区及boot分区（如果有的话）没有被破坏的情况下，只要有个ESP分区，就能修复引导，甚至可以更智能一点，即使没有ESP分区，只要硬盘上还有300MB空闲空间就能自动建立一个esp分区并修复引导，这样才叫修复。

这是在系统启动后执行sudo update-grub的结果

这是系统分区情况

这是在liveCD中用工具修复的结果显示

因为用工具不能修复损毁的引导，所以我现在只用备份还原ESP分区的办法代替用工具引导修复，虽然也挺简单的，但工具不能修复引导始终是个问题。

我也遇到这个问题，没有楼主这么专业，能说出原因。我有两台惠普笔记本，一台老的 4 代 i5 处理器，单机械硬盘，安装 win10+deepin 双系统，怎么启动都没有问题。一台新的，7 代 i5 处理器，单固态硬盘，同样的方式安装双系统，启动 win10 报错，每次要恢复 BIOS 出厂设置，才能进 win10，如果下次要进 deepin，也要恢复 BIOS 出厂设置才能进 deepin