Re: Compressed kernels currently won't boot

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2019-07-31 at 10:50 -0700, James Bottomley wrote:
> On Wed, 2019-07-31 at 19:30 +0200, Sven Schnelle wrote:
> > Hi,
> > 
> > On Wed, Jul 31, 2019 at 09:44:03AM -0700, James Bottomley wrote:
> > > I noticed this trying to test out compressed kernel booting.  The
> > > problem is that a compressed kernel is divided into two pieces,
> > > one
> > > of which starts at 0x000e0000 and is the bootstrap code which is
> > > uncompressed into 0x00100000 and the rest of which is the real
> > > compressed kernel which is loaded above the end of the current
> > > decompressed size of the entire kernel.  palo decompresses the
> > > head
> > > and jumps to it and it then decompresses the rest of the kernel
> > > into place.  This means that the first part of the compressed
> > > image
> > > can't be larger than 0x20000 == 131072 because otherwise it will
> > > be
> > > loaded into an area that decompression will alter.
> > > 
> > > The problem is that a change was introduced by 
> > > 
> > > commit 34c201ae49fe9e0bf3b389da5869d810f201c740
> > > Author: Helge Deller <deller@gmx.de>
> > > Date:   Mon Oct 15 22:14:01 2018 +0200
> > 
> > Hmm. This is what i've been facing as well.
> 
> Yes, except you're a more extreme case than me ... you actually have
> the compressed segment overlapping the end of the decompressed text. 
> that does seem to mean we have a lot of no-load debug information
> which
> isn't useful to the compressed image.
> 
> >  After reading this commit i'm not sure that the patch i've just
> > sent ("parisc: strip debug information when building compressed
> > images") is really wanted. However, it is really a pain to always
> > copy huge lifimages around when booting parisc machines via LAN.
> > Does someone really extract the vmlinux file from a compressed
> > kernel images? Should we keep that?
> 
> Well, it's a thing.  There's a script in the kernel source tree
> 
> scripts/extract-vmlinux
> 
> that does it.  It doesn't seem to be packaged by debian, though.

What about causing the compressed make to build both a stripped and a
non-stripped bzImage (say sbzImage and bzImage).  That way you always
have the stripped one available for small size things like boot from
tape or DVD?  but in the usual case we use the bzImage with full
contents.

James