Problems with "extract boot image"

[Die In Sente]

I've been trying to create a bootable CD/DVD/ISO from a bootable USB flash drive.   Google search brought me to try using ImgBurn for this, so I downloaded and installed, it, but it doesn't seem to work in this case.

Just to be clear, I'm trying to create a bootable CD with the Seagate "SeaTools Bootable" package https://www.seagate.com/support/downloads/seatools/, so I can run hard drive diagnostics.   No, Seagate does NOT have a downloadable ISO on their web site -- at least not that I can find.  Instead, you download a windows executable, which will format your flash drive and copy all the utilities onto it.    This flash drive boots up fine on multiple boxes that I've tried.   I thought it should be relatively easy to convert this to a bootable CD.  Boy, was I wrong about that.

The process I've been using, which seems to be correct from reading the guides is:

• Open ImgBurn
• Select "Create image file from files/folders"
• Add all of the files from the flash drive to the project.   (I think this is optional, and just duplicates having the files in the boot image.)
• Go to the Labels tab and enter labels
• Go to the Advanced | Bootable Disc tab and select "Make Image Bootable".
• Go down to the "Extract Boot Image" pane, select the flash drive, and click on the little save icon.
• This will create a "BootImage.ima" file.
• When that's complete, ImgBurn asks if I "would like to use the boot image file in your current project?" and I click "Yes".  This sets the Emulation Type to "Hard Disk" and sets the Boot Image to file I just created.
• Optionally, type some text into the "Developer ID" box.   It doesn't seem to matter what, if anything is entered there.
• Click on the icon to create the ISO.

As I say, this DOES NOT WORK.   ImgBurn says is successfully created the ISO and there are no errors messages  (log attached), but the resulting ISO is not bootable.   If I try to boot it, I just get "Missing operating system".   I spent several hours and burned a bunch of useless coasters trying different variations:  different sized flash drives, different media, CD versus DVD, trying to boot different computers, different optical drives, trying to boot Virtual Box with the ISO, etc.   Nothing worked.  Always the same result: "Missing operating system".

Digging down, I found that what the ImgBurn "Extract Boot Image" function does is, it makes a binary copy of the FAT32 partition on the flash drive, but it does not read the MBR (master boot record) from the flash drive.    The .ima file produced is a binary disk image, but ImgBurn prepends it's own MBR boot code and creates a partition table in the image de novo.   (Background:  hard drives are formatted with an MBR at sector 0 which contains the partition table, and -- optionally, if the drive is bootable -- some bootstrap code in bytes 0x0 thu 0x1BD of that sector.)  Examining the MBR that ImgBurn writes to the .ima file,  the only thing I noticed that seemed off was that the field for the "number of sectors in the partition" in the partition table entry was wrong (see https://en.wikipedia.org/wiki/Master_boot_record#PTE).   The number there was the LBA or sector number of the end of the partition, i.e. the start sector plus the size, instead of just the size.   This really shouldn't matter;  I don't think the bootstrap code looks at that field.  In any case it wasn't causing the failure.

When ImgBurn creates the ISO, it does a binary copy of the .ima disc image into the ISO file, without modifying it.   Those bytes are stored contiguously in the .iso file, and it's relatively easy to find the location.  (In my case, it was always at offset 0x81000.)  I verified that the MBR with it's bootstrap code hadn't somehow gotten mangled in that step.

I have some code I wrote a while back to read the MBR of a hard drive or flash drive (actually, the entire "hidden" system area from sector 0 to the start of the FAT partition) and write that to a file.  This is how I know that the MBR that ImgBurn writes to the .ima isn't the same.

I used Visual Studio Community Edition's binary editor to open up the ISO file, and copy bytes 0x0 thru 0x1bd from the flash's MBR to the MBR image at offset 0x81000 of the ISO.  And that worked!  Now the ISO produces a CD that actually is bootable!  (Well, OK, it doesn't boot successfully everywhere, but it does boot up on the system I wanted to used it for.   And in none of the failure cases am I getting the "missing operating system" error anymore, so those failures must be some other problem.   A problem with the payload, not the ISO creation process.)

I don't know why ImgBurn is ignoring the correct (at least in my case) bootstrap code from the source drive and substituting it's own.  I assume there I some reason for this.  But the boot code that ImgBurn provides is obviously not robust enough to work with any operating system.     (The Seagate tools use SYSLINUX and something called "Tiny Core Linux".)

 

 

ImgBurn.log

[dbminter]

You said you're trying to create an ISO from files from a bootable flash drive with ImgBurn?  ImgBurn doesn't support bootable flash drives for boot images as far as I know.  So, even if you extracted the boot image from a bootable flash drive, copied over the contents from the flash drive, and created an ISO, I don't think it would work.  LUK might know some bootable settings to change to do this, but as far as I know, this won't work.

[LIGHTNING UK!]

SeaTools Legacy is the one you want for it being a bootable ISO.

Regarding the program, I don't think anything other than floppy and optical drives have really been used / tested with the extract boot image stuff - although I guess at the time of implementation, I must have done something or the code wouldn't exist at all.

The program doesn't actually dump the entire drive, it only dumps the partition (corresponding to the drive letter) you select - partition is specifically mentioned in the message box that pops up. So that's why the MBR is different to that of the actual drive, it doesn't read the one on the physical drive - It has its own within the code... one from MS I guess, as that's what I'm running.

I do not know the ins and outs of the MBR and I guess I hoped one would work for all.... obviously that isn't the case.

There is no way to read the entire physical drive to a raw image within the program, but it sounds like that's what you're after.

Thank you for reporting the issue with the partition's 'number of sectors' field in the partition table. I was using a variable containing the size of the entire boot image rather than just the size of the partition. That has now been corrected.

 

 

 

[Die In Sente]

Thanks for the response, Lightning!

Actually, there shouldn't be any problem with reading the entire physical drive, or just the MBR.  As I said above, I wrote code to do that a long time ago.   (I wanted create backup copies of hard drive partition tables after having been burned too often by partition utilities -- Partition Magic; Windows disc manager -- corrupting the partition tables.)   If ImgBurn is doing a direct binary copy of the entire partition, I'm guessing you're running with sufficient privileges to access the rest of the drive as well.

AFAIK, extracting a boot image from a floppy and from a flash drive should be just the same, but perhaps you know something I don't.

I'm guessing the MBR you insert was written to work with some versions of Windows pre-execution environment, but short of disassembling the bootstrap code I couldn't say specifically why it doesn't work with other OSes.

One experiment I did, which I omitted from my post, was to create an image file of the entire flash drive myself, and use that, but then ImgBurn complained that the signature of the MBR didn't match what it expected, so it went ahead and substituted it's own bootloader anyway.  :-(

 

[LIGHTNING UK!]

I agree, there's no problem to read the entire drive, it just wasn't written to do that.

It only opens \\.\C: or whatever and so doesn't have access to the MBR.

I spent a bit of time yesterday adding 'Physical Drive #x' entries to the list, so now there is indeed a method dumping the entire drive.

The warning about unknown signatures isn't an issue (for people that know their MBR is correct), it's just to give people a heads up that things might go wrong. Seeing that message doesn't substitute in the program's built in MBR, so if you extracted your own dump of a full physical disk, that's what you'd have ended up with in the ISO - unedited.

I was playing around with SeaTools on a 4GB stick yesterday doing various things and I couldn't get it to boot in vmware (at all), which is a shame. I guess I need to dig out a 2nd real machine to test it on - mine never really gets rebooted.

I didn't ever get a message about missing OS though, it just came up with a syslinux message and sat there forever. That was with an ISO made where I'd only fixed the 'number of sectors' issue and ISO's where the full physical drive was being dumped and used as the boot image. Maybe I should give VirtualBox a go too to see if it behaves differently.

[dbminter]

Off topic, I know, but you actually had problems with Partition Magic?  It was one of the few utilities that did what it did that I found that actually worked.  I miss it tremendously, along with PowerQuest's Drive Image.  DI was also the first utility of its kind I ever used that did what it did and did it well.

[Die In Sente]

On 1/8/2019 at 8:40 AM, dbminter said:

Off topic, I know, but you actually had problems with Partition Magic?  It was one of the few utilities that did what it did that I found that actually worked.  I miss it tremendously, along with PowerQuest's Drive Image.  DI was also the first utility of its kind I ever used that did what it did and did it well.

Yes, on the whole Partition Magic was a great utility and I used to use it a lot back in the day.  To be fair I only recall it failing and corrupting the partition tables just once in many, many, uses.   IIRC, the way PM worked was it would not actually execute your changes right away, but just keep them queued up until you told it to commit the changes to the disk.  The one time I had problems, I decided that maybe I had accumulated too many changes for it to do all at once (delete this one, shrink that one, move this one, and then expand it...).   After that incident, I was always careful do just one change at a time, commit it and then reboot, before making the next change. and never had a failure again.

[dbminter]

Yes, as a matter of habit, I always only queue up one task at a time.  And, yes, PM did queue up operations.  I think every partition management software I've ever used did that.

 

If the software has a bootable disc option, I always use that to boot out of Windows to perform partition operations.

 

Yeah, for whatever reason, when tasks are queued, there's a greater likelihood one task won't work for whatever reason.  Plus, if one task doesn't complete, the rest of the queue is abandoned and you lose all the work you put into them.  Hence, I learned a long time ago to just queue up 1 task at a time.