[OE-core] RFC: Braindump on Bootloaders, Image Types, and Installers

[Daniel Lazzari]

>Date: Tue, 05 Jun 2012 13:54:14 -0700
>From: Darren Hart <dvhart at linux.intel.com>
>Subject: [OE-core] RFC: Braindump on Bootloaders, Image Types, and
>	Installers
>To: Patches and discussions about the oe-core layer
>	<openembedded-core at lists.openembedded.org>
>Cc: damien.lespiau at intel.com, "Wold, Saul" <saul.wold at intel.com>
>Message-ID: <4FCE71F6.3060001 at linux.intel.com>
>Content-Type: text/plain; charset=ISO-8859-1
>
>All,
>
>There has been a lot of discussion scattered across the lists and
>bugzilla regarding bootable image types. There are a variety of
>different situations, each with specific requirements. Our current set
>of image types are showing their age. Here I collect what I've seen in
>an attempt to start a consolidated discussion to help arrive at a clear
>vision of where we want to be, and to define tasks that we can
>distribute across various people. If you are on CC, I intend to include
>you in that list of people ;-)
>
>Current issues:
>* hddimg types fail to boot on many intel platforms [3]
>* USBZIP image creation is slow and not integrated into the bitbake
>  process
>* dosfstools is stuck at an old version to avoid requiring GPLv2 to
>  build images
>* no support for kernel+initramfs as a single blob [9]
>* can't create partitioned images as the tools require root access
>* hybrid ISO images are more universally bootable, but don't provide
>  persistent storage even on USB sticks.
>* different boot loaders are used on the live images and the installed
>  images
>* boot parameters are not preserved across installation [0]
>* the installer is very limited to where it can install
>* the installer doesn't work for EFI images [1]
>* the hddimg will load the first rootfs it finds, even if it isn't the
>  one on the hddimg boot media
>* the boot prompts are not self descriptive
>* EFI, PCBIOS, ISO all have subtly different boot requirements which
>  complicate the bootimg recipe and associated classes.
>* custom multi-partition images are not supported [4]
>* Can't build the image and the bootloader as different arches [5]
>* Various issues with unionfs [7] and chroot [8]
>
>... and that's just for x86...
>
>Where I envision images going:
>
>* Create the follwing image types:
>  * Live Installer
>    - this is the merger of hddimg, ISO, and ISOHYBRID
>    - non-persistent storage
>    - intended for demonstration and installation
>    - can be written directly to USB sticks or CDs
>  * Disk Image
>    - create partitioned images (not just volume images)
>    - intended to be written to USB sticks, MMC drives, or SATA disks
>    - may require a script to assemble the image for specific target
>      devices.
>  * Initramfs
>    - Linux kernel and initramfs as a single image
>    - this will require some significant workflow changes as images are
>      generated after the kernel and the kernel needs the rootfs to
>      build the combined image.
>

While we're on the topic, I would add that there's currently no easy way to generate multiple images using different mkfs arguments from the same image recipe. Our use case is that we have multiple boards with only a very slight difference, the NAND geometry. Because UBI and UBIFS need NAND geometry info when being generated, this means under the current system, we'd need 3 image recipes, each containing all of the same packages but having slightly different mkfs and ubinize arguments which is a major performance drawback because the rootfs has to be created for each final image. We've hacked together a solution in house, but if someone is looking at redesigning images, we'd love to see support for this.

Daniel Lazzari Jr
Firmware Engineer
LeapFrog, Inc
dlazzari at leapfrog.com