happy-porcupine

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?

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.

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?

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.