Re: Providing (armhf) u-boot images together with d-i images?
On Tue, 2014-12-30 at 13:42 -0800, Vagrant Cascadian wrote:
On 2014-12-30, Ian Campbell wrote:
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.
I thought these were being copied into the output dir, rather than (or
as well as) being encapsulated into the image, doing the latter is fine.
Sounds like I misread the patch and it is infact only doing the latter.
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.
But what is the difference between these two things in this context?
Aren't they functionally identical from the users perspective?
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...
pxelinux.cfg stanzas can include an fdtdir directory which is a path
which u-boot will search for ${fdtfile} under.
This isn't terribly well documented, but
http://patchwork.ozlabs.org/patch/423507/ improves things a lot.
Speaking of which, does the extlinux.conf stuff (which also supports
fdtdir) help with the multiple images problem at all?
extlinux.conf (and pxelinux.conf) also has the advantage over boot.scr
that it can offer multiple options (graphical vs text etc etc).
I also think more systems support booting boot scripts than u-boot's
PXE emulation at this point.
That's true.
Going forward we should try and make it our default option though I
think -- it was basically put together this way by the Fedora guys to
support exactly this sort of scenario.
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:
1 u-boot only for each supported platform
2 hd-media full with u-boot + kernel + initrd + dtbs + bootscript for
each platform
3 hd-media concatenateable with kernel + initrd + dtbs + bootscript
4 netboot full with u-boot + kernel + initrd + dtbs + bootscript for
each platform (like mini.iso)
5 netboot concatenateable with kernel + initrd + dtbs + bootscript
6 netboot boot script for use with TFTP
(I've switched your bullets to numbers for ease of reference).
Are 2+4 and 3+5 not essentially the same things with different names (on
x86 the distinction is iso image vs a f/s image, but on ARM both are
sd-card images).
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 so much worried about concatenatable vs non as netboot vs
hd-media, but perhaps I just haven't grokked the difference.
Ian.
--
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
Re: Providing (armhf) u-boot images together with d-i images?
On 2015-01-02, Ian Campbell wrote:
On Tue, 2014-12-30 at 13:42 -0800, Vagrant Cascadian wrote:
On 2014-12-30, Ian Campbell wrote:
I think the difference is one is a set of netboot images, and the other
is a set of hd-media images.
But what is the difference between these two things in this context?
Aren't they functionally identical from the users perspective?
Differnt initrd with different modules, and defaults to loading a
different set of udebs. The hd-media scans for .iso files, the netboot
initrd requires to download remaining udebs using network...
Technically, both images could be made to do either based on bootprompt
options or something, but that probably would require rewriting a bit
more of d-i.
pxelinux.cfg stanzas can include an fdtdir directory which is a path
which u-boot will search for ${fdtfile} under.
This isn't terribly well documented, but
http://patchwork.ozlabs.org/patch/423507/ improves things a lot.
Thats really helpful, thanks!
Speaking of which, does the extlinux.conf stuff (which also supports
fdtdir) help with the multiple images problem at all?
...
extlinux.conf (and pxelinux.conf) also has the advantage over boot.scr
that it can offer multiple options (graphical vs text etc etc).
I don't think so, as netboot/hd-media are different images entirely. I
guess you could conceptually make one image with both initrds, and you
could use the menu support to select between the initrds... not sure if
that's worth doing at the moment.
I also think more systems support booting boot scripts than u-boot's
PXE emulation at this point.
That's true.
Going forward we should try and make it our default option though I
think -- it was basically put together this way by the Fedora guys to
support exactly this sort of scenario.
Seems reasonable. I'll add it to the increasing list of features I want
to get into u-boot for Jessie+1...
1 u-boot only for each supported platform
2 hd-media full with u-boot + kernel + initrd + dtbs + bootscript for
each platform
3 hd-media concatenateable with kernel + initrd + dtbs + bootscript
4 netboot full with u-boot + kernel + initrd + dtbs + bootscript for
each platform (like mini.iso)
5 netboot concatenateable with kernel + initrd + dtbs + bootscript
6 netboot boot script for use with TFTP
(I've switched your bullets to numbers for ease of reference).
Are 2+4 and 3+5 not essentially the same things with different names (on
x86 the distinction is iso image vs a f/s image, but on ARM both are
sd-card images).
They're both typically used with sd-card, yes. But they differ in how
they load the remaining portions of the installer, and have different
modules and udebs in the initrds appropriate to the install
media. Hopefully that's clear now? :)
live well,
vagrant
signature.asc
Description: PGP signature
Re: debian-cd in Git
On Fri, 2015-01-02 at 23:56 +, Steve McIntyre wrote: On Sat, Jan 03, 2015 at 11:54:11AM +1300, Philip Charles wrote: Hi, Would it be possible to upload to Git a version of debian-cd that can handle jessie? Hi Phil, How do you mean? We're building jessie stuff every day from git master. Is there something in particular that's broken for you? Thanks muchly. I have been downloading the nightly snapshot - it must be out of date as it is version 3.1.13 and the last date in the change log is 30 April 2013. I will have to do Git properly. FYI, I have apt-usb-add and installing extra packages from a stick working. Phil. -- Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand +64 3 488 2818Fax +64 3 488 2875Mobile 027 663 4453 phil...@copyleft.co.nz - personal.i...@copyleft.co.nz - business -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1420253178.1617.5.ca...@copyleft.co.nz
Re: debian-cd in Git
On Sat, Jan 03, 2015 at 03:46:18PM +1300, Philip Charles wrote: On Fri, 2015-01-02 at 23:56 +, Steve McIntyre wrote: How do you mean? We're building jessie stuff every day from git master. Is there something in particular that's broken for you? Thanks muchly. I have been downloading the nightly snapshot - it must be out of date as it is version 3.1.13 and the last date in the change log is 30 April 2013. Ummm, what nightly snapshot are we talking here? You've lost me...! :-) I will have to do Git properly. FYI, I have apt-usb-add and installing extra packages from a stick working. Yay! -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150103025410.gg21...@einval.com
Starbucks Newsroom Notification: Starbucks Launches Teavana Hot Brewed Teas in Starbucks Stores in the U.S. and Canada
The following is new content from the Starbucks Newsroom:\r\n\r\n Starbucks Launches Teavana Hot Brewed Teas in Starbucks Stores in the U.S. and Canada [http://news.starbucks.com/news/teavana-hot-brewed-teas-in-starbucks-stores]\r\n \r\n To unsubscribe from this mailing or update your notification preferences, please visit [http://news.starbucks.com/alerts/unsubscribe/debian-cd@lists.debian.org].\r\n\r\n We've contacted you because you registered at [http://news.starbucks.com] for news and alerts - or you have otherwise opted in to receive email from Starbucks Newsroom. Your address is listed as debian-cd@lists.debian.org. Please let us know if you wish to unsubscribe from this list.\r\n\r\n This email is sent from an account we use for sending messages only. So if you want to contact us, don't reply to this email - we won't get your response. Instead, email pr...@starbucks.com or mail your comments to PO Box 34067, Seattle, WA 98124-1067.\r\n\r\n Copyright 2015 Starbucks Corporation. All rights reserved.
Re: debian-cd in Git
On Sat, Jan 03, 2015 at 11:54:11AM +1300, Philip Charles wrote: Hi, Would it be possible to upload to Git a version of debian-cd that can handle jessie? Hi Phil, How do you mean? We're building jessie stuff every day from git master. Is there something in particular that's broken for you? -- Steve McIntyre, Cambridge, UK.st...@einval.com Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150102235620.ge21...@einval.com
Re: Providing (armhf) u-boot images together with d-i images?
Karsten Merker mer...@debian.org (2015-01-02): (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? ISTR having proposed a patch to #700026 / #696418, but that wasn't commented upon. Mraw, KiBi. signature.asc Description: Digital signature
debian-cd in Git
Hi, Would it be possible to upload to Git a version of debian-cd that can handle jessie? Phil. -- Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand +64 3 488 2818Fax +64 3 488 2875Mobile 027 663 4453 phil...@copyleft.co.nz - personal.i...@copyleft.co.nz - business -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1420239251.1602.3.ca...@copyleft.co.nz
Re: Providing (armhf) u-boot images together with d-i images?
On Wed, 2014-12-31 at 01:59 +0100, Karsten Merker wrote: 0001-Add-boot-arm-u-boot-image-config.patch Seems fine. 0002-Provide-u-boot-binaries-for-armhf-systems-without-u-.patch I think this isn't actually publishing the u-boot binaries, but rather sd-card images with the u-boot inlined, is that right? Is there any use in shipping the raw binaries too? It provides both Sorry, I must have misread. 0003-Add-utils-gen-hd-image.patch I didn't review in detail, but perhaps the functionality of patch 0002 could be folded in? TBH I'm not sure what the distinction is between what 0002 does and what this script would produce (except I can see the script clearly has more functionality) It depends :-). gen-hd-image can provide different types of images - full images (SD card image including partition table, u-boot, kernel, initrd and dtbs) and concatenateable images, which is effectively a full image split up into a device-specific part (containing the partition table and u-boot) and a device-independent part (containing kernel, initrd and dtbs). If one decides to build concatenateable images, the device-specific part is mostly the same as the ready-to-copy SD card image generated by patch 2, with the difference that it contains a filled partition table with a predefined geometry and medium size. My original idea was to build u-boot-only images from patch 2 for people who want to install by TFTP or from USB-Stick using the existing hd-media tarball. This was the first thing I implemented. Vagrant proposed also building full images (u-boot, kernel, initrd and dtbs) similar to the images we build for i386/amd64, so I implemented that. 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? 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. 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. 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. The dtbs are only inside the generated images, they are not copied elsewhere as files. My mistake, I thought they were ending up unpacked in the output too. Having all of them inside the image is a necessity if we want to have the option of using concatenateable builds as in this case they are in the device-independent part. The size of the dtbs inside the image is less than 900kB, so I do not think that is much of an issue size-wise. Agreed. 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. 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
