On 2014-12-30, Ian Campbell wrote:
> I should start by saying that I'm not personally particularly interested
> in this functionality, but I don't want to be a blocker for people who
> are so since I've been asked I'll give my 2pence...
Thanks for taking the time.
> I've been wondering if this image generation should be in debian
> installer or if it should be a separate project (similar to how
> debian-cd is separate).
I overall like the idea, all the parts (kernel, initrd, dtb) are already
shipped in d-i, and those that aren't (u-boot) are easy to depend
on. The bootscripts could still go into d-i, or this image generation
utility itself...
I would also hope that these images get shipped through some official
channel(like the .iso files produced by debian-cd), in a format that's
easy for the end-user to install, though. Not sure what it takes to make
that happen.
> 0004-Add-SD-card-image-build-support-for-hd-media-builds-.patch
...
> It seems to be creating a copy of dtbs again, please lets try
> and keep it to one set of these files in the top level
> component.
Well, all the dtb files need to be on the concatenateable images so that
simply dd'ing the right u-boot files onto the card will be able to
boot. If the image was only made for a specific system, then it would be
possible to only include the relevent dtb files.
> 0005-Add-SD-card-image-and-tftpboot-tarball-build-support.patch
>
> What is this providing? Is it a mini.iso like netboot sd image?
I think it is basically like the mini.iso on i386/amd64, yes.
> I'm not sure how this is different from what the previous
> patches introduced.
I think the difference is one is a set of netboot images, and the other
is a set of hd-media images.
> 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?
Boot scripts allow the use of ${fdtfile}. As far as I understand, the
pxelinux.cfg syntax unfortunately lacks the ability to use u-boot
variables, and thus requires a different pxelinux.cfg for each system
that uses a different .dtb. Which doesn't seem particularly useful for
a single config for network booting...
I also think more systems support booting boot scripts than u-boot's
"PXE" emulation at this point.
> I suppose my main overall concern is that this seems to be providing the
> same thing 3 or 4 times and I'm not sure what the difference between
> each of those things is (or perhaps as likely I've misunderstood what is
> going on somewhere along the line). I was already concerned about the
> proliferation of images which taking this approach was implying in
> general and adding a multiplier to that just makes me more
> uncomfortable.
If I'm reading it correctly(perhaps partly based on earlier descriptions
of the goal), there are several images produced:
* u-boot only for each supported platform
* hd-media full with u-boot + kernel + initrd + dtbs + bootscript for
each platform
* hd-media concatenateable with kernel + initrd + dtbs + bootscript
* netboot full with u-boot + kernel + initrd + dtbs + bootscript for
each platform (like mini.iso)
* netboot concatenateable with kernel + initrd + dtbs + bootscript
* netboot boot script for use with TFTP
The netboot/hd-media without u-boot are meant to be concatenated
together with the appropriate u-boot only images... so yes, there is
significant overlap between the image types.
The full images are obviously easier for the users to use, as it
requires writing a single image, but obviously proliferate the number of
images for each new supported platform.
The concatenateable images obviously save a lot of space, at the expense
of the user having to do additional steps and more complicated
documentation (and might be difficult on non-unix-like platforms?).
It probably doesn't make sense to ship both the concatenateable and full
images. I think Karsten wanted to enable both so that they could be
tested in the daily images, and then later pick which would ship with
Jessie?
I'm not attached to it all happening inside of debian-installer, just
hope that whatever's done makes it easy for the users to install debian
on some of these newish accessible low-power platforms...
live well,
vagrant
Attachment:
signature.asc
Description: PGP signature