In an Android Bootloader ostree deployment, we use system_a partition as the sole root partition. We have a /boot directory remaining which acts as a fake /boot partition. This is useful so ostree can store it's metadata in BLS format among other things. It helps integrate with our existing tooling which assume grub+BLS essentially.
As an advantage we save some space in system_a partition, and Android Bootloader deployments look more like a UEFI system.
This new system_b/boot partition can be ext4 by default to align with our other UEFI platforms.
In order to use initoverlayfs, it stores initoverlayfs image files in a simple /boot partition, like initrd's cpio image files are stored.
On completion of this our aboot builds in CentOS Automotive SIG will build three files:
aboot.img (this already exists) for boot_a/boot_b partition.
root.img (this already exists) for system_a partition.
boot.img for system_b partition. (this is the new ext4 one, that holds /boot stuff)
In an Android Bootloader ostree deployment, we use system_a partition as the sole root partition. We have a /boot directory remaining which acts as a fake /boot partition. This is useful so ostree can store it's metadata in BLS format among other things. It helps integrate with our existing tooling which assume grub+BLS essentially.
As an advantage we save some space in system_a partition, and Android Bootloader deployments look more like a UEFI system.
This new system_b/boot partition can be ext4 by default to align with our other UEFI platforms.
In order to use initoverlayfs, it stores initoverlayfs image files in a simple /boot partition, like initrd's cpio image files are stored.
On completion of this our aboot builds in CentOS Automotive SIG will build three files:
aboot.img (this already exists) for boot_a/boot_b partition. root.img (this already exists) for system_a partition. boot.img for system_b partition. (this is the new ext4 one, that holds /boot stuff)