RFC: Braindump on Bootloaders, Image Types, and Installers

DISCUSSION Darren Hart 6 participants 9 messages Jun 5, 2012 – Jun 9, 2012

Share & tools

Darren Hart

author

2012-06-05 21:07 UTC #0 lore raw

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.

Signature · 3 lines

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

Burton, Ross

2012-06-06 12:50 UTC #1 lore raw

Hi,

Quoted 5 lines · Darren Hart

* 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

Darren Hart

author

2012-06-06 16:40 UTC #2 lore raw

Quoted 9 lines · Ross

Hi,
Quoted 5 lines · Darren Hart
* 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.

Quoted 5 lines

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,

Signature · 3 lines

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

Mark Hatle

2012-06-06 16:57 UTC #3 lore raw

In reply to Darren Hart

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

Quoted 91 lines · 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

Koen Kooi

2012-06-07 16:21 UTC #4 lore raw

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

Quoted 7 lines

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

Quoted 103 lines

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
Quoted 80 lines · 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.
Quoted 11 lines
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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Saul Wold

2012-06-08 06:27 UTC #5 lore raw

Quoted 5 lines · Koen Kooi

Op 6 jun. 2012, om 18:47 heeft Mark Hatle het volgende geschreven:
Quoted 2 lines
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.

Quoted 8 lines

Quoted 5 lines
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!

Quoted 117 lines

I really like the idea of revamping the whole processes inbetween having packages and making an image out of them.
regards,
Koen
Quoted 99 lines
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
Quoted 80 lines · 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.
Quoted 11 lines
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
Quoted 4 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Koen Kooi

2012-06-08 07:48 UTC #6 lore raw

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

Quoted 10 lines · Koen Kooi

Quoted 9 lines
Op 6 jun. 2012, om 18:47 heeft Mark Hatle het volgende geschreven:
Quoted 6 lines
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.

Quoted 7 lines

Quoted 4 lines
Quoted 1 line
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

Darren Hart

author

2012-06-09 00:01 UTC #7 lore raw

In reply to Mark Hatle

Restoring the CC list.

Quoted 12 lines · 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.

Quoted 6 lines

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.

Signature · 3 lines

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

Anders Darander

2012-06-07 07:05 UTC #8 lore raw

In reply to Darren Hart

Quoted 5 lines · Darren Hart

* 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

Signature · 2 lines

Anders Darander
ChargeStorm AB / eStorm AB