Re: arm64: Image vs. Image.gz
On Fri, Feb 03, 2017 at 12:00:54PM +0000, Riku Voipio wrote:
> On Wed, Feb 01, 2017 at 01:35:40PM -0800, Vagrant Cascadian wrote:
> > So, when building an arm64 linux package using Debian's packaging, it
> > builds a package where /boot/vmlinuz-VERSION is uncompressed, and
> > bootloaders such as u-boot can boot it with booti.
>
> > But when building a mainline kernel with "make bindeb-pkg" it produces a
> > package where /boot/vmlinuz-VERSION is compressed with gzip, and
> > u-boot's booti fails to boot it. Simply uncompressing the
> > /boot/vmlinuz-VERSION then allows u-boot's booti command to work
> > properly.
>
> Since it already breaks with "failed magic" error, I think adding support
> for detecting gzip magic would not be very hard?
Mabye this will help?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831003
> > I seem to recall a similar issue with grub not booting the compressed
> > image, but it's been a while since I've tried.
>
> grub has a gzip module, which may or may not get included the grub that
> get installed in grubaa64.efi. We should mae sure it happens.
It does, and that's enough to support compressed kernels on EFI
platforms. Although, if we switch, we need to make sure it gets
included in d-i as well, since it generates its own image.
-dann
> > Are there platforms on arm64 that use Image.gz?
>
> > Should upstream default to "Image" instead, or should upstream's
> > bindeb-pkg target default arm64 builds to use KBUILD_IMAGE=Image, to be
> > consistant with Debian's linux packages?
>
> Personally I'd like to see compressed kernels by default (because they are
> so yuge). But for now, as no bootloader really works out of box with compressed
> images, deb-pkg/bindeb-pkg should match what Debian is doing.
>
> Riku
>
Reply to: