Hello cloud dwellers,<div><br></div><div>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. &nbsp;</div><div><br></div><div>Basically we have extlinux in the VBR, and /boot/extlinux/extlinux.conf. &nbsp;This is used by qemu-kvm/OpenStack. &nbsp;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.</div><div><br></div><div>Then for upgrades, grubby knows how to update both config files. &nbsp;Due to the way grubby is implemented, it also handles the fact that they have *different* kernel arguments. &nbsp;We're conflating EC2 with grub1, and setting console=hvc0.</div><div><br></div><div>So...ostree is really not set up to handle this. &nbsp;A bit of background - ostree is designed around the BLS:</div><div><a href="http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/">http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/</a></div><div>Concretely it writes /boot/loader.[01]/entries/ostree-&lt;data&gt;.conf</div><div>for each root. &nbsp;Why [01]? &nbsp;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.</div><div><br></div><div>Not every bootloader implements the BLS (in fact it's mostly just gummiboot and pjones' patch for grub2). &nbsp;So what OSTree does is update traditional config files like /boot/syslinux.cfg from that config.</div><div><br></div><div>Now, I could probably with not too much effort synthesize both extlinux and grub1 configs. &nbsp;But that wouldn't handle this case where we actually have different kernel arguments.</div><div><br></div><div>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.</div><div><br></div><div>Would anyone be opposed to having separate kickstarts for EC2 versus qemu/kvm? &nbsp;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.</div><div><br></div><div>Then for OpenStack we use extlinux. &nbsp;These kickstart files would of course inherit from a common content definition/configuration base.</div><div><br></div><div>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. &nbsp;</div><div><br></div><div>Thoughts?</div>