Re: Booting uncompressed kernel images
On Mon, 2016-02-01 at 10:06 +0000, Ian Campbell wrote:
> On Mon, 2016-02-01 at 06:03 -0200, Tiago Ilieve wrote:
> > Hi,
> >
> > I have a scenario[1] where the default Linux kernel compressed with XZ
> > (from Jessie and up) cannot be booted. The first thing that I've tried
> > was to uncompress it using "extract-linux"[2] and it didn't worked by
> > the time, so I decided to rebuild the entire "linux-image-*" package
> > changing "CONFIG_KERNEL_XZ=y" to "CONFIG_KERNEL_GZIP=y". This, of
> > course, implies that it would be needed to recompile the kernel every
> > time a new version of the package is released, which is an overkill
> > for a such simple requirement.
> >
> > Yesterday, Ben Hutchings itself suggested[3] me to write a hook that
> > decompresses the kernel at package installation time, something which
> > I find a great idea. The problem is that, again, I couldn't boot a
> > machine (tried on VirtualBox and Xen) after uncompressing its
> > "/boot/vmlinuz-*" using "extract-linux".
>
> What does file(1) say about the resulting file? It should be a plain ELF
> file of some sort.
>
> I wouldn't expect such a kernel to be bootable by very much other than
> Xen
> PV. It won't work as native for sure, nor as Xen HVM.
>
> > I can generate an initrd file
> > from this uncompressed image, "update-grub" detects it fine, but if I
> > reboot it the following error appears:
> >
> > Loading Linux 3.16.0-4-amd64 ...
> > error: invalid magic number.
> > Loading initial ramdisk ...
> > error: you need to load the kernel first.
>
> Is this booting via pvgrub[1], if not then do you know how? What does the
> grub.cfg stanza look like?
Hrm, that "invalid magic number" message is from upstream grub2, native
code paths, AFAICT.
Were you trying to boot this kernel natively? Or are the guests on Oracle
HVM ones (in which case the compression shouldn't matter, since the kernel
native boot path will take care of it).
>
> > - Is "extract-linux" stripping some essential information (the script
> > looks for an offset to start the decompression process) from the
> > kernel image that is needed to boot it later? If so, is there a way to
> > recover and insert it on the uncompressed image?
>
> It should just be the raw ELF file payload form the bzImage. Xen requires
> some particular ELF notes to be present, but I very much doubt extract-
> linux would be stripping those (since that would involve diving into the
> contents of the payload)
>
> Ian.
>
> [1] http://wiki.xen.org/wiki/PvGrub
>
>
>
> >
> > Regards,
> > Tiago.
> >
> > [1]: https://lists.debian.org/debian-cloud/2016/01/msg00052.html
> > [2]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/pl
> > ai
> > n/scripts/extract-vmlinux
> > [3]: https://lists.debian.org/debian-cloud/2016/01/msg00060.html
> > [4]: http://www.he1ix.org/2015/01/creating-a-xen-domu-on-debian-squeeze
> > -6
> > -0-6/
> > [5]: http://noone.org/blog/English/Computer/Debian/Running%20a%20Sid%20
> > Do
> > mU%20on%20a%20Squeeze%20Dom0.html
> >
>
>
Reply to: