linux系统升级后，手动编译的kernel无法启动问题

做开发相关，需要编译3.18的kernel，x86_64的，但是我的deepin升级v20之后，编译的kernel就无法启动了，引导不了，直接重启。

解决办法在最后

重启位置

启动打印如下，然后重启

early console in decompress_kernelDecompressing Linux... Parsing ELF...

因为重启很快，打印很快闪过，添加启动参数，需要将earlyprintk打印到串口记录下来。

APPEND root=/dev/sda1 rw earlyprintk=ttyS0,115200

代码查看

grep kernel代码，加了一点打印，发现内核解压完之后，在将程序段复制到内存时失败，memcpy阶段重启了。
还看了下编译过程，但也就限于了解下是如何编译的。
使用readelf分析了下各个文件的信息，和之前可以启动的相比，arch/x86/boot/comprssed/vmlinux.bin程序段个数不一样多。
能力有限，就只能分析到这里了。

因为系统升级前可以，所以问题肯定出在一些软件包，库等更新了，导致编译的东西有问题，但是无法定位哪个软件包有问题。

怀疑对象：ld，objcopy，nm等

对比代码

编译了master上最新的kernel，启动正常，所以怀疑是kernel是后面修复了这个问题的。
主要怀疑的代码为：arch/x86/boot目录里面的代码
几经曲折，终于发现一个可疑点：
启动失败就是在这个函数，标识位置为最新kernel上有的。

合并到我的kernel里面后，系统果然卡在这个位置里面，可见是对齐问题。
然后查看kernel开发日志，找出patch
查找修改这个文件的日志，可以很快找到那次日志
提交日志

原因

从提交记录可以知道，当binutils软件包升级到2.31后，为了减少x86-64可执行文件和共享对象的大小，最大页面大小从2MB减少到4KB。但是x86-64内核必须对齐到2MB，所以出了问题。
修改办法为，添加编译参数，强制2M。
在arch/x86/Makefile中添加如下补丁

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 498c1b8123006..1c4d012550ec5 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -223,6 +223,15 @@ KBUILD_CFLAGS += $(cfi) $(cfi-sigframe) $(cfi-sections) $(asinstr) $(avx_instr)LDFLAGS := -m elf_$(UTS_MACHINE)+ifdef CONFIG_X86_64
+LDFLAGS += $(call ld-option, -z max-page-size=0x200000)
+endif
+# Speed up the buildKBUILD_CFLAGS += -pipe# Workaround for a gcc prelease that unfortunately was shipped in a suse release

在arch/x86/boot/compressed/misc.cz中添加检查

--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -309,6 +309,10 @@ static void parse_elf(void *output)switch (phdr->p_type) {case PT_LOAD:
+#ifdef CONFIG_X86_64
+          if ((phdr->p_align % 0x200000) != 0)
+              error("Alignment of LOAD segment isn't multiple of 2MB");
+#endif#ifdef CONFIG_RELOCATABLEdest = output;dest += (phdr->p_paddr - LOAD_PHYSICAL_ADDR);

binutils包里有什么？
ld,as,strip,ojbcopy,readelf等
GNU_Binutils