Strangeness with isolinux.bin

[happy-porcupine]

First, I must say that I've been a slow adopter of Imgburn, but now that I've taken time to learn it's features, I'm beginning to appreciate how much control I have over the output of custom CD images. I'm also impressed with the 2Mb footprint compared to that of Nero's at >80Mb. My thanks go out to the author for providing this freeware application.

 

I've attempted to work out the problem myself, but I'm at that point where I've looked at this too long and my interpretation of what I'm seeing may be the problem.

 

Imgburn 2.4.3.0 is exhibiting some unwanted behavior. I am working on a multiboot CD image that combines several things. (It seems) The mere presence of the file ISOLINUX.BIN anywhere in the directory structure being added to the output ISO is causing the 2K boot image to be extracted from it and used, rather than the one specified in the project settings (which is Bart's LOADER.BIN). If ISOLINUX.BIN is removed or renamed to something like ILINUX.BIN, then the substitution is suppressed, but this isn't a workaround I'm happy with. What Imgburn program setting needs to be disabled to prevent this, and furthermore, why is this happening in the first place?

 

Some hints would be helpful. Thanks for reading.

[LIGHTNING UK!]

If isolinux.bin is present then it uses it - exactly as you've seen.

 

This is because the program has to do special things with it regarding patching it and pointing the el torito descriptor at the physical file rather than making another copy it.

 

You're lucky enough to have brought this to my attention in time to make 2.4.4.0... which fingers crossed will be released later today.

 

I'll will make it prompt the user before it goes ahead and uses the isolinux.bin boot file over the one the user specifies (which going by previous threads on this subject was always that same isolinux.bin anyway).

 

Of course now I have no idea if I need to patch Bart's LOADER.BIN in the same way I had to patch ISOLINUX.BIN. Any ideas?!

[happy-porcupine]

If isolinux.bin is present then it uses it - exactly as you've seen.

 

This is because the program has to do special things with it regarding patching it and pointing the el torito descriptor at the physical file rather than making another copy it.

 

You're lucky enough to have brought this to my attention in time to make 2.4.4.0... which fingers crossed will be released later today.

 

I'll will make it prompt the user before it goes ahead and uses the isolinux.bin boot file over the one the user specifies (which going by previous threads on this subject was always that same isolinux.bin anyway).

 

Of course now I have no idea if I need to patch Bart's LOADER.BIN in the same way I had to patch ISOLINUX.BIN. Any ideas?!

 

 

Thank goodness I'm not losing my mind after all. Fffwweeeefffff.

 

LOADER.BIN is exactly 2048 bytes, and I've already used it with success on previous CD projects, so I'd say no. Also I think Bart's loader programs are El Torito aware (?) since I learned of the specification from him first. (http://www.nu2.nu/diskemu/ for your reference) Just a little background on it; LOADER.BIN basically calls a larger loader program named DISKEMU.BIN, which implements a shell program that parses a script (diskemu.cmd) that can be used as a basic bootable CD menu, which in turn will call any other loaders. So by way of example, I've made a custom CD with this that allows Windows 2000 installation AND a bunch of bootable floppies to all be selectable and ran from the loader menu.

 

I don't really understand the need to automatically deal with ISOLINUX.BIN, since it could be legitimate for the file to sit in the directory structure passively. In a test I observed that naming the file in the options for a given .IBB project works as expected, including the extraction of the boot loader from the ISOLINUX.BIN. Perhaps a "Allow passive isolinux.bin" checkbox?

[LIGHTNING UK!]

Nope, I've changed my mind.

 

It'll now only use (and patch accordingly) the isolinux\isolinux.bin file within the image if it has the same name (including path) as the one you select in the 'Bootable Disc' tab.

 

I assume your 'Bart' disc still functions 100% when you renamed isolinux.bin to something else? (i.e. so patching it isn't important at all)

[happy-porcupine]

Nope, I've changed my mind.

 

It'll now only use (and patch accordingly) the isolinux\isolinux.bin file within the image if it has the same name (including path) as the one you select in the 'Bootable Disc' tab.

 

I assume your 'Bart' disc still functions 100% when you renamed isolinux.bin to something else? (i.e. so patching it isn't important at all)

 

 

Wow. Speedy; like ... Lightning. :0)

 

Yes things are fine with the renaming. I've never had problems with using the LOADER.BIN/DISKEM1X.BIN loaders for my projects within Imgburn. ISOLINUX.BIN on the other hand has been very troublesome. You know about this minor issue, perhaps now I can now relay a second issue.

 

Working with the Ultimate Boot CD 4.11 -- if I exact the contents of their .ISO file, I can rebuild the .ISO easily with mkisofs and it boots fine. If I attempt to rebuild the .ISO with corresponding settings using ImgBurn, upon boot up ISOLINUX.BIN complains about a image checksum error. This forum has a thread on it, and I've looked at a few articles about this ISOLINUX error elsewhere, but I haven't found the right settings in ImgBurn to suppress this error, which BTW halts execution at that point.

 

I should also point out that I'm testing all my boot images in Microsoft Virtual PC 2004; I'm using ImgBurn as an .ISO builder much like people used to with WinISO.

[LIGHTNING UK!]

The image checksum (inside isolinux\isolinux.bin) is one of the things ImgBurn has to correct - and I'm hoping this now works ok in 2.4.3.0... if it doesn't, I give up! lol

[happy-porcupine]

The image checksum (inside isolinux\isolinux.bin) is one of the things ImgBurn has to correct - and I'm hoping this now works ok in 2.4.3.0... if it doesn't, I give up! lol

 

Unfortunately, I've observed the problem in v2.4.3.0, using ISOLINUX.BIN v3.35 and in the previous v2.4.2.0 using ISOLINUX.BIN v3.37 (from the extracted contents of the new UBCD v5 beta 12. What exactly is ISOLINUX.BIN checking that is triggering this failure?

[LIGHTNING UK!]

There's a CRC field in the area starting at byte 8 (56 bytes long) known as the 'boot information table'.

 

I really have fixed it now though! I rebuilt the Ubuntu 8.04 installation image and my CRC now matches the one on the original disc.

[rasheed]

My experience with isolinux.bin is as follows:

 

1. Latest versions work fine without boot info table patching - isolinux just issues a warning message saying "No boot info table, assuming single session disk...", I have built boot cds with ImgBurn 2.4.1.0 and 2.4.2.0, mkisofs and MS's CDIMAGE. They all worked fine.

 

2. Just did a quick test with ImgBurn 2.4.3.0, can't say nothing about missing boot info table error message, it boots too fast, but I assume that version 2.4.3.0 correctly patches it in.

 

3. mkisofs. If you use mkisofs to build your image, and use the "-boot-info-table" option, mkisofs will patch the boot info table into isolinux.bin file residing on your hard drive, and use patched file for boot loader. If you afterwards use other program to build your image, which does not correctly, or not at all, patch the boot info table, you'll get a checksum error and booting will fail.

 

 

-boot-info-table

Specifies that a 56-byte table with information of the CD-ROM layout will be patched in at offset 8 in the boot file. If this option is given, the boot file is modified in the source filesystem, so make sure to make a copy if this file cannot be easily regenerated! See the EL TORITO BOOT INFO TABLE section for a description of this table.

[LIGHTNING UK!]

ImgBurn's CRC calculation was 100% wrong.

 

You have to read the ISOLINUX.BIN file from byte 64 onwards in chunks of 4 bytes and CRC that. ImgBurn was reading them in the wrong order - i.e. it wanted byte[3] to be the most significant, not byte[0].