On Mon, Sep 22, 2014 at 4:06 PM, Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com> wrote: > On 22.09.2014 22:03, Michael Marineau wrote: >> that is what I need to make use of and copying the code to re-read the >> type field yet again felt silly. My final goal is actually a module >> that will search for two partitions of the same type and select >> between them based on some other metadata. Since searching by >> partition type is already a common task in the grub code base >> providing an API to do so seemed like a good starting point. Others >> will likely find extending this to support label and uuid more useful. >> For example with GPT the Linux kernel can use >> "root=PARTUUID=<someuuid>" directly, unlike LABEL= or UUID= which must >> be implemented in an initrd. > Using partition type has proven to be unrelaiable in the past and grub2 > uses as little of it as possible. Why can't your goals be achieved with > FS UUIDs?
I'm working on CoreOS which updates /usr via read-only filesystem images, switching between using two different partitions in an A/B setup. The UUID in the filesystem is set when the image is created and has nothing to do with which of the two coppies of the filesystem I want to boot. That information is instead in the partition table, both /usr partitions have the same special type and a set of flags that determine which of the two to try next. It is based on the scheme ChromeOS uses except we only have /usr instead of root and kernel partitions. http://www.chromium.org/chromium-os/chromiumos-design-docs/disk-format#TOC-Selecting-the-kernel Right now we implement this logic in an initrd and launch the final kernel (which must match the /usr partition) via kexec. Instead I'm moving that into a grub module because kexec does not work on many platforms. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
