[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH] Add new partition type API and convert GPT type checks.

From: Andrei Borzenkov
Subject: Re: [RFC PATCH] Add new partition type API and convert GPT type checks.
Date: Tue, 23 Sep 2014 21:27:38 +0400

В Mon, 22 Sep 2014 16:49:46 -0700
Michael Marineau <address@hidden> пишет:

> On Mon, Sep 22, 2014 at 4:06 PM, Vladimir 'φ-coder/phcoder' Serbinenko
> <address@hidden> 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.
> 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.

It has GPT as prerequisite, and does not look like it would work with
anything else. Just implement support in loader module. If more users
appear, it is always possible to factor out common code.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]