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

[Jérémie Koenig]

On Mon, Jul 12, 2010 at 11:19 PM,  <olafBuddenhagen@gmx.net> wrote:
> I already talked to Jeremie
> about handling of partitions in grub-probe. As this is a rather
> fundamental issue, I hope he will start an extra thread on this.

Summary: grub-probe, used by grub-install, needs to deteremine which
device node a given file (say, /boot/grub) is stored on. In the
current implementation, the system device node path is effectively
used as the canonical name for a given device. The current strategy
for Hurd is to use file_get_storage_info() (same as store_open()
does), to determine the underlying Mach device name, an prepend
"/dev/" to it.

When Mach partition devices are used, this is fine. But user-space
part stores have the whole disk as the backing device, so the current
grub-probe reports that which makes grub-install fail. There are three
approches for fixing this as far as I can see.

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.

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. The result would be converted to a
system device node path by using the device.map information. In this
scenario, on Hurd, the device node path would be used as a name only,
and grub-install could be made to work on, say, disk image files whose
partitions would have been mounted using the part: store.

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.

What do you think?

-- 
Jérémie Koenig <jk@jk.fr.eu.org>
http://jk.fr.eu.org/