Re: Providing (armhf) u-boot images together with d-i images?
On Fri, 2015-01-02 at 14:51 +0100, Karsten Merker wrote:
> On Fri, Jan 02, 2015 at 10:46:37AM +0000, Ian Campbell wrote:
> > On Wed, 2014-12-31 at 01:59 +0100, Karsten Merker wrote:
>
> > Talking about other compression schemes or providing multiple versions
> > of the same file will just confuse users. It looks like someone has
> > commented on the duplicated concat examples in v3 too.
>
> Ok, I'll change the wording for V4. My intention was to provide a
> generic README that works regardless of which compression options
> one chooses in the makefile, so that switching from .gz to .xz
> would be simple without having to think of updating documentation
> elsewhere.
>
> If I now change the README to explicitly mention only one
> compression type, on which one shall we settle for all installer
> images on armhf? Everything compressed by gzip or by xz? As
> usual, this is a trade-off between compression ratio, CPU cycles
> and memory requirements on the build hosts.
I'd say go for gzip for maximum compatibility, e.g. for people making
images from Windows.
> > > The previous patch produces hd-media builds for use with CD/DVD
> > > iso images (equivalent to the i386/amd64 hd-media
> > > boot.img.gz). This patch produces a netboot SD card (equivalent to
> > > the i386/amd64 netboot mini.iso), plus a netboot.tar.gz which
> > > contains everything needed to be put onto a tftp server for
> > > tftp-booting the installer (equivalent to the i386/amd64
> > > PXE netboot.tar.gz).
> >
> > netboot.tar.gz sounds fine. What I don't get (see my reply to Vagrant)
> > is what the practical difference to the user is between the hd-media
> > builds and the netboot "mini.iso" ones, given that for ARM each is just
> > an sd-card image.
>
> The netboot and hd-media versions contain different installer
> builds - the list of udebs in them and the order of the udebs
> being executed is different between the two (see
> http://d-i.alioth.debian.org/doc/internals/ch02.html). The
> netboot image has to have network access to work, it loads all
> additional udebs it needs and all regular packages from the
> network. The hd-media one is for installing from local media and
> can work completely offline. This distinction is made on all
> platforms supported by d-i and unifying those two does not seem
> to work (sorry, I do not remember the details; IIRC it had
> something to do with different and conflicting anna
> implementations for the two variants).
Got it, thanks (I had a question in my reply to Vagrant, I won't repeat
it here).
> > > > For the tftpboot part, u-boot supports standard pxelinux.cfg
> > > > syntax configuration files -- would it be better to just
> > > > generate a suitable one of those?
> > >
> > > I have not in detail checked the pxelinux.cfg support in u-boot
> > > yet, but as we unfortunately have to build special-casing into the
> > > boot script for several platform (such as the i.MX6 console
> > > baudrate issue), I do not see how to implement that with the
> > > pxelinux.cfg syntax. Pointers welcome :).
> >
> > IMHO we should be moving towards using this way of doing things, which
> > might mean fixing things like the i.MX6 issue at source. Too late for
> > Jessie of course.
> >
> > BTW our kernel now supports the /chosen/stdout-path property in fdt and
> > will automatically put a console on it.
>
> Just to make sure that I understand that correctly: with the
> u-boot and kernel versions currently in Jessie, there is no need
> to ever pass a console parameter to the kernel on any platform?
> Or is this something that was introduced after the u-boot v2014-10
> release in Jessie?
/chosen/stdout-path is more a function of the kernel and the dtb, I
don't think u-boot is involved much at all, at it need not be. I suppose
on platforms where there is a choice of consoles it might auto update
the stdout-path to reflect where u-boot is outputting it's stuff, but
you'll get some sort of sane default for the platform either way
(assuming the dtb is sane).
> If the former, using pxelinux.cfg should indeed work everywhere; if the
> latter, we would have to keep using boot.scr for Jessie.
I think it's the former.
> > > Inside the existing hd-media and netboot directories, a
> > > subdirectory "SD-card-images" gets created, which then contains
> > > the created images. These have the following sizes:
> > >
> > > option "netboot full image":
> > > 18568 A10-OLinuXino-Lime.img.gz
> > > 18572 A20-OLinuXino-Lime.img.gz
> > > 18572 BananaPi.img.gz
> > > 18640 BeagleBoneBlack.img.gz
> > > 18572 Cubieboard2.img.gz
> > > 18568 Cubieboard.img.gz
> > > 18572 Cubietruck.img.gz
> > > 18564 MX53LOCO.img.gz
> > > 18568 MX6_Cubox-i.img.gz
> > > 18560 PandaBoard.img.gz
> > > 18552 Wandboard_Quad.img.gz
> > >
> >
> > So around 200M in total? I haven't checked but I would imagine that was
> > an order of magnitude more than d-i produces for any other arch in the
> > d-i builds.
>
> As I wrote in my previous mail, we could squash that down to
> 18M once + ~200kB per platform if we manage to unify the boot
> process (be it with an appropriate boot.scr or with using
> the pxelinux.cfg infrastructure) by using the concatenateable
> images instead of the full ones.
The downside there is more complexity for the end user though. I'm not
in charge of mirrors etc so it's not really me to say, the point I tried
to make in the following paragraph was that you ought to check with
those who deal with this infra if 200M here is ok or not. If they say no
the decision is made for you.
Ian.
Reply to: