Re: Providing (armhf) u-boot images together with d-i images?
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:
> > As full images need a bit of
> > space, the idea of providing concatenateable images instead of
> > full images came up, but doing that is dependent on solving the
> > "one boot script for all platforms" issue, for which we do not
> > yet have a proper solution, therefore I implemented that as an
> > option for testing this approach.
>
> Does using the extlinux.conf stuff (mentioned in my reply to Vagrant)
> help here?
Not sure - it might if we can solve the console issue (see below).
> > > 0004-Add-SD-card-image-build-support-for-hd-media-builds-.patch
> > >
> > > I don't think we need all of (.gz|.bz2|.xz) (like the README
> > > suggests, although it's not clear these are all actually
> > > present). Just one would do IMHO.
> >
> > Only the gzipped variant is actually built, the README just
> > covers the possible options (when calling gen-hd-image with
> > -z/-j/-J).
>
> This README is installed in the output directory, I think? IMHO it
> should document only the compression type actually used in that
> directory and we should provide at most one version of each file (either
> compressed or not) using a single consistent compression algorithm for
> all such files.
We do provide only one version of each file.
> 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.
> > 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).
> > > 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?
If the former, using pxelinux.cfg should indeed work everywhere; if the
latter, we would have to keep using boot.scr for Jessie.
> > 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.
> (Do your patches end up adding the correct Built-Using on u-boot?)
No, they don't, but d-i does not do that for similar components
on other platforms (syslinux/isolinux/grub) as well. Probably we
should do that, but then it would have to be done for all
platforms. Kibi?
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: