Control: severity -1 important
Control: retitle -1 armel kernel images are close to size limits
On Fri, 2014-12-12 at 19:36 +0000, Ian Campbell wrote:
> On Fri, 2014-12-12 at 18:12 +0000, Ben Hutchings wrote:
> > Package: src:linux
> > Version: 3.16.7-2
> > Severity: serious
> >
> > The kirkwood and orion5x kernel images generally have to be installed
> > in flash partitions with a fixed size. Currently we check at build
> > time that vmlinuz is small enough to fit. However, these platforms
> > now require Device Tree blobs, and the appropriate DTB must be
> > appended to the kernel image in flash since the boot loader won't load
> > it separately.
> >
> > The kirkwood machines with the smallest known kernel partition are
> > QNAP TS-119/TS-219, with 2097080 bytes space. We need to fit:
> >
> > -rw-r--r-- 1 ben ben 2094680 Nov 7 03:37 vmlinuz-3.16.0-4-kirkwood
> > -rw-r--r-- 1 ben ben 10394 Dec 9 04:57 kirkwood-ts219-6281.dtb
>
> We have not switched to dtb appending for the QNAP TS* platforms in
> Jessie. The board support still existed in v3.16 and we still use it.
OK.
> I had originally planned to switch QNAP over for 3.16 but it wasn't
> quite ready upstream (I've forgotten why). The board files went away in
> 3.17 so in experimental (v3.18) appending is necessary. Once I've worked
> out some kinks with kirkwood in v3.18 I was planning to upload a
> corresponding flash-kernel which does appending for those platforms.
In case you hadn't noticed, I've changed the size check in trunk so it
can optionally include the size of the largest DTB. That is somewhat
pessimistic in that the largest DTB probably won't be used in
conjunction with the smallest partition. I enabled this for both
kirkwood and orion5x, though now I think I should not have done so for
orion5x.
[...]
> > 2094680 < 2097080
> > 2094680 + 10394 = 2105074 > 2097080
> >
> > The orion5x machine with the smallest known kernel partition is D-Link
> > DNS-323, with 1572792 bytes space. We currently have less than 1 KB
> > to spare here. Thankfully this machine is still supported by board
> > code and doesn't need a DTB. But if any of the other orion5x machines
> > we intend to support have a similarly small kernel partition and
> > require a DTB they will not work with this version.
>
> I don't know much about orion5x, but the flash-kernel db tells me that
> we don't currently append a dtb on any platform there.
>
> 1k is rather tight though, even if appending isn't needed. A security
> update adding 1k of binary size wouldn't be totally out of the question
> and it would be unfortunate to have to start disabling features in a
> security update.
Yes, you're right. For comparison, this is what's happened over the
course of wheezy stable updates:
3.2.41-2 3.2.63-2 limit growth% growth limit%
iop32x: 1427968 1434632 1441784 0.47 0.97
ixp4xx: 1424696 1428920 1441760 0.30 1.20
kirkwood: 1606512 1613040 2097080 0.41 30.54
orion5x: 1475936 1483632 1572792 0.52 6.56
They've grown by up to about 0.5% over the course of 20 months of a ~36
month support period. That implies we want to allow for about 1% growth
from the size in the .0 release. Thankfully they did all start with
this much space.
Currently in sid we have:
3.16.7-ckt2-1 limit growth limit%
ixp4xx: 1429712 1441760 0.84%
kirkwood: 2094488 2097080 0.12%
orion5x: 1568248 1572792 0.29%
I misread earlier - kirkwood is about 2.5 KB below the limit, not < 1.
Anyway, both kirkwood and orion5x have much less than 1% of growth room
and ixp4xx has slightly less. I think that some of the config changes I
made in trunk should be applied to jessie/sid as well.
Ben.
--
Ben Hutchings
Kids! Bringing about Armageddon can be dangerous. Do not attempt it in
your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'
Attachment:
signature.asc
Description: This is a digitally signed message part