[bug #31148] Grub Loopback Module Does not Contain Offset Functionality

[Jakub Sadowski]

Follow-up Comment #3, bug #31148 (project grub):

Rationale for this bug to be re-opened:
- There is no equivalent functionality elsewhere in GRUB2.  Blocklists can be
read to load a file but cannot be accessed with filesystem semantics (i.e.
directory listing, file printout with 'cat', etc...).
- Assuming GRUB's filesystem-awareness is intended to allow it to boot any
file accessible to the operating system which may have created it and can read
it as well.  It only makes sense to have the same semantics as supported OSes
so if the Linux loopback module can mount an image with an offset
(irregardless of the supposed intent or need for it) then GRUB should be able
to do this as well just in case the boot files (kernel, initrd, etc...) might
be located there.
- This should be relatively easy to implement.

Potential use cases:

1) We have a system with an MBR-style partition table and a partition with a
portion of the disk containing a volume (possibly with a bootable operating
system, FakeOS with Prey tracking software loaded on it in case thieves steal
the machine).  Irregardless the machine has an encrypted volume starting at
the sector after the aforementioned partition (and continuing to the end of
the disk) partition containing a bootable OS.  GRUB is booted from a USB stick
to load this OS.  Adding the encrypted volume to the partition tables is
undesirable as it reveals it's existence which may not be desired by the
system owner.

2) One has to support a system booting a Linux kernel compiled without
partition support from LILO (don't ask how or why but this is the scenario)
and changing to the GRUB2 would allow broader boot device support.  Doing this
without partitions, however, means placing the LVM volume at an offset from
the start of the device to make space for GRUB LVM code to be loaded using
blocklists.  Ideally it would be great if GRUB could load stage2 with LVM
drivers from within an LVM-formatted partition or device.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?31148>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/