Re: Fixing grub-probe to work with user-space part stores

[Samuel Thibault]

Digging back the discussion.

Jérémie Koenig, le Tue 13 Jul 2010 20:00:24 +0200, a écrit :
> There are three approches for fixing this as far as I can see.
> 
> The second one, which I favor and am working on so far, would be to
> enumerate the _grub_ devices, and use get_storage_info() on them too.
> We would compare the result with that of the file being looked up, and
> use the grub-detected partition information to deteremine on which
> _grub_ device the file resides.

This was NACKED by grub maintainer.  Not only because he does not want
to involve GRUB here, but also because that does not work for empty
files, whose storage information is thus empty.

Actually, nowadays GRUB does not actually need a recognizable /dev/hd0s1
path.  It will be happy with whatever path lets it open the FS and
remember the UUID, and not the path which led to it. So

> The third option would be to use file_get_fs_options() (ie. fsysopts)
> instead of get_storage_info(), and attempt to decode the retreived
> command line. This could not be made reliable, though, since only the
> actual translator knows extractly what its options mean, and a given
> store can be specified in many different ways.

this kind of option may actually be sensible: it's exactly that
information that GRUB wants: the node that the filesystem opens.  We
just need to define a standard way to get it.  As mentioned above,
fetching from the command line can be fragile.  Another way is to define
an RPC to get the name actually opened by libdiskfs.  In both case, we
have to handle /dev/foobar or device:foobar anyway.  In the latter case,
if we don't want to assume that /dev/foobar exists, we could write a
devmux, and point GRUB at a devmuxed /dev/storeio/foobar.  There can be
other types, of course, but we can probably require the user to refrain
himself from them for / and /boot.

As a working-enough-for-now solution, we can use the non-option part of
fsysopts, and replace device: with /dev/.

> The first one would be to make part.c embed extra information in its
> stores and their encoded form (possibly in the "misc" fiels of a remap
> store). This would force it to create a new layer instead of reusing
> the underlying store, which could reduce performance slightly in some
> cases. It would need complicity from remap.c, which has jusrisdiction
> over its "misc" field as far as I can tell. It would also change the
> existing principle by which stores and storage_info provide a way to
> access the underlying storage in the most direct way possible, as
> opposed to encoding the history of how the store was constructed.

That seems quite complex, and is actually more than GRUB needs: it
doesn't need partition number etc., just what file to open.

What do people think?

Samuel