So I was looking at rpm-ostree + EC2 stuff, and digging into the current Fedora cloud image, I hadn't realized just how special it is.
Basically we have extlinux in the VBR, and /boot/extlinux/extlinux.conf. This is used by qemu-kvm/OpenStack. But in order to support EC2's pv-grub, we also have /boot/grub/grub.conf which is generated by hand from the kickstart file.
Then for upgrades, grubby knows how to update both config files. Due to the way grubby is implemented, it also handles the fact that they have *different* kernel arguments. We're conflating EC2 with grub1, and setting console=hvc0.
So...ostree is really not set up to handle this. A bit of background - ostree is designed around the BLS:
Concretely it writes /boot/loader.[01]/entries/ostree-<data>.conf
for each root. Why [01]? That's how the atomic updates are implemeted, when we want to update the config, we create a new dir, write files, then swap the symlink.
Not every bootloader implements the BLS (in fact it's mostly just gummiboot and pjones' patch for grub2). So what OSTree does is update traditional config files like /boot/syslinux.cfg from that config.
Now, I could probably with not too much effort synthesize both extlinux and grub1 configs. But that wouldn't handle this case where we actually have different kernel arguments.
What makes this situation uglier is writing the grub1 config by hand - Anaconda still has code to write grub1 configs, even though the grub1 package no longer exists in Fedora.
Would anyone be opposed to having separate kickstarts for EC2 versus qemu/kvm? It feels like with EC2 it'd be less magical if we used the new "bootloader --disabled" to skip installing extlinux (or grub2) at all, and kept our hack to create the grub1 config.
Then for OpenStack we use extlinux. These kickstart files would of course inherit from a common content definition/configuration base.
BTW - another argument for splitting is that with GCE, we'll likely want a custom configuration for cloud-init (or min-metadata-service) to have it DTRT.
Thoughts?
_______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
