Jump to content











Photo
- - - - -

Error "bad blocks" when starting Ghost Solution from Multiboot USB

multiboot grub4dos symantec ghost solution suite bad blocks

  • Please log in to reply
5 replies to this topic

#1 sibicht

sibicht
  • Members
  • 3 posts
  •  
    Germany

Posted 13 September 2012 - 10:17 AM

Hello everybody,

I have a problem related to the topic described in the following thread:
http://reboot.pro/7437/ (Problem with GHOST)

What I have done so far:

I have used the program RMPREPUSB v.2.1.648 to make a 32GB USB Stick bootable (FAT32, install grub4dos 0.4.5c).
I have created menus entries loosely based on WINFIRA (http://www.scribd.co...aDisk-RMPrepUSB)

So far, I have managed to get most of the ISOs and floppy disk images to boot.

However, I am having some trouble getting images with Symantec Ghost Solution Suite 2.5 to run.
The included Ghost Boot Wizard allows the creation of several combinations of operating systems and bootable media:

PC-DOS/MS-DOS/Windows PE/Linux and Floppy Disk Set/VMware Virtual Floppy/USB Disk/ISO Image.

Using a medium created this way usually works flawlessly to boot, integrating it into my multiboot USB-stick however does not.

Of particular concern of the above combinations are PC-DOS on VMware Virtual Floppy (creates a 2.88 MB image) and PC-DOS on ISO-Image (creates a 28.868.608 byte ISO, containing a file OSBOOT.IMG sized 24.643.584 bytes in its root, which itself contains the boot files that are also on the 2.88 MB floppy image you can create (IBMIO.COM, IBMDOS.COM, Ghost program files etc.)

The most success I have had so far was using the following two entries (from tinybit's posts in the above referenced thread):

title 9. Test GSOL25 (2.88MB Floppy)a\n
map (hd0,0)/test.img (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
map --floppies=1

and

title 13. Test ISO \n
map (hd0,0)/gsol25msdos.iso (0xff)
map --hook
root (0xff)
map /osboot.img (hd0)
map (hd0) (hd1)
map --rehook
root (hd0,0)
chainloader +1

Or as an alternative with memdisk:

kernel /syslinux/memdisk
initrd /test.img

All three entries seem to boot up just fine (the OS is being started, the program as well), but the Ghost program shows the following (each time chosing YES):
Question: (1801) Bad block(s) encountered on read - continue anyway? (Yes/No)
Question: (1815) Ignore subsequent bad blocks? (Yes/No)

Additionally, the error is elaborated with the following line:

Bad block(s) encountered on read: Int13 error: invalid function in AH or invalid parameter(0x01)

After that, the program SEEMS to run just fine.

However:

Do I have to worry about this error or can I safely ignore it? As far as I understand it, the error is caused by Ghost trying to access some parts of the mounted image that it can not. (And not some part of any of the HDDs in the system I may want to use Ghost on to create images from, which would be fatal, am I right in this assumption ?)

Is there a way to boot these images which will remove the error? Some additional parameters / other ways of doing this that I in my fairly inexperienced ignorance am not yet aware of?

Additional information that may help:

When using "map (hd0,0)/test.img (fd0)" on the command line instead, I get the output:

FAT12 BPB found with 0xEB (jmp= leading the boot sector
info: BPB total_sectors(5757) is less than the number of sectors in the whole disk image(5760).
probed C/H/S = 80/2/36, probed total sectors = 5757
floppies_orig=0, harddrives_orig=2, flippies_curr=1, harddrives_curr=2

With the ISO, I get the following output after "map /osboot.img (hdo)":

Warning: total_sectors calculated from partition table(48195) is greater tahn the number of sectors in the whole disk image (48132). The int13 handler wiss disable any read(write operations accross the image boundary. That means you will not be able to r/w sectors 48132-48194, though they are logically inside your emulated virtual disk (according to the partition table).
probed C/H/S = 3/255/63, probed total sectors = 48195
IMHO this may be directly related to the error I get from Ghost.

Thanks in advance for any help/help attempts/suggestions/etc

P.S:
I tried to attach the first 512 bytes of the OSBOOT.IMG, as this seemed to have helped troubleshooting in the referenced thread, however I could not find any way to upload file attachements, so I just post the content of the hexdump as plain text:

FA EB 0A 53 59 4D 43 20 76 31 2E 34 00 33 C0 8E D8 8E C0 8E D0 BC 00 7C FB BE 00 7C BF 00 06 B9 00 01 F3 A5 50 BF 2A 06 57 CB CD 12 48 A3 AA 07 B1 06 D3 E0 A3 A8 07 33 C0 CD 13 A1 A8 07 BF 00 00 8E C0 B4 00 B0 02 B1 00 B5 80 BB 01 00 BA 00 00 E8 9E 00 73 03 E9 80 00 A1 A8 07 BF 00 02 8E C0 B4 00 B0 03 B1 00 B5 80 BB 02 00 BA 00 00 E8 80 00 72 65 A1 A8 07 8E C0 8B 1E AA 07 26 89 1E B9 03 FF 1E A6 07 BE BE 07 A1 A8 07 8E C0 8B 44 08 26 A3 B5 03 8B 44 0A 26 A3 B7 03 33 C0 8E C0 8A 64 01 8A 44 02 8A 4C 03 B5 80 8B 5C 08 0B DB 74 1F 8B 54 0A BF 00 7C E8 37 00 72 1C BF 00 7C 26 81 BD FE 01 55 AA 75 10 B8 50 00 8B EE 06 57 CB BE 79 07 E8 0E 00 EB FE EB 05 00 00 00 00 00 BE 93 07 EB EF B4 0E BB 07 00 AC CD 10 38 3C 75 F9 C3 BE 00 80 88 64 10 88 44 11 88 4C 12 88 6C 13 33 C0 C7 04 10 00 C7 44 02 01 00 89 7C 04 8C 44 06 89 5C 08 89 54 0A 89 44 0C 89 44 0E B4 08 8A 54 13 CD 13 72 51 80 E1 3F 8A C6 F6 E1 B9 FF 03 F7 E1 3B 54 0A 74 04 7F 1B EB 05 3B 44 08 7F 14 8A 54 13 BF 05 00 B8 00 42 CD 13 73 2A 33 C0 CD 13 4F 75 F2 BF 05 00 B8 01 02 8A 6C 12 8A 4C 11 8A 74 10 8A 54 13 8B 5C 04 8E 44 06 CD 13 73 07 33 C0 CD 13 4F 75 E0 C3 0A 0D 49 6E 76 61 6C 69 64 20 70 61 72 74 69 74 69 6F 6E 20 74 61 62 6C 65 00 0A 0D 45 72 72 6F 72 20 6C 6F 61 64 69 6E 67 20 4F 53 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 01 01 00 04 FE 3F 02 3F 00 00 00 04 BC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA

#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 13 September 2012 - 11:54 AM

The "relevant" part of the hex you posted is the actual partition table:
Type Boot bCyl bHead bSect eCyl eHead eSec StartSector NumSectors 

#0 04 80 0 1 1 2 254 63 63 48132
That says that the image shoud contain 63+48132=48195 sectors, i.e. the image should be EXACTLY 48195*512=24,675,840 bytes
To avoid the grub4dos warning, simply get fsz from the dsfok toolkit:
http://members.ozema...eezip/freeware/
and make the file that size (a few 00ed sectors will be added to it):
fsz osboot.img 24675840
Or you could - but breaking the Cylinder/Head boundary current compatibility - reduce the size of the actual filesystem by 32256 bytes (it would need patching just a few bytes).
Same goes for the 2.88 floppy image, such an image is 5760 sectors and thus must have a size of 5760*512=2,949,120 bytes, in this case reducing the size of the filesystem by three sectors wouldn't "break" any compatibility, but it would still remain a "queer" image.

WHY the images were created with the "wrong" size is the actual question.

Try with the "fixed" size images and see if the "bad blocks" error still appears, it is possible that *somehow* the source files/.iso/whatever is corrupted.

:cheers:
Wonko

#3 sibicht

sibicht
  • Members
  • 3 posts
  •  
    Germany

Posted 13 September 2012 - 01:08 PM

Thanks for the answer, Wonko, I have tried a few of your suggestions as follows.

I padded the file OSBOOT.IMG to 24,675,840 bytes, then reinserted it into the ISO, using UltraISO. I noticed that the size of the ISO had doubled to 49.367.040 bytes, although UltraISO only shows the one file OSBOOT.IMG being inside.
Viewing the original ISO with an ISO-viewer-plugin for my favourite file manager TotalCommander, i see a hidden directory named "boot.images" containing a file "harddisk.00" which is exactly 24.675.840 bytes as well. The new ISO contains this file as well, but due to the size I assume that somehow the same place was being referenced twice somehow?

I tried the new, bigger ISO nonetheless like this:

map (hd0,0)/gsol25msdos2.iso (0xff)
map --hook
root (0xff)
map /osboot.img (hd0)
map (hd0) (hd1)
map --rehook
root (hd0,0)
chainloader +1

It boots the same way as before, except that the map command no longer gives any warning about incorrect sectors. The warning in GHOST after booting are still there and still the same though.

Alternatively I tried copying the padded OSBOOT.IMG directly to the USB-stick and booting it with same result (no warning display during booting, but error still in Ghost) using this:

map (hd0,0)/osboot.img (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
map --floppies=1

As for the floppy images, they are already being created 2,949,120 bytes of size, so I am not exactly sure what you are suggesting I should/could change to make them work. Please elaborate.

Ideally I would prefer to integrate one of the floppy images, being 3mb compared to 25mb of the ISO (although not really a deal breaker on a 32GB USB).
It is still bugging me to find out where exactly the problem is though :)

As a different approach, using the Ghost option to create a bootable USB (which I have tried on an 8GB drive), is there any way to create an image from there that you can reduce in size and get to boot from my multiboot USB somehow?
The created 8GB uses FAT32. I have managed to create a copy from it using WinImage, but I am not sure how to proceed from there (How to convert, what best to convert it to, how to start from my multiboot).

I will continue to try, any help is appreciated.

#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 13 September 2012 - 02:17 PM

FAT12 BPB found with 0xEB (jmp= leading the boot sector
info: BPB total_sectors(5757) is less than the number of sectors in the whole disk image(5760).
probed C/H/S = 80/2/36, probed total sectors = 5757
floppies_orig=0, harddrives_orig=2, flippies_curr=1, harddrives_curr=2

Then the bootsector of the floppy image is corrupted.
grub4dos sees 5757 sectors instead of 5760.
Check two bytes at 0x13 of the first sector of the floppy image.
They should be 8016. (=0x1680=5760).
If - for any reason - they are 7D16 the behaviour is nicely explained


Rule of the thumb is to NEVER, for ANY reason, use a .iso boot editor on bootable .iso images, there are tens of things that can go "wrong" when doing so, or, if you prefer, it is MUCH safer to rebuild the .iso.

But why would you want the .iso at all?
I mean just extract the image, patch it and chainload the image directly from grub4dos, I mean:

map (hd0,0)/gsol25msdos2.iso (0xff)
map --hook
root (0xff)

find --set-root /osboot.img
map /osboot.img (hd0)
map (hd0) (hd1)
map --rehook
map --hook
root (hd0,0)
chainloader +1


:cheers:
Wonko

#5 sibicht

sibicht
  • Members
  • 3 posts
  •  
    Germany

Posted 13 September 2012 - 03:09 PM

For the floppy: Yes, you were right, there was 7D16 - I changed those 2 bytes, but still the same error in Ghost (no longer warning in grub4dos thoughj).
For the rule of thumb: Duly noted, thanks.
For the ISO: I do not need the ISO, I have just been experimenting with all kinds of formats with trial and error to increase my horizon, intending to finally use whatever is working, discarding the rest. That doesn't mean im not interesting in the more elegant solutions that might be out there.

I mean just extract the image, patch it and chainload the image directly from grub4dos, I mean:...

I already tried that, sadly with the same result as before. Everything boots, but Ghost still throws this error.
Might this have something to do with the "Int13" part of the error message? I read that there might be issues with certain programs due to the protected/real mode problems.
Or those people at Symantec just like messing with people's heads :cold:
Im taking a break with this line of problems for now (due to more pressing matters).
Thanks again for your help. :good:

#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 13 September 2012 - 03:24 PM

I already tried that, sadly with the same result as before. Everything boots, but Ghost still throws this error.
Might this have something to do with the "Int13" part of the error message? I read that there might be issues with certain programs due to the protected/real mode problems.
Or those people at Symantec just like messing with people's heads :cold:

The second you said. :whistling:

If I were you I would try making a Ghost bootdisk using as "base" MS DOS 7.x (windows 9x)
It is possible that it is a combination of IBM DOS with your hardware/BIOS.
http://www.symantec....t&id=TECH107936
Cannot say why the guys at Symantec seemingly suggest to not use the 8.x (Windows ME but also "DOS boot disk" in 2K/XP), but later tell you which files on the Me bootdisk are not needed :dubbio:.
Please also note how the links in the above page all lead to "Nathan" :w00t: :ph34r:

Posted Image
Hi, I'm Nathan. How can I help?

Example: How do I install on another computer?


:frusty:

Mind you that is the example of a question! (and lacks, besides any form of intelligence, the §@#çing subject!)
A rare case that makes you reconsider how after all even Bob or Clippy weren't that bad.....:rolleyes:

The usual reference for ghost related matters is radified.com:
http://ghost.radified.com/
and it's forum, it is very possible that you are not the only one with this kind of issues.

:cheers:
Wonko





Also tagged with one or more of these keywords: multiboot, grub4dos, symantec ghost solution suite, bad blocks

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users