Re: Chainloading to an isofile embedded bootloader

[Arbiel (gmx)]

Hi

I beg your pardon, Glenn and Y, for coming back so late to thank you for 
the very valuable pieces of information you provided me with.

Let me first explain what I'm doing.

I'm in the process of writing a little GUI (zenity-based) shell script 
to allow for the rebooting of a PC from an iso file without the need of 
anything else but Grub2 and the iso file itself (no CD burning, no 
erasing of the contents of a USB stick to make it bootable). However, 
I'm not in the spirit of, let's say, grub-iso-booting *any* file, but 
mainly GNU/Linux distributions and other Multiboot compliant kernels and 
applications.

In particular, I do not expect to be able to boot Windows iso files, 
even if such an option would certainly be interesting. I clearly 
understand having grub booting any iso file to be very challenging.

The rebooting methode I've designed consists of the creating of a 
directory, which I named "greffons", into grub's directory (let's say 
/boot/grub/greffons) to hold a file containing a "booting" function and 
the modifying of the custom.cfg file to have it "source" this 
booting-function-file and call the booting function with two parameters, 
the path to the iso file and the path to sort of a grub's configuration 
file (let's name it loopback.cfg). The booting function itself either 
"source" or "configfile" this loopback.cfg to append a new line into or 
overwrite grub's menu for the booting from the iso file.

When chosen, the submenu displays the menuentries defined in the 
loopback.cfg file, or executes the grub commands (mainly "linux", 
"initrd" and "boot") if the loopback.cfg file does not contain any 
menuentry.

When the iso file contains the loopback.cfg file, there is no difficulty 
for booting. In the other case, the loopback.cfg file is to be created, 
from the contents of the configuration files of the iso file embedded 
bootloader, and more specifically the parameters to be passed to the 
kernel in the "linux" command. And this is where the difficulties are, 
and explains my initial question : "Is it possible to chainload to the 
iso file ?". I understand now from Glenn's reply, that it cannot be done.

But Y gave me another way for achieving my goal, using "memdisk". That 
way, I've been able to increase the usability of my script to additional 
files.

But, even using memdisk, there are still files that don't boot, as 
Manjaro iso (manjaro-gnome-0.8.7.1-x86_64.iso). I understand from 
Glenn's explanations the initrd file not to be "cooperative" enough with 
the kernel. Does anybody know the way I should go to understand which 
modules are lacking and how to complement initrd to make it 
"cooperative" enough ?

Thanks to anybody who will show me the right way to go.

Arbiel

---------------------------------------------------------------

As I haven't been able to post my reply from the "help-grub" page, I've 
replicated hereunder the whole thread.

---------------------------------------------------

Y, as I explained below, its not (practically) possible.  Memdisk is a
great tool, but it *will not* work for *any* ISO.  They even say so
themselves here:
http://www.syslinux.org/wiki/index.php/MEMDISK#ISO_images.

Like I said below, that page says that booted kernels that do not goes
through the BIOS will not work (unless those kernels are specially
programmed to work).  Memdisk uses the same technique for disk
emulation that I outlined below, by hooking the BIOS call.

I definitely think it would be great for grub2 to have a
memdisk/bios-hooking feature.  It already "messes" with the BIOS a
small with in the drivemap feature.

Also, does anyone know how to do this kind of "hack" with (U)EFI?
Unfortunately, I must either boot (U)EFI or BIOS (can't go from BIOS to
(U)EFI), so it would be nice if this would be done in (U)EFI as well.

On Tue, 05 Nov 2013 09:57:49 +0100
Y <address@hidden> wrote:

> That's all very interesting information. Thank you for posting.
>
> However, unless I don't understand what the original poster actually
> wants, there is a way he can boot any ISO file: the memdisk tool from
> the syslinux package.
> See here for an example of usage with Grub2:
>
> 
http://yeti.selfip.net/cms/index.php/post/2013/05/09/Bootable-flash-drive-for-both-Linux-and-Windows%3A-part-2
>
> Y.
>
> Le 05/11/2013 00:09, Glenn Washburn a écrit :
> > On Mon, 04 Nov 2013 16:12:13 +0100
> > "Arbiel (gmx)" <address@hidden> wrote:
> >
> >> Hi
> >>
> >> Using grub2, booting a PC from an iso file is rather
> >> straightforward when the file's bootloader is grub2 itself or that
> >> the /boot/grub/loopback.cfg file exists.
> >> When this is not the case, one has to write such a
> >> /boot/grub/loopback.cfg file, and this may require a lot of
> >> expertise. A way to avoid this rather cumbersome task would be to
> >> have grub2 chainload to the loopbacked file-embedded bootloader.
> >>
> >> 1) does such a chainload operation work ?
> >
> > Usually this doesn't work.  First, loopback.cfg in general never
> > chainloads anything (I've never seen a case where it does).
> > Usually it loads a menu for then loading an initrd and kernel with
> > parameters needed by the kernel/initrd for finding the iso.  Also,
> > you seem to imply that a loopback.cfg *can* be written for an ISO.
> > This is in general not the case, and requires a cooperating initrd.
> >
> > As far as I know (and I'm no expert), the only standard way to boot
> > an ISO is through El-Torito, which essentially embeds a bootable
> > floppy image inside the ISO.  When the CDROM is booted, the second
> > sector (with CDROM sector sizes of 2K, that starts at byte 2048) is
> > loaded (not sure if how many bytes are actually loaded, but I'd
> > guess 2K). These bytes are then executed and should locate the
> > bootable floppy on the CDROM.  This floppy is loaded and executed
> > and figures out how to boot the "rest of the way".  This generally
> > entails finding a CDROM drive via the BIOS and using that as a
> > device to finish booting to.
> >
> > So the first problem is that ISOs don't start executing from the
> > first byte, unlike bootable floppies or harddisks.  Okay, we can
> > get around that by doing a chainload (dev)+4.
> >
> > But then in the normal case the bootable floppy expects to find
> > such a CDROM device via the BIOS.  If you're chainloading from a
> > file on-disk, the BIOS will have no knowledge of that ISO being a
> > CDROM drive, so the bootable floppy will fail to boot the rest of
> > the way.  Again this too can be worked around by hooking BIOS calls
> > with code to "create" a virtual CDROM for the bytes of the ISO.
> > This is not trivial, but it can be done (see grub4dos).  I have
> > successfully gotten DOS only bootable ISOs to boot fine with
> > grub4dos (these were driver update ISOs, so not a serious system).
> >
> > However, now we come to our third and (usually) more fatal problem.
> > Assuming the bootable floppy finds the virtual CDROM drive and
> > transfers control to it, the kernel (windows, linux, whatever) that
> > is loaded and control transfered to from the bootable floppy must
> > "see" the this virtual CDROM drive.  This isn't a problem if you're
> > just running DOS, which only goes through the BIOS to access disks.
> > However, all(?) modern kernels speak directly to the hardware,
> > bypassing the BIOS.  So those kernels will not see the virtual CDROM
> > drive and wonder where their rootfs is, which usually ends up
> > causing it to fall flat on its face.
> >
> > As far as I know, there's no good solution to this.  To put it
> > another way, which has been said time and time again, the ISO
> > _must_ be created with the intention of allowing boot from file in
> > order for this to work (in the generic sense).
> >
> > There are specific instances, due to the nature of the ISO that it
> > can be booted from file or (more likely) as bytes at the beginning
> > of a partition or disk.
> >
> > At one time, I was asking myself the same ones you're asking
> > yourself, which is how I came to understand the process above.  I
> > wish a generic boot from ISO file were possible, but its
> > (practically) not.  I would love for the BIOS hooking feature of
> > grub4dos to get in grub2, but I'm not willing to do it at this time.
> >
> > If anyone cares to add to or correct the above understanding of the
> > process and it limitations, I would love for a more and deeper
> > understanding.
> >
> > Cheers
> >
> >> 2) in the case it works, can you please inform me which block
> >> address and length are to be used ?
> >> 3) else, would it be possible to include this development into
> >> grub's future plans ?
> >>
> >> Thanks
> >>
> >> Arbiel
>
> _______________________________________________
> Help-grub mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/help-grub