增加boot分区大小导致升级后分区损坏

[wi11iamzhao]

详细叙述

#11741 会导致在luci中升级固件后分区损坏
可能会破坏docker的opt分区
甚至导致系统启动时卡在waiting for root device partuuid=xxxxxx
没有必要仅仅为了消除一个警告而增加升级时的风险

重复 issue

• 没有类似的 issue

具体型号

x86-64 server,esxi7.0u3

详细日志

waiting for root device partuuid=xxxxxx

[kxdn3]

问题是很多人已经升完了，改回来又完蛋一次

[coolsnowwolf]

确实是……

[zuozhehao]

我还正想问，最近固件是不是不稳定，反复编译、反复升级，反复死机

[caixin1218]

是的，20日晚上更新后就变得很不稳定了，无故重启。

[WYC-2020]

如何复现这个问题，说说 我瞧瞧 我目前 没遇到这个问题呢，按理说 你编译x86出来后 大小都是固定的最大的区别也就是 各个分区所占用的比例不同总大小应该不会便，你docker的分区肯定是在 这个总大小之后或者是另外挂盘的，不应该会导致这个问题吧

[binge8]

我的docker分区已经完蛋的升级完了 别再改回去又完蛋一次

[wi11iamzhao]

如何复现这个问题，说说 我瞧瞧 我目前 没遇到这个问题呢，按理说 你编译x86出来后 大小都是固定的最大的区别也就是 各个分区所占用的比例不同总大小应该不会便，你docker的分区肯定是在 这个总大小之后或者是另外挂盘的，不应该会导致这个问题吧

复现方法：ESXI7里面新建一个虚拟机并配置好，然后将旧版本（r23.11.11）编译出来的openwrt-x86-64-generic-squashfs-combined-efi.img转换成vmdk上传至ESXI作为虚拟机的虚拟硬盘，成功启动：

然后编译新版本并在网页后台更新：

系统重启后即卡住：

用快照恢复软路由虚拟机，把 bios boot分区大小改回256kb再编译新版本升级，一切正常。

[WYC-2020]

如何复现这个问题，说说 我瞧瞧 我目前 没遇到这个问题呢，按理说 你编译x86出来后 大小都是固定的最大的区别也就是 各个分区所占用的比例不同总大小应该不会便，你docker的分区肯定是在 这个总大小之后或者是另外挂盘的，不应该会导致这个问题吧

复现方法：ESXI7里面新建一个虚拟机并配置好，然后将旧版本（r23.11.11）编译出来的openwrt-x86-64-generic-squashfs-combined-efi.img转换成vmdk上传至ESXI作为虚拟机的虚拟硬盘，成功启动： 然后编译新版本并在网页后台更新： 系统重启后即卡住： 用快照恢复软路由虚拟机，把 bios boot分区大小改回256kb再编译新版本升级，一切正常。

明天我试试看

[WYC-2020]

如何复现这个问题，说说 我瞧瞧 我目前 没遇到这个问题呢，按理说 你编译x86出来后 大小都是固定的最大的区别也就是 各个分区所占用的比例不同总大小应该不会便，你docker的分区肯定是在 这个总大小之后或者是另外挂盘的，不应该会导致这个问题吧

复现方法：ESXI7里面新建一个虚拟机并配置好，然后将旧版本（r23.11.11）编译出来的openwrt-x86-64-generic-squashfs-combined-efi.img转换成vmdk上传至ESXI作为虚拟机的虚拟硬盘，成功启动： 然后编译新版本并在网页后台更新： 系统重启后即卡住： 用快照恢复软路由虚拟机，把 bios boot分区大小改回256kb再编译新版本升级，一切正常。

这个23.11.11 这个我没有 给一个固件 我试试

[WYC-2020]

刚抽一点时间 试了下，我懒得回退编译，我直接用的l的R23.4.1版本 转成vmdk后 刷我的那个固件 确实不行，但是并不是boot导致的，因为我编译的固件是2G 明显基于23.4.1生成的VMDK肯定是不够的，为了猜测我这个想法，我直接新建了一个空白的磁盘3G然后磁盘克隆吧23.4.1的所有内容复制过去，然后再用工具吧这个磁盘转成vmdk，然后各种刷过去刷过来 没遇到你这个问题，你重点看下 你那个vmdk原来是多大，你后面刷入的固件又是多大 我验证怀疑你是固件大小不同混刷导致，混刷的话从大到小刷没问题，从小到大刷肯定是不行的，东西都放不下

[WYC-2020]

因为 这个调整对齐后，那个指定分区前面的大小会有变化的会变成1M所以，不要每次刚好固件的大小 一点冗余都没得 ，从这个图就可以看出实际的大小并不是固件指定的大小，因为以前对齐的时候 第二个分区好像不是1M很小的，但是这里改了后 这里就变成1m了 会导致可能你原来的分区大小差那么一点点 ，所以就会出现这个问题，

[WYC-2020]

这个是原来 bios对齐没改的时候

这是改了的，下面那个2G别看，对比前面 你就会知道，原来是17K+239K+16M+400M 够成的整个vmdk，现在调整分区对齐后，应该要17K+1M+16M+400M 明显原来的不够了，以为那个转换出来的vmdk是一点冗余都没得的 完全不够 自然就洗白白了哈哈

[wi11iamzhao]

刚抽一点时间 试了下，我懒得回退编译，我直接用的l的R23.4.1版本 转成vmdk后 刷我的那个固件 确实不行，但是并不是boot导致的，因为我编译的固件是2G 明显基于23.4.1生成的VMDK肯定是不够的，为了猜测我这个想法，我直接新建了一个空白的磁盘3G然后磁盘克隆吧23.4.1的所有内容复制过去，然后再用工具吧这个磁盘转成vmdk，然后各种刷过去刷过来 没遇到你这个问题，你重点看下 你那个vmdk原来是多大，你后面刷入的固件又是多大 我验证怀疑你是固件大小不同混刷导致，混刷的话从大到小刷没问题，从小到大刷肯定是不行的，东西都放不下

我使用到的img和vmdk：https://drive.google.com/drive/folders/1CU5jtOyWW1GVmFy0fozbBrDVo2_PI929
从用户的角度这个问题确实会造成虚拟化的软路由升级后系统损坏，非虚拟化的情况下如果影片中存在后续分区或者原始配置正好占用了全部空间时的影响还不确定。如果用ESXI虚拟化又将管理网口也虚拟化，软路由系统意外损坏恢复会非常麻烦。
个人认为没有必要仅仅消除一个warming就引入这些风险，而且用户不仔细检查Commits记录很难发现这一变化。

[WYC-2020]

刚抽一点时间 试了下，我懒得回退编译，我直接用的l的R23.4.1版本 转成vmdk后 刷我的那个固件 确实不行，但是并不是boot导致的，因为我编译的固件是2G 明显基于23.4.1生成的VMDK肯定是不够的，为了猜测我这个想法，我直接新建了一个空白的磁盘3G然后磁盘克隆吧23.4.1的所有内容复制过去，然后再用工具吧这个磁盘转成vmdk，然后各种刷过去刷过来 没遇到你这个问题，你重点看下 你那个vmdk原来是多大，你后面刷入的固件又是多大 我验证怀疑你是固件大小不同混刷导致，混刷的话从大到小刷没问题，从小到大刷肯定是不行的，东西都放不下

我使用到的img和vmdk：https://drive.google.com/drive/folders/1CU5jtOyWW1GVmFy0fozbBrDVo2_PI929 从用户的角度这个问题确实会造成虚拟化的软路由升级后系统损坏，非虚拟化的情况下如果影片中存在后续分区或者原始配置正好占用了全部空间时的影响还不确定。如果用ESXI虚拟化又将管理网口也虚拟化，软路由系统意外损坏恢复会非常麻烦。 个人认为没有必要仅仅消除一个warming就引入这些风险，而且用户不仔细检查Commits记录很难发现这一变化。

想太多了，你说他是bug吗并不是，只是不兼容以前的，这一刀切的多的是，没办法，开源项目很多东西都是个人感觉可以这样，并不会考虑很多兼容性的，改来改去正常的很，按我那个理解的话，现在改回去就不会有任何问题，因为最多只会从大变小，所以刷机需谨慎哦，很多提交并不会所有的都测试，目测这个也只会在vmdk这种上面，可怜的孩子

[binge8]

这谁啊，可别恢复了。大部分都升级完了，退回去又得完蛋

[WYC-2020]

这谁啊，可别恢复了。大部分都升级完了，退回去又得完蛋

回去应该不会挂 ，但是既然都已经全部升级了 那就没必要再改回去了，大不了搞一个 提示 置顶就行了 让 通过 以前vmdk的 留意即可，有数据保留的 先把以前的vmdk 用dg打开 克隆到新的即可

[binge8]

这谁啊，可别恢复了。大部分都升级完了，退回去又得完蛋

回去应该不会挂 ，但是既然都已经全部升级了 那就没必要再改回去了，大不了搞一个 提示 置顶就行了 让 通过 以前vmdk的 留意即可，有数据保留的 先把以前的vmdk 用dg打开 克隆到新的即可

赞同

[wi11iamzhao]

ESXI下boot分区1M的用256K的升级不不会破坏分区

[WYC-2020]

原因都分析过了的 没必要了，只是不兼容导致的而已，如果一开始 这个值是125 对齐的话 256一样也会破坏 只是这个开源项目一开始以256开始的而已，就这么简单，至于那个 1M好像是uefi这个标准有一个优化来的，建议是1M

[binge8]

都软路由了还在乎那1M吗？大点肯定没坏处。还在这纠结这个那个退回的，有毛病。

[wlshdjj]

楼上，讨论技术的时候，收回你这种态度。
在第一眼扫过那个commit的代码的时候，我就摇头，这必定害惨一堆人。
从技术上说，linux的很多东西从一开始就是错误的或者不算最佳，但是这么久以来都没有去强制更改过来，而是遵循着原来的错误使用下去，只要目的达到就不去管它，这是为什么？这是要考虑到绝大多数人。
或许提交的人并没有错，因为当局者迷，但掌控全局的维护者却没有经过深思熟虑。

[binge8]

什么玩意乱七八糟，上纲上线的怎么还在这纠结，还掌控全局的维护者没有深思熟虑，还讨论技术，这玩意都明摆着了在朝着优化完善的方向发展，还用讨论吗，赶紧关贴吧，浪费感情