Jump to content

Strange or "odd" multi or single boot CD/DVD El-Torito images


jaclaz

Recommended Posts

Seemingly you just check that at offset 510 there are Magic Bytes 55AA and from this you assume that the sector is a MBR or a PBR.

 

True !

At that stage that is all I test yes.

 

I could look into a stricter test (I'm not promising and it may be next week before I find time for that).

Link to comment
Share on other sites


 

Seemingly you just check that at offset 510 there are Magic Bytes 55AA and from this you assume that the sector is a MBR or a PBR.

 

True !

At that stage that is all I test yes.

 

I could look into a stricter test (I'm not promising and it may be next week before I find time for that).

 

No hurry and no worry. :)

 

I re-checked the older Isolinux versions and (unwantingly of course) I brought you on a "wrong" path. :w00t::ph34r:

 

Earlier versions of Isolinux NEED the -boot-info-table switch in mkisofs to be actually bootable.

 

The pre-embedded valid boot info table in later Isolinux has seemingly been implemented to avoid the need for the -boot-info-table switch.

 

In other words (apart the "source" isolinux.bin in the original tool archive) it seemingly cannot exist "In nature" a bootable Isolinux based CD without correct bootinfotable data (no matter of course if that is the pre-embedded or the mkisofs calculated/patched one), in practice a .iso made with Isolinux before 2.12 with mkisofs without the -boot-info-table switch won' t be bootable.

 

As such, now that the bootinfotable checksum verifying is corrected, there is no need :no: for the "EFBEADDE" check, as any "real world" .iso based on Isolinux is correctly identified :yes: by the size and checksum in the bootinfotable. 

 

I hate it when it turns out that I am  more royalist than the king ! :blushing:

 

jaclaz

Link to comment
Share on other sites

As such, now that the bootinfotable checksum verifying is corrected, there is no need :no: for the "EFBEADDE" check, as any "real world" .iso based on Isolinux is correctly identified :yes: by the size and checksum in the bootinfotable.

 

I see .. so the hardcoded option is not really needed ?

Well ... I 'll leave it in, for when people uncheck the 'mkisofs' test but leave the hardcoded checkbox on.

Maybe I'll have to add another hardcoded check again at a later date.

Link to comment
Share on other sites

I see .. so the hardcoded option is not really needed ?

No.

 

Well ... I 'll leave it in, for when people uncheck the 'mkisofs' test but leave the hardcoded checkbox on.

But, if I get it right, it will never detect anything. :ph34r:

The isolinux.bin before 2.12 has ALL fields set to "EFBEADDE" BUT it cannot be used without the mkisofs -boot-info-table switch that will fix with the right values into first (only used) 4 fields with the right data AND fill all the other fields with 00's.

The isolinux.bin 2.12 and later will have the first 4 fields pre-set and all the other ones set to "EFBEADDE" (i.e. it will work with or without the mkisofs switch, and the only difference will be whether the other unused fields will "EFBEADDE" or "00000000").

If you are checking for "EFBEADDE" in the first 4 sectors fields, you will never find a bootable .iso based on isolinux with those values.

 

Maybe I'll have to add another hardcoded check again at a later date.

Keeping the "hardcoded check" routine handy may be of use in the future, but right now the option is (sorry, my bad :() not useful.

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

Hello,

 

Small update.

 

This version tests a bit stricter for a FAT volume (so not just the 0x55AA signature)

Nothing else changed.  I didn't really test but I'm confident ;)

 

I decided to leave the "hard coded" option checked by default because it also includes the test for "ISOLINUX" and the name change of "BootImage.img" to "IsoLinux.img".

Link to comment
Share on other sites

Yep :yes:, sorry I had no time to test latest/latest, I now have done it and it seems like it's fine :).

 

A further (semi-random) thought (still connected with the generic concept of making the user more aware about what is going on).

What if you (if possible of course, and with a low-low priority) add a small icon near the boot image file, indicating the method used to detect/analyze it?

Something *like*:

c - catalog

m - mkisofs

o - other ISO filesystem structures

v - volume or hard disk image PBR or MBR

...

 

Still to be picky (as I am ;)), what would  happen if I use (for the fun of it) a non FAT filesystem for a "queer" image like the Acronis one?

(FAT filesystem is of course compulsory for the EFI image), but it shouldn't be for an image made out of a loader+volume (very unlikely, but possible I believe).

 

jaclaz

Link to comment
Share on other sites

what would  happen if I use (for the fun of it) a non FAT filesystem for a "queer" image like the Acronis one?

 

Then you let me know and I'll see what I can do :)

It already works for NTFS btw, but not for other FS.  Frankly it's not that high a priority anyway as I see it.  It's just about finding another volume inside the image file.

The option to expand FAT from Boot image files also only works for FAT btw !!

 

The icons ... maybe later but I'm not promising :)

 

I think this project is sort of done unless issues are found or more exceptions can be implemented.

Link to comment
Share on other sites

 

I think this project is sort of done unless issues are found or more exceptions can be implemented.

 

Yes, I also believe that there is no real sense in continuing until a new "queer" .iso image is spotted in the wild ;).

More than "done", I would say "dormant" (but ready to wake up if *needed*).

 

jaclaz

Link to comment
Share on other sites

  • 5 weeks later...

Before I forget :w00t:, in order to keep things as together as possible :), here is another example of when a "peculiar" setting/edit is needed:

http://www.msfn.org/board/topic/149758-win7pe-se/page-6#entry1067197

 

Basically, if a "dual boot" BIOS/UEFI CD/DVD is made with OSCIMG using grldr (but I believe *any* non-2048 or non 4096 bytes loader are likely to behave the same :unsure:), on some older BIOSes the thingy won' t boot and there is the need to edit the "Size to be initially loaded" to 2048 bytes.

 

jaclaz

Link to comment
Share on other sites

  • 1 month later...
  • 3 weeks later...

The final version is (finally) out: http://www.isobuster.com/news/isobuster_3.5_release_notes

From now on these changes are available in all future versions, no need to work with test or beta versions anymore.

 

Merry Christmas !

 

It seems like some of the new features have found an actual practical use :thumbup, JFYI:

http://reboot.pro/topic/20004-boot-a-acronis-true-image-2014-iso-image-with-grub2-at-uefi/

 

Merry Chistmas to you too. santa-smiley-ho-ho-ho.gif

 

jaclaz

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...