Re: [PATCH,HURD] Fix grub-probe with userland partition support

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3332 bytes --]

On 25.04.2012 00:21, Samuel Thibault wrote:
> Vladimir 'φ-coder/phcoder' Serbinenko, le Tue 24 Apr 2012 22:14:33 +0200, a écrit :
>> On 24.04.2012 19:13, Samuel Thibault wrote:
>>> Vladimir 'φ-coder/phcoder' Serbinenko, le Tue 24 Apr 2012 15:19:25 +0200, a écrit :
>>>> On 24.04.2012 14:42, Samuel Thibault wrote:
>>>>> 0-sized indeed poses problems.
>>>>>
>>>>>> I'm surprised that Hurd doesn't offer a way to just ask "What does this
>>>>>> filesystem translator consume?"
>>>>> Because the whole point of the Hurd is to let the user have access
>>>>> to more powerful ways.  A file can reside inside an iso file, which
>>>>> is stored in an ext2fs, which is stored in a file,
>>>> So much GRUB can handle.
>>> But how to express that to GRUB? grub_guess_root_devices only returns
>>> a series of alternative paths.  See below.
>> By just giving the file in question.
> That will not tell you which image has to be mounted to find it.
As I said: currently we assume that image is for VM use, so nothing
needs to be specifically mounted. Just return image filename. When the
adssumption is lifted mounting would be handled in
prepare_grub_to_access_device
>>>> As for the second, we're limited to what GRUB can do and so it won't be
>>>> possible to have /boot on translator from hyperspace.
>>> Sure.  But it can be something expressed in a complex way by the user,
>>> which can actually be reached by GRUB.  That said, as I said earlier, we
>>> can ask the user to refrain himself when it's about /boot.
>> We can add more translators handling as-needed.
> So would it be acceptable for now as a horrible-but-works solution to
> use the output of sysopts:
>
> ext2fs --writable --no-atime --no-inherit-dir-group --store-type=typed device:hd1
>
> and
>
> /hurd/ext2fs --writable --no-inherit-dir-group /dev/hd0s1
>
> Drop the first parameter (translator path), -* options, and that leaves
> only the device, with additional s_device:_/dev/_ mangling.
Yes it will, just we need comprehensive error messages on failure and a
comment in code that it's not complete solution.
>>>>> But we generally don't want to impose any syntax here, it could actually
>>>>> be
>>>>>
>>>>> /opt/my/own/translator xyz
>>>>>
>>>>> I guess we'll have to impose some syntax anyway for whatever contains
>>>>> /boot, so that grub can open it itself.
>>>> There should be a standartised way to get this information for any
>>>> conventional FS, otherwise it makes porting programs which use this
>>>> information much more difficult and in most cases results in dirty
>>>> workarounds.
>>> So far, I've mostly seen GRUB really needing that information.
>> I suppose that databases would want to know this for optimisations.
> libstore does provide the best thing for that: the actual area on the
> disk, which is what was used in the very first patch already, and which
> is used for swap, etc.  But that reveals to be actually too precise for
> GRUB.
It's more of it not being stable. You could access all the files by
blocklists but it would fail very quickly
> Samuel
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]