Bug#704571: support for multiple kernel versions in binary
Excerpts from jnqnfe's message of Fri Feb 13 20:31:13 +0100 2015:
>
> On 13/02/2015 14:08, Michal Suchanek wrote:
> > the build still fails when multiple kernel flavours are installed and
> > multiple kernels of the same flavour are installed. Live-build contains
> > this code:
> > mv binary/${_INITRAMFS}/vmlinuz-*-${_FLAVOUR} binary/${_INITRAMFS}/vmlinuz${_NUMBER}
> > Obvoiusly, in case vmlinuz-*-${_FLAVOUR} expands to multiple files
> > this command fails.
>
> I have just recently completed a large chunk of work improving the
> existing bootloader code in live-build. You will find an archive
> containing a set of 73 commits attached to the last post of bug #775322
> (which I used for tracking this work).
>
> While I have not specifically tackled support for multiple versions of
> the same kernel flavour (perhaps you could actually help me understand
> the use case for this), I have improved the piece of code you refer to
> here, which now applies the same logic as when a single kernel flavour
> is requested (using only the latest version for each flavour).
The use case is that when a particular kernel version does not boot on a
particular piece of hardware you can try a different version.
Specifically, using an upstream kernel version from experimental often
allows using more graphics cards but in wheezy I had this problem that
on a particular PC model the network card would work (at least
partially) only with the stable kernel and not the git snapshot with
overlayfs patches I used as alternate.
So now my plan is to use the stable Jessie kernel with experimental
trunk kernel as alternate so that I get better hardware coverage and
overlayfs testing.
Thanks
Michal
Reply to: