[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Chainloading to an isofile embedded bootloader
Re: Chainloading to an isofile embedded bootloader
Tue, 5 Nov 2013 10:25:26 -0600
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
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:
> 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