Re: [gentoo-soc] GSoC 2017: Atom Gentoo

[Robin H. Johnson]

On Thu, Mar 30, 2017 at 02:57:21AM -0700, Huimin Zhang wrote:
> Atom Gentoo will have a build script that will generate a disk image,
> complete with bootloader, to be cloned to disks for deployment. I suspect
> BIOS is a lot more prevalent than UEFI for servers and virtualization so a
> BIOS bootloader will be default. The default kernel config should be
> tailored for virtualization.
The image-building part will probably already be very similar to the
OpenStack diskimage-builder tool, you can possibly benefit from that.

> Each installation of Atom Gentoo consists of two separate partitions for
> the root filesystem. Only one will be in use at a time, and the other will
> be used for upgrades. If an upgrade fails, the partially upgraded partition
> should be reset to be a copy of the other partition. If an upgrade
> succeeds, the unupgraded partition should copy the contents of the upgraded
> partition.
Why sticking to writable filesystems here? This could be treated via
block-level replication, with squashfs or read-only optimized
filesystems, and verified via dm-verity or similar, providing options
for verified boot.

I presume you were thinking of something like OverlayFS for the stateful
layer, but that could also be used for one or more application R/O
layers.

These ideas aren't new, look at how the OS is handled in Android &
ChromeOS, you'll see many of them together. Even Docker's container
build model is very similar to this.

> The logic for choosing which partition to boot and maintaining the two
> partitions will be handled in the init of initramfs, and the functionality
> of generating such an initramfs could be patched into genkernel.
As the genkernel author, there have been debates about replacing the
initramfs-generation portion with Dracut (which requires porting of some
of the existing initramfs functionality to Dracut) [this is probably a
GSOC project candidate as well, but it'll be a lot of work].

> For updates, Atom Gentoo can rsync from a server that was defined at build
> time. By using rsync the updates are diff-only instead of fetching the full
> image each time. This can run automatically in the background as a cronjob,
> updating the root partition not currently in use.
Since the start & final state can be known, you can pre-generate the
delta (see rsync --write-batch etc), or go even more efficent by looking
at block layer transfers (including bindiff of squashfs, zfs/btrfs send
& other models).

> Should Atom Gentoo be minimal to the point of excluding portage and not
> being self-sufficient? Since Atom Gentoo will receive full atomic OS
> updates, it doesn’t really need to update its own packages, and perhaps
> package management as a whole can be offloaded? This makes a lot of sense
> for mass deployment.
Putting the packages in a different layer could be valuable.

> For building Atom Gentoo, should the starting point be one of the Gentoo
> Stage 3 tarballs or even earlier? I am leaning towards “even earlier”,
> which will be necessary if portage is cut out of Atom Gentoo.
Move it to the packages layer maybe, or a "dev" layer.

> Should Atom Gentoo use a specific stdlib? I think uClibc and musl fit this
> project well, but I haven’t worked with them before.
Having multiple options shouldn't be a hurdle here ;-).

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
E-Mail   : robbat2@g.o
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136