RFC: Braindump on Bootloaders, Image Types, and Installers

RFC: Braindump on Bootloaders, Image Types, and Installers

[Darren Hart]

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.

As for boot loaders. In x86 land, we have syslinux, efilinux, grub, and
grub-efi. We use syslinux for the hddimg and grub after installation,
which accounts for some of the boot parameters being lost in the
transition. I feel we would benefit from unifying the bootloader across
image types and presenting a consistent interface. For the core, I plan
to adopt syslinux everywhere [6]. Syslinux supports ISO images, EXT
filesystems, FAT filesystems, and will support EFI soon enough. It also
has the option for a menu system and basic graphics. With this, we can
greatly improve the initial experience and keep that consistent across
the various image types, as well as after installation.

EFI merits a special note here. While working with an EFI enabled
system, it often makes sense to work from the EFI shell for a variety of
reasons. As such, packaging and including efibootmgr to manage boot
targets in the EFI firmware is something we should be providing in
addition to the common use case of a boot/install boot loader. Our
current EFI images frequently do not boot automatically, despite using
the "boot/EFI/boot[ARCH].efi" path for the payload as specified in the
EFI specification. This may be do to the media not being ready in time
(USB can be awfully slow). Some additional research is clearly necessary
to properly support EFI in our images, and likely some hacks to work
around buggy firmware [2]. We should be making friends with Matthew Gerrett.


References
[0] https://bugzilla.yoctoproject.org/show_bug.cgi?id=2426
[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1919
[2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1950
[3] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1763
[4] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1780
[5] https://bugzilla.yoctoproject.org/show_bug.cgi?id=2073
[6] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1635
[7] https://bugzilla.yoctoproject.org/show_bug.cgi?id=2343
[8] https://bugzilla.yoctoproject.org/show_bug.cgi?id=2064
[9] https://lists.yoctoproject.org/pipermail/yocto/2012-May/008633.html
-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: RFC: Braindump on Bootloaders, Image Types, and Installers

[Burton, Ross]

Hi,

On 5 June 2012 21:54, Darren Hart <dvhart@linux.intel.com> wrote:
>  * 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.

Can we get an option to specify the size of the target device?  I've a
4GB stick that I'm using with .hddimg (being the lucky owner of a box
that actually boots them!) and it's sad to see the rootfs being only a
little bigger than the contents when there is about 3.5G of empty disk
space available.

Ross

Re: RFC: Braindump on Bootloaders, Image Types, and Installers

[Darren Hart]

On 06/06/2012 05:39 AM, Burton, Ross wrote:
> Hi,
> 
> On 5 June 2012 21:54, Darren Hart <dvhart@linux.intel.com> wrote:
>>  * 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.
> 
> Can we get an option to specify the size of the target device?  I've a
> 4GB stick that I'm using with .hddimg (being the lucky owner of a box
> that actually boots them!) and it's sad to see the rootfs being only a
> little bigger than the contents when there is about 3.5G of empty disk
> space available.

I believe this is a better fit for the diskimage type with proper
partitions. I don't have data regarding performance of a loop mounted
filesystem versus a proper block device, but my gut feel is that using
block devices for large partitions will provide a better experience.

If we did want to allow for the use of the entire disk, we should find a
way to do so without bloating the image files themselves with empty
filesystem space. Does anyone know if we can use sparse files to
accomplish this with rootfs.img?

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: RFC: Braindump on Bootloaders, Image Types, and Installers

[Mark Hatle]

I don't have specific comments below, but I can share some of what I will be 
working on for my company in the next 6 months or so.

I will be working on moving the image generation: filesystem construction, 
filesystem -> image generation, and similar into a framework that can reside 
externally of OE-core/bitbake.

The idea is that we should have a single framework that can construct the 
filesystem from the package feeds, construct the images (using the parameters 
and more that you list below), and then eventually deploy these images onto the 
target system.

Having this external of oe-core will allow it to be invoked by OE-core, as it is 
today, as well as for on-target installers, people who want to start w/ the 
package feeds, etc.

I believe this fits within the vision you have below, but may throw in some 
issues when we start talking about external capable tooling.

--Mark

On 6/5/12 3:54 PM, Darren Hart wrote:
> 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.
>
> As for boot loaders. In x86 land, we have syslinux, efilinux, grub, and
> grub-efi. We use syslinux for the hddimg and grub after installation,
> which accounts for some of the boot parameters being lost in the
> transition. I feel we would benefit from unifying the bootloader across
> image types and presenting a consistent interface. For the core, I plan
> to adopt syslinux everywhere [6]. Syslinux supports ISO images, EXT
> filesystems, FAT filesystems, and will support EFI soon enough. It also
> has the option for a menu system and basic graphics. With this, we can
> greatly improve the initial experience and keep that consistent across
> the various image types, as well as after installation.
>
> EFI merits a special note here. While working with an EFI enabled
> system, it often makes sense to work from the EFI shell for a variety of
> reasons. As such, packaging and including efibootmgr to manage boot
> targets in the EFI firmware is something we should be providing in
> addition to the common use case of a boot/install boot loader. Our
> current EFI images frequently do not boot automatically, despite using
> the "boot/EFI/boot[ARCH].efi" path for the payload as specified in the
> EFI specification. This may be do to the media not being ready in time
> (USB can be awfully slow). Some additional research is clearly necessary
> to properly support EFI in our images, and likely some hacks to work
> around buggy firmware [2]. We should be making friends with Matthew Gerrett.
>
>
> References
> [0] https://bugzilla.yoctoproject.org/show_bug.cgi?id=2426
> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1919
> [2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1950
> [3] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1763
> [4] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1780
> [5] https://bugzilla.yoctoproject.org/show_bug.cgi?id=2073
> [6] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1635
> [7] https://bugzilla.yoctoproject.org/show_bug.cgi?id=2343
> [8] https://bugzilla.yoctoproject.org/show_bug.cgi?id=2064
> [9] https://lists.yoctoproject.org/pipermail/yocto/2012-May/008633.html

Re: RFC: Braindump on Bootloaders, Image Types, and Installers

[Koen Kooi]

Op 6 jun. 2012, om 18:47 heeft Mark Hatle het volgende geschreven:

> I don't have specific comments below, but I can share some of what I will be working on for my company in the next 6 months or so.
> 
> I will be working on moving the image generation: filesystem construction, filesystem -> image generation, and similar into a framework that can reside externally of OE-core/bitbake.
> 
> The idea is that we should have a single framework that can construct the filesystem from the package feeds, construct the images (using the parameters and more that you list below), and then eventually deploy these images onto the target system.
> 
> Having this external of oe-core will allow it to be invoked by OE-core, as it is today, as well as for on-target installers, people who want to start w/ the package feeds, etc.

Chris Larson mentioned this idea during lunch at the last ELC. For angstrom we already put heavy emphasis on the narcissus tool for users to generate their images and lately I have been needing root permissions for various ext4 tweaks which oe-core/bitbake can't do (and really shouldn't).

I really like the idea of revamping the whole processes inbetween having packages and making an image out of them.

regards,

Koen

> 
> I believe this fits within the vision you have below, but may throw in some issues when we start talking about external capable tooling.
> 
> --Mark
> 
> On 6/5/12 3:54 PM, Darren Hart wrote:
>> 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.
>> 
>> As for boot loaders. In x86 land, we have syslinux, efilinux, grub, and
>> grub-efi. We use syslinux for the hddimg and grub after installation,
>> which accounts for some of the boot parameters being lost in the
>> transition. I feel we would benefit from unifying the bootloader across
>> image types and presenting a consistent interface. For the core, I plan
>> to adopt syslinux everywhere [6]. Syslinux supports ISO images, EXT
>> filesystems, FAT filesystems, and will support EFI soon enough. It also
>> has the option for a menu system and basic graphics. With this, we can
>> greatly improve the initial experience and keep that consistent across
>> the various image types, as well as after installation.
>> 
>> EFI merits a special note here. While working with an EFI enabled
>> system, it often makes sense to work from the EFI shell for a variety of
>> reasons. As such, packaging and including efibootmgr to manage boot
>> targets in the EFI firmware is something we should be providing in
>> addition to the common use case of a boot/install boot loader. Our
>> current EFI images frequently do not boot automatically, despite using
>> the "boot/EFI/boot[ARCH].efi" path for the payload as specified in the
>> EFI specification. This may be do to the media not being ready in time
>> (USB can be awfully slow). Some additional research is clearly necessary
>> to properly support EFI in our images, and likely some hacks to work
>> around buggy firmware [2]. We should be making friends with Matthew Gerrett.
>> 
>> 
>> References
>> [0] https://bugzilla.yoctoproject.org/show_bug.cgi?id=2426
>> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1919
>> [2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1950
>> [3] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1763
>> [4] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1780
>> [5] https://bugzilla.yoctoproject.org/show_bug.cgi?id=2073
>> [6] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1635
>> [7] https://bugzilla.yoctoproject.org/show_bug.cgi?id=2343
>> [8] https://bugzilla.yoctoproject.org/show_bug.cgi?id=2064
>> [9] https://lists.yoctoproject.org/pipermail/yocto/2012-May/008633.html
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: RFC: Braindump on Bootloaders, Image Types, and Installers

[Saul Wold]

On 06/07/2012 09:11 AM, Koen Kooi wrote:
>
> Op 6 jun. 2012, om 18:47 heeft Mark Hatle het volgende geschreven:
>
>> I don't have specific comments below, but I can share some of what I will be working on for my company in the next 6 months or so.
>>
>> I will be working on moving the image generation: filesystem construction, filesystem ->  image generation, and similar into a framework that can reside externally of OE-core/bitbake.
>>
>> The idea is that we should have a single framework that can construct the filesystem from the package feeds, construct the images (using the parameters and more that you list below), and then eventually deploy these images onto the target system.
>>
>> Having this external of oe-core will allow it to be invoked by OE-core, as it is today, as well as for on-target installers, people who want to start w/ the package feeds, etc.
>
> Chris Larson mentioned this idea during lunch at the last ELC. For angstrom we already put heavy emphasis on the narcissus tool for users to generate their images and lately I have been needing root permissions for various ext4 tweaks which oe-core/bitbake can't do (and really shouldn't).
>
Hmm, more info here, please.

I am looking at moving OE-Core to use ext4 by default, is there 
something that will break if we do that?  It seems like it's the right 
time to do that based on where maintenance and support of ext3 and ext4 are.

Sau!

> I really like the idea of revamping the whole processes inbetween having packages and making an image out of them.
>
> regards,
>
> Koen
>
>>
>> I believe this fits within the vision you have below, but may throw in some issues when we start talking about external capable tooling.
>>
>> --Mark
>>
>> On 6/5/12 3:54 PM, Darren Hart wrote:
>>> 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.
>>>
>>> As for boot loaders. In x86 land, we have syslinux, efilinux, grub, and
>>> grub-efi. We use syslinux for the hddimg and grub after installation,
>>> which accounts for some of the boot parameters being lost in the
>>> transition. I feel we would benefit from unifying the bootloader across
>>> image types and presenting a consistent interface. For the core, I plan
>>> to adopt syslinux everywhere [6]. Syslinux supports ISO images, EXT
>>> filesystems, FAT filesystems, and will support EFI soon enough. It also
>>> has the option for a menu system and basic graphics. With this, we can
>>> greatly improve the initial experience and keep that consistent across
>>> the various image types, as well as after installation.
>>>
>>> EFI merits a special note here. While working with an EFI enabled
>>> system, it often makes sense to work from the EFI shell for a variety of
>>> reasons. As such, packaging and including efibootmgr to manage boot
>>> targets in the EFI firmware is something we should be providing in
>>> addition to the common use case of a boot/install boot loader. Our
>>> current EFI images frequently do not boot automatically, despite using
>>> the "boot/EFI/boot[ARCH].efi" path for the payload as specified in the
>>> EFI specification. This may be do to the media not being ready in time
>>> (USB can be awfully slow). Some additional research is clearly necessary
>>> to properly support EFI in our images, and likely some hacks to work
>>> around buggy firmware [2]. We should be making friends with Matthew Gerrett.
>>>
>>>
>>> References
>>> [0] https://bugzilla.yoctoproject.org/show_bug.cgi?id=2426
>>> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1919
>>> [2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1950
>>> [3] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1763
>>> [4] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1780
>>> [5] https://bugzilla.yoctoproject.org/show_bug.cgi?id=2073
>>> [6] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1635
>>> [7] https://bugzilla.yoctoproject.org/show_bug.cgi?id=2343
>>> [8] https://bugzilla.yoctoproject.org/show_bug.cgi?id=2064
>>> [9] https://lists.yoctoproject.org/pipermail/yocto/2012-May/008633.html
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>

Re: RFC: Braindump on Bootloaders, Image Types, and Installers

[Koen Kooi]

Op 8 jun. 2012, om 08:16 heeft Saul Wold het volgende geschreven:

> On 06/07/2012 09:11 AM, Koen Kooi wrote:
>> 
>> Op 6 jun. 2012, om 18:47 heeft Mark Hatle het volgende geschreven:
>> 
>>> I don't have specific comments below, but I can share some of what I will be working on for my company in the next 6 months or so.
>>> 
>>> I will be working on moving the image generation: filesystem construction, filesystem ->  image generation, and similar into a framework that can reside externally of OE-core/bitbake.
>>> 
>>> The idea is that we should have a single framework that can construct the filesystem from the package feeds, construct the images (using the parameters and more that you list below), and then eventually deploy these images onto the target system.
>>> 
>>> Having this external of oe-core will allow it to be invoked by OE-core, as it is today, as well as for on-target installers, people who want to start w/ the package feeds, etc.
>> 
>> Chris Larson mentioned this idea during lunch at the last ELC. For angstrom we already put heavy emphasis on the narcissus tool for users to generate their images and lately I have been needing root permissions for various ext4 tweaks which oe-core/bitbake can't do (and really shouldn't).
>> 
> Hmm, more info here, please.
> 
> I am looking at moving OE-Core to use ext4 by default, is there something that will break if we do that?  It seems like it's the right time to do that based on where maintenance and support of ext3 and ext4 are.

tl;dr version: a real ext4 partition requires mkfs.ext4, genext2fs + tune2fs + fsck is flaky and won't give you the actual ext4 benefits.


Some background: my ext4 quest was started to make the system feel faster when using cheap kingston sd cards. I started out with thinking "ext4 is just ext2 with some extra bits", so I did the genext2fs + tune2fs thing:

case "${ROOTFSTYPE}" in
		ext3)
				genext2fs -z -N $FS_NUM_INODES -b $FS_SIZE_BLOCKS -d ${IMAGE_ROOTFS} ${LOOPDEV_FS}
				tune2fs -L ${IMAGE_NAME} -j ${LOOPDEV_FS}
				;;
		ext4)
				genext2fs -z -N $FS_NUM_INODES -b $FS_SIZE_BLOCKS -d ${IMAGE_ROOTFS} ${LOOPDEV_FS}
				tune2fs -L ${IMAGE_NAME} -j -O extents,uninit_bg,dir_index ${LOOPDEV_FS}
				;;
		*)
				echo "Please set ROOTFSTYPE to something supported"
				exit 1
				;;
esac

The above plays nice with bitbake and pseudo and according to all the wikis yields an ext4 system. And as a bonus the u-boot ext2 parser can load a uImage from it. It has however a few downsides:

1) you need to run fsck.ext4 to init the dir_index
  1a) fsck.extX is stupid and will not always treat that ext4 system as an ext4 system. If you have an fsck .conf file in /etc/ you've already lost. I had it working on my build machine, but after an update to e2fsprogs it stopped working, it only ran in ext2 mode. Ironically, the only systems that will reliably treat that partition as ext4 are my OSX systems where I compiled and installed e2fsprogs myself.
2) the big ext4 feature 'extents' will only work on files created *after* that fsck.

So you end up with an ext3 system that needs an fsck to actually work and has none of the ext4 features out of the box.

What I have been doing to get around this is totally screwed up:

The initial creation of the SD card:

* generate the multipartition image with OE
* mkfs.ext4 the second partition, erasing what OE put there with genext2fs + tune2fs
* tar xjf the rootfs.tar.bz2 to the second partition
* dd image to sd card

And for all the updated images the past few weeks:

* opkg update ; opkg upgrade on the target
* rm /mnt/loop/home/root/.[A-z]* /mnt/loop/etc/dropbear/* -rf on the host
* dd /dev/sdX | pv -s 3484M > sd.img

The only advantage of this is that upgrade paths must work and I never run into changes-without-PR-bump problems because the angstrom uploader filters out duplicate filenames before uploading. But for the rest: completely screwed up.

regards,

Koen

Re: RFC: Braindump on Bootloaders, Image Types, and Installers

[Darren Hart]

Restoring the CC list.

On 06/06/2012 09:47 AM, Mark Hatle wrote:
> I don't have specific comments below, but I can share some of what I will be 
> working on for my company in the next 6 months or so.
> 
> I will be working on moving the image generation: filesystem construction, 
> filesystem -> image generation, and similar into a framework that can reside 
> externally of OE-core/bitbake.
> 
> The idea is that we should have a single framework that can construct the 
> filesystem from the package feeds, construct the images (using the parameters 
> and more that you list below), and then eventually deploy these images onto the 
> target system.
> 
> Having this external of oe-core will allow it to be invoked by OE-core, as it is 
> today, as well as for on-target installers, people who want to start w/ the 
> package feeds, etc.
> 
> I believe this fits within the vision you have below, but may throw in some 
> issues when we start talking about external capable tooling.

I've been considering external tools to assemble images as well to keep
root permission requirements out of bitbake. This would greatly simplify
partitioning and loop mounting images. Preparing filesystem images in
bitbake, and bootable images outside of bitbake seems like a reasonable
approach to me as well.



-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: RFC: Braindump on Bootloaders, Image Types, and Installers

[Anders Darander]

* Darren Hart <dvhart@linux.intel.com> [120605 22:56]:
>   * 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.

Here it would also be nice to support an option to combine the kernel
and the initramfs in a post-process stage. Otherwise, there needs to be
some more, possibly complicated, changes to the workflow to make it
possible to build external kernel modules into the initramfs. Or to
explicitly state that this is an unsupported configuration. We're
currently looking into this, but we're currently heading for separate
kernel and initramfs, partly due to this.

Cheers,

/Anders

-- 
Anders Darander
ChargeStorm AB / eStorm AB

Re: RFC: Braindump on Bootloaders, Image Types, and Installers

[Daniel Lazzari]

>Date: Tue, 05 Jun 2012 13:54:14 -0700
>From: Darren Hart <dvhart@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@lists.openembedded.org>
>Cc: damien.lespiau@intel.com, "Wold, Saul" <saul.wold@intel.com>
>Message-ID: <4FCE71F6.3060001@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@leapfrog.com