On Mon, Jul 12, 2010 at 11:19 PM, <olafbuddenha...@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 <j...@jk.fr.eu.org> http://jk.fr.eu.org/
