> Hi, > > I have met an issue during loading a new kernel with Kexec on an ARMv5 SoC. The kernel is a 4.19 with Gzip compression but during loading Kexec does not recognize the compression. > > If I load the new kernel and dtb with: > > kexec -l /boot/zImage -d --dtb=/boot/u-boot.dtb > > The output is: > > Try gzip decompression. > Try LZMA decompression. > lzma_decompress_file: read on /boot/zImage of 65536 bytes failed > kernel: 0xb6a68008 kernel_size: 0x494d30 > MEMORY RANGES > 0000000000000000-000000000fffffff (0) > zImage header: 0x016f2818 0x00000000 0x00494d30 > zImage size 0x494d30, file size 0x494d30 > kexec_load: entry = 0x8000 flags = 0x280000 > nr_segments = 2 > segment[0].buf = 0xb6a68008 > segment[0].bufsz = 0x494d30 > segment[0].mem = 0x8000 > segment[0].memsz = 0x495000 > segment[1].buf = 0x1fcf060 > segment[1].bufsz = 0x245b > segment[1].mem = 0x16f2000 > segment[1].memsz = 0x3000 > > Looking at the debug, the function gzdirect returns “1” which indicates the kernel compression is not of gzip but I > definitely use gzip. > I also tested it with LZMA compression and uImage instead of zImage but all with the same outcome. > > To be complete, I use Kexec-tools 2.0.19 and zlib 1.2.11. > > Did I implement something wrong or how can I debug this further? > > Kind regards, > > Maikel Coenen Did some more testing and as far as I can see, it tries to decompress the kernel before removing the decompressing stub and header of the zImage/uImage. Therefore, it is not able to find the magic numbers of a gzip file at the beginning of the file. Function gz_look, called from gzdirect at zlib_decompress_file, checks the first byte of the stream to be equal to 31 and the second equal to 139. Because it did not strip the header, the first and second byte are 39 and 5. These are the first bytes of the uImage. _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
