fedora 37 的内核就是一个 gzip 格式的压缩包：
file /boot/vmlinuz-6.0.7-301.fc37.aarch64
/boot/vmlinuz-6.0.7-301.fc37.aarch64: gzip compressed data, max compression, from Unix, original size modulo 2^32 46483968
而 fedora 38 的内核就不知道是什么意思了：
file vmlinuz-6.2.9-300.fc38.aarch64
vmlinuz-6.2.9-300.fc38.aarch64: PE32+ executable (EFI application) Aarch64 (stripped to external PDB), for MS Windows, 2 sections
我的问题是 PE32+ executable 格式的内核是怎么被 u-boot 加载启动的？ u-boot 应该不支持这个格式吧?
 |
1
ysc3839 May 29, 2023 via Android
|
 |
2
wniming OP @ysc3839 感谢回复，我知道内核可以伪装成 efi 文件让 uefi 固件来加载，u-boot 也部分实现了 uefi 协议，但 arm64 的内核不像 x86 那样还自带解压缩程序，而这个 efi 文件的大小和 fedora 37 的 gzip 格式的内核大小差不多，肯定也是被压缩过的，那么解压缩这个步骤是谁来执行呢？
|
 |
4
yzwduck May 29, 2023 via Android
我觉得这可能不是 efistub 而是 Unified Kernel Image? 参见 https://wiki.archlinux.org/title/Unified_kernel_image 与 https://www.phoronix.com/news/Fedora-38-Unified-Kernel-Part-1
|
 |
6
qbqbqbqb May 29, 2023  1
@wniming 你可以理解成开启 EFISTUB 功能就是在内核上套了一层 UEFI 的壳，其余部分的格式和原来的内核没什么差别，引导器想要绕过这层壳像原来一样直接加载启动也是可以的。
比如说 x86-64 UEFI 的情况下，grub2-x86_64-efi 是不用 UEFI 的机制，类似传统方法自行加载内核启动的；而 rEFInd, systemd-boot 等引导器是利用 UEFI 的机制加载启动（相当于 chainload ）。 验证方法是在 secure boot 的环境下，GRUB 只需要引导器本身有签名，如果关闭了 GRUB 另带的验证机制（需要自行编译或者使用不原生支持 secure boot 的发行版；像 ubuntu 这种原生支持的一般都自带额外的验证），可以直接加载未签名的内核并启动；而 rEFInd, systemd-boot 等引导器除了引导器的 efi 文件需要签名以外，内核文件也需要签名，否则会被 UEFI 拒绝。 所以说原来怎么解压，现在还是怎么解压。 |
|
7
qbqbqbqb May 29, 2023 1
按照 fedora 的官方说法，是使用了 CONFIG_EFI_ZBOOT 这个功能（ 6.1 版本加入内核，以前为第三方补丁），可以支持 UEFI 环境下解压内核，同时兼容非 UEFI 环境，由引导器按照以前的方法解压内核。
https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 |
Select Language