53 replies to this topic

[cdob]

we need then to feed the (hopefully valid) result into a small batch similar to the partnew command in grub4dos, I believe that for isohybrid compatibility only the "Magic Bytes" need to be added (besides the partition entry

If need be: partnew can be used to create the partition entry. A grub4dos batch to create a UEFI image fake partiton.
However grub4dos dosn't boot at UEFI mode. A BIOS boot would be necessary.
I would prefer a windows approach.

To investigate a isohybrided ubuntu-14.10-desktop-amd64.iso, both MBR and GPT partitions

loopback loop /ubuntu.iso
ls
(loop) (loop,msdos2) (loop,apple2) (loop,apple2)
ls (loop,msdos2)/efi/boot
bootx64.efi grubx64.efi

The file ubuntu.iso hexedited, gpt deleted, MBR boot code deleted.
One non active partiton entry and "Magic Bytes" exist still:
loopback mounts the EFI image at (loop,msdos2).

[Wonko the Sane]

Sure , a small windows batch of course, replicating the way the partnew command behaves in grub4dos,.

 

A further experiment for your test .iso.

GRUB2 may ignore completely the CHS values, so the non-0 Parittion ID and the LBA Start and Number of sectors may be enough in a partition entry.

 

Wonko

[cdob]

GRUB2 may ignore completely the CHS values, so the non-0 Parittion ID and the LBA Start and Number of sectors may be enough in a partition entry.

Yes, that's a good guess:

Both approaches works, ls (loop,msdos2)/efi/boot is possible:

With CHS values

1C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FE
1D0 FF FF EF FE FF FF D0 56 22 00 C0 11 00 00 00 00
1E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA

Zeroed CHS values

1C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1D0 00 00 EF 00 00 00 D0 56 22 00 C0 11 00 00 00 00
1E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA

[Wonko the Sane]

Yes, that's a good guess:

Both approaches works, ls (loop,msdos2)/efi/boot is possible:

Good, this simplifies matters, as basically we can get the "Numbers of sectors" from the bootsector without doing any calculation with cylinders/heads/sectors.

I need to do some tests, but if I get this right, what we need is ultimately:

1. find an "EF" entry
2. verify it is  "88"
3. fundamentally "ignore" whether it is 00/01/02/03/04
4. find and verify the next (FAT) bootsector
5. copy to sector 0 in a partition entry the "EF" partition type, the extents of the volume (taken "as is" from the bootsector) and calculate it's start LBA, basically multiplying by 4 the address of the found bootsector on CD.
6. write the 55AA magic bytes to sector 0

Wonko

[Wonko the Sane]

This might do .

::- mkhybEFI.cmd Version 0.01 Alpha 21 December 2014
::- Small batch file by jaclaz - released under CAREWARE license
::- http://jaclaz.altervista.org/Projects/careware.html
::- to make ISO-HYBRID iso's from ones containing EFI boot image
::- usage:
::- mkhybEFI.cmd <[path]iso_filename.iso>
::- Hopefully you will get the offset (expressed in 512 bytes sectors)
::- of the Bootable image(s) and their length (also in 512 bytes sectors)
::- and optionally modify the .iso writing them to it's first sector
::- useful for GRUB2 mapping to loopback devices of Acronis .iso's
::- Needs dumphex.exe
::- http://rbach.priv.at/DumpHex/
::- and hexalter.exe
::- http://kuwanger.net/misc/hexalter.shtml

But I am not at all "convinced" that it will work properly on *any* .iso, particularly NOT on the one hason has that seems like a Hard Disk emulation one.

Now the point is, should we *somehow* recognize that it is a MBR and use info in it, or "blindly" check a number of following sectors (how many? I mean like 63 or 2048 )

 

Wonko

Attached Files

•  mkhybEFI_001.zip   2.49KB   663 downloads

[hason]

This might do .

::- mkhybEFI.cmd Version 0.01 Alpha 21 December 2014
::- Small batch file by jaclaz - released under CAREWARE license
::- http://jaclaz.altervista.org/Projects/careware.html
::- to make ISO-HYBRID iso's from ones containing EFI boot image
::- usage:
::- mkhybEFI.cmd <[path]iso_filename.iso>
::- Hopefully you will get the offset (expressed in 512 bytes sectors)
::- of the Bootable image(s) and their length (also in 512 bytes sectors)
::- and optionally modify the .iso writing them to it's first sector
::- useful for GRUB2 mapping to loopback devices of Acronis .iso's
::- Needs dumphex.exe
::- http://rbach.priv.at/DumpHex/
::- and hexalter.exe
::- http://kuwanger.net/misc/hexalter.shtml

But I am not at all "convinced" that it will work properly on *any* .iso, particularly NOT on the one hason has that seems like a Hard Disk emulation one.
Now the point is, should we *somehow* recognize that it is a MBR and use info in it, or "blindly" check a number of following sectors (how many? I mean like 63 or 2048 )
 

Wonko

I was try with mkhybefi.cmd.

It seems same original ifu.iso

[Wonko the Sane]

Sure , that was expected.

 

The batch should work fine however for the more "normal" Acronis.iso's that have a plain "superfloppy" image.

I have not that particular "ifu" image, so I have nothing to test it with, you could extract from it Sectors 0-39, compress them in a zip file and post the archive.

 

Using dsfo that would be:

dsfo ifu.iso 0 81920 ifysectors039.bin

 

Wonko

[hason]

Sure , that was expected.
 
The batch should work fine however for the more "normal" Acronis.iso's that have a plain "superfloppy" image.
I have not that particular "ifu" image, so I have nothing to test it with, you could extract from it Sectors 0-39, compress them in a zip file and post the archive.
 
Using dsfo that would be:
dsfo ifu.iso 0 81920 ifysectors039.bin
 

Wonko

I can not attach file on forum. I was upload it via datafilehost.
http://www.datafilehost.com/d/d6bcc746

[Wonko the Sane]

Edit mkhybEFI.cmd.

Add, right after:

FOR /F "tokens=2,3,4 delims= " %%A IN ('dumphex /S%MyOffset% /L3 %Source% 2^>NUL') DO (
SET JB=%%A%%C
)
IF %JB%==EB90 SET /A Count+=1

a line:

IF %JB%==E900 SET /A Count+=1

and try again, it should work, the image is after all a "floppy-like one", actually FAT12 but it uses the "other" set of jump bytes, see as a reference:
http://www.msfn.org/...mages/?p=987482

I'll think of a more comprehensive/better checking code according to the above, I fear that checking for just the first byte (EB or E9) might lead to "false positives".


Wonko

[hason]

Edit mkhybEFI.cmd.

Add, right after:

a line:

IF %JB%==E900 SET /A Count+=1

and try again, it should work, the image is after all a "floppy-like one", actually FAT12 but it uses the "other" set of jump bytes, see as a reference:
http://www.msfn.org/...mages/?p=987482

I'll think of a more comprehensive/better checking code according to the above, I fear that checking for just the first byte (EB or E9) might lead to "false positives".


Wonko

I was try but it did not work.

[Wonko the Sane]

What do you mean "I was try but it did not work"?

 

It seems like the batch worked, i.e. it should have produced the intended result, the issue here seems like something not working in GRUB2 or in it's booting/chainloading mode, I can mount the (partial) filesystem fine in (say) IMDISK.

 

Wonko

[hason]

I was try boot ifu.iso in uefi mode via grub2. Try loopback
loopback ElTorito (loop)108+13224
set root=(ElTorito,msdos1)
and I got error "disk 'ElTorito,msdos1' not found. How to mount it via imdisk?

[Wonko the Sane]

Well, here we have an issue in communication (and possibly you are not familiar with batches/haven't looked inside it)

From the screenshot you posted from IsoBuster it seemed that the image was a hard disk like one.
Verified, it is a normal "floppy" like or Volume.

The idea by cdob (and what the batch should do) is to modify the whole .iso adding to it a iso-hybrid MBR with the mapping to the volume.


So, you want to map the whole .iso as loopback device, *like*:
 

loopback ElTorito /ifu.iso
set root=(ElTorito,msdos1)

But of course, now that it seems like the batch works fine, you have to make it actually write to the .iso, see in the batch:
 

:: Right now only a simulated write is performed.
:: Remove the ECHO from the following line to enable writing to the .iso MBR
SET ShoWOnly=ECHO

Wonko

[hason]

Well, here we have an issue in communication (and possibly you are not familiar with batches/haven't looked inside it)

From the screenshot you posted from IsoBuster it seemed that the image was a hard disk like one.
Verified, it is a normal "floppy" like or Volume.

The idea by cdob (and what the batch should do) is to modify the whole .iso adding to it a iso-hybrid MBR with the mapping to the volume.


So, you want to map the whole .iso as loopback device, *like*:
 

loopback ElTorito /ifu.iso
set root=(ElTorito,msdos1)

But of course, now that it seems like the batch works fine, you have to make it actually write to the .iso, see in the batch:
 




Wonko

I was remove try again.

But it did not work.
If I use:

loopback ElTorito (loop)108+13224
set root=(ElTorito,msdos1)
It shows: disk 'Eltorio,msdos1' not found

If I use:

loopback ElTorito /images/ifu.iso
set root=(ElTorito,msdos1)

It shows


Thanks for all. Merry christmas!

[Wonko the Sane]

Yes, that last "error message"  comes from the GRUB2.

 

Still if you use a disk/drive mounting tool (like the mentioned IMDISK), the modified .iso is mountable and it's contents are accessible.

 

So, it must be some issue of GRUB2 with the specific image.

 

The "difference" may lie in the FAT12 filesystem chosen, or in the non-conventional geometry of 16 heads 17 sectors per head or in the "sectors before" that are set to 0  cannot say.

You can try to correct "sectors before" in the bootsector 

that would be:

hexalter ifu.iso 0xD81C=0x6C,0x00,0x00,0x00

to reset to "current" 0 value:

hexalter ifu.iso 0xD81C=0x00,0x00,0x00,0x00

 

As a matter of fact the mentioned "partnew" command in grub4dos does automatically that correction, so it is very possible that it is *needed* for GRUB2 too.

 

Wonko

[hason]

I was try to correct "boot sector" but It has same error when I test it. It seems no way for ifu.iso. Also, I was try unpack ifu.iso, keep only bootx64.efi and ifu.ini. Oh good, it can use without iso file.

menuentry "TeraByte for UEFI" {
search --no-floppy --file --set=root /ifu/imageu.efi
chainloader /ifu/imageu.efi

Thank you for all. Merry Christmas and Happy new year

[cdob]

This might do

Thanks, well done. Works at Acronis ISO.
 

It seems no way for ifu.iso.

Yes, the booting is the difficult part.

Time to try previous question?
 

menuentry "Acronis True Image Home 2015 ISO ElTorito" {
set quiet=1
set gfxpayload=1024x768x32,1024x768
set mbrcrcs=on
set isofile="/ATIH2015.iso"
#isohybrided http://reboot.pro/topic/20004-boot-a-acronis-true-image-2014-iso-image-with-grub2-at-uefi/page-2#entry189345
search --set -f $isofile
loopback loop $isofile
linux (loop,msdos1)/dat9.dat quiet
initrd (loop,msdos1)/dat8.dat
}

[Wonko the Sane]

Thanks, well done. Works at Acronis ISO.

Good .
BUT, I am failing to see how this approach:

Yes, the booting is the difficult part.

Time to try previous question?
 

menuentry "Acronis True Image Home 2015 ISO ElTorito" {
set quiet=1
set gfxpayload=1024x768x32,1024x768
set mbrcrcs=on
set isofile="/ATIH2015.iso"
#isohybrided http://reboot.pro/topic/20004-boot-a-acronis-true-image-2014-iso-image-with-grub2-at-uefi/page-2#entry189345
search --set -f $isofile
loopback loop $isofile
linux (loop,msdos1)/dat9.dat quiet
initrd (loop,msdos1)/dat8.dat
}

is leading *anywhere*.

I mean, if we use the little batch, we get a isohybrided .iso with the partition entry in first slot, aka "msdos1" in the stupid GRUB2 syntax, (OK) but if next step is anyway that of chainloading a kernel and a initrd (that can be called dat9.dat/dat8.dat but also - say - dat13.dat/dat12.dat) so there is anyway the need to manually find which file is the actual kernel and initrd,  there is IMHO very little "practical advantage" in having:

search --set -f $isofile
loopback loop $isofile

when opposed to:

search --set -f $isofile
loopback loop $isofile
loopback ElTorito (loop)160+158000

i.e. we can still use the batch to find the 160+158000 values, but altering the .iso image making it isohybrided is IMHO only an unneeded complication...

 

... unless *somehow* also the "\efi\bootx64.xml" is parsed to find what file is what (kernel/initrd), but then again the "\efi\bootx64.xml" is only - I believe - in some of these Acronis .iso and it is not a "standard" file.

 

Wonko

[hason]

Thanks, well done. Works at Acronis ISO.
 
Yes, the booting is the difficult part.

Time to try previous question?
 

menuentry "Acronis True Image Home 2015 ISO ElTorito" {
set quiet=1
set gfxpayload=1024x768x32,1024x768
set mbrcrcs=on
set isofile="/ATIH2015.iso"
#isohybrided http://reboot.pro/topic/20004-boot-a-acronis-true-image-2014-iso-image-with-grub2-at-uefi/page-2#entry189345
search --set -f $isofile
loopback loop $isofile
linux (loop,msdos1)/dat9.dat quiet
initrd (loop,msdos1)/dat8.dat
}

I was try with ati15.iso

use code

menuentry "Acronis True Image Home 2015 ISO ElTorito" {
set quiet=1
set gfxpayload=1024x768x32,1024x768
set mbrcrcs=on
set isofile="/images/ati15.iso"
#isohybrided http://reboot.pro/topic/20004-boot-a-acronis-true-image-2014-iso-image-with-grub2-at-uefi/page-2#entry189345
search --set -f $isofile
loopback loop $isofile
linux (loop,msdos1)/dat9.dat quiet
initrd (loop,msdos1)/dat8.dat
boot

It works ok.

[hason]

I used mkhybEFI.cmd to patch add12.iso. And I was try test on two system.
Vmware: windows 8x64; uefi
-All work (ati15.iso; add12.iso)
Vmware: windows 8(x32, x64); legacy bios
- Ati15.iso: ok
- Add12.iso: not work
All test with grub2

menuentry "Acronis Disk Director Home 12 ISO ElTorito" {
set quiet=1
set gfxpayload=1024x768x32,1024x768
set mbrcrcs=on
set isofile="/images/add12.iso"
#isohybrided http://reboot.pro/topic/20004-boot-a-acronis-true-image-2014-iso-image-with-grub2-at-uefi/page-2#entry189345
search --set -f $isofile
loopback loop $isofile
linux (loop,msdos1)/dat5.dat quiet
initrd (loop,msdos1)/dat4.dat
boot

If I try mount Eltorito

menuentry "Acronis Disk Director Home 12 ISO ElTorito" {
set quiet=1
set gfxpayload=1024x768x32,1024x768
set mbrcrcs=on
set isofile="/images/add12.iso"
search --set -f $isofile
loopback loop $isofile
echo mount the El Torito floppy image
loopback ElTorito (loop)220+161792
#ls (ElTorito)/
linux (ElTorito)/dat5.dat quiet
initrd (ElTorito)/dat4.dat
boot
}

It work ok.

[Wonko the Sane]

Well, this somehow confirms how the isohybriding is not (unfortunately) an "universal" solution, from what you report the ati15.iso works indifferently if the kernel and intird are chainloaded when the FAT image is mounted to loop device as "hard disk volume" (with the isohybrided .iso) or "directly" as "floppy image", whilst the add12.iso only works in the latter case (on BIOS, while in EFI/UEFI it is OK).

But you could try again after having corrected the "sectors before" in the add12.iso bootsector of the FAT image, the point here is that EFI/UEFI way of booting does not really-really need this piece of info, while the BIOS usually does. (but of course this ultimately depends on what is inside the actual initrd)

 

Wonko

[hason]

Today, I was test all acronis iso on real uefi system. It's so bad! It was hang on "Acronis loading...". I was try remove "quite" from code and I had this error:

unable to handle kernel paging request at 0000000075b1c288

How to resolve it? 

[cdob]

It was hang on "Acronis loading...".

unable to handle kernel paging request at 0000000075b1c288

The OS dosn't support the hardware.
Asks the manufacturer to support the hardware.

[kyvaith]

Hi,

 

 

Maybe some of you could help me with my problem:

 

http://www.msfn.org/...rm-grub2-cddvd/

[Wonko the Sane]

 

Hi,

 

 

Maybe some of you could help me with my problem:

 

http://www.msfn.org/...rm-grub2-cddvd/

 

 

Or maybe not, as a matter of fact someone may decide to not help you only because you bump threads everywhere for no other reason than to ask for help.

 

Wonko