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

[Samuel Thibault <samuel.thibault@ens-lyon.org>]

Vladimir 'φ-coder/phcoder' Serbinenko, le Tue 24 Apr 2012 15:19:25 +0200, a écrit :
> On 24.04.2012 14:42, Samuel Thibault wrote:
> > Vladimir 'φ-coder/phcoder' Serbinenko, le Tue 24 Apr 2012 11:55:33 +0200, a écrit :
> >> They have iso9660 spanning through
> >> the whole disk but all of the disk other than the first sector is
> >> in some kind of partition table to avoid it being accidentally
> >> overwritten.  So even though the file itself is inside a partition, we
> >> want the whole disk.
> > The partition itself can not be mounted?
> No, since it contains FS structures at wrong offset.

Ok.

> >> Also if file is 0-sized, sparse, compressed or encrypted it won't have
> >> blocklist and this approach would fail, possibly even with out-of-range
> >> array access.
> > Other than 0-sized would work, the eventual storage would still be on
> > the partition.
> completely sparse just has a size and not backed by any storage.

That's included in "0-size" in my head :)

> > 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.

> We don't handle loopback automatically right now since it's not clear
> whether it's a loopback for VM or loopback used on host.

You'd need to know which files to open anyway. You don't want to browse
all filesystems for that :) So the OS-specific function has to tell you.

> >  using the user's
> > own translator with no constraint on the naming convention, etc. etc.
> For these ones we're limited at what GRUB can. grub-probe is used for 2
> purposes:
> 1) Determining the device for root, its FS and UUID
> 2) Determining the GRUB environment on boot.
> The first is used in grub-mkconfig and if Hurd is so much more flexible
> 10_hurd.in may need to be adjusted accordingly.

Sure.

> 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.

> > 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.

Samuel