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