Jump to content











Photo
- - - - -

Grub4DOS issue


  • Please log in to reply
5 replies to this topic

#1 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 13 January 2011 - 04:06 PM

I do not know wheter this is an issue of
  • Grub4Dos
  • Oriensol's hddimage.cmd based on Jaclaz's mbrbatch/mkimg batches
Maybe somebody moves this topic to the logical better location.

What happens:

Using hddimage.cmd I create either Firadisk or WinVBlock images and boot into them from Grub4Dos.
Both give a warning message:
g4d_sectors_fira.gif
g4d_sectors_wvb.gif

I think that FiraDisk and WinVBlock are innocent.
It is either an issue of Grub4Dos or hddimage.cmd

Peter

#2 sbaeder

sbaeder

    Gold Member

  • .script developer
  • 1338 posts
  • Location:usa - massachusettes
  •  
    United States

Posted 13 January 2011 - 08:19 PM

I think that FiraDisk and WinVBlock are innocent.
It is either an issue of Grub4Dos or hddimage.cmd

What does the menu.lst look like? Are you using memdisk?

Looks like somehow the calculations of the "hard disk" structure aren't alinging with the expected value...
:)
Scott

#3 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 13 January 2011 - 08:38 PM

In both cases the same menu.lst entry, no use of MEMDISK:
map --mem /I386/nativeEx_R_XP.IMG (hd0)

map --hook

chainloader (hd0,0)/NTLDR

Peter

Currently I have the feeling that also Grub4Dos is innocent.

My "Bug" candidate now is hddimage.cmd

But that's only a feeling, maybe wrong.

Peter

#4 sbaeder

sbaeder

    Gold Member

  • .script developer
  • 1338 posts
  • Location:usa - massachusettes
  •  
    United States

Posted 13 January 2011 - 09:40 PM

My "Bug" candidate now is hddimage.cmd

From the post on hddimage (I'm guessing from a search this one)

It takes a filename for the disk image, a size in bytes (with optional K,M or G suffix for KB, MB or GB) and an optional /R parameter to create a disk image rounded to cylinder boundary.

Did you use the "round" parameter? If not, then that might explain this, since it things (from adding up all the sectors in the partition table, that it is LESS that what there should be if it multiplies out the Cylinder/Head/Sector (i.e. 14x255x63 = 224910 but you only had a file of size 217195

BINGO...On the same page, later down it says...
Use the optional round-cylinder option (/R) to ensure image ends at cylinder 

boundary  Using /R will prevent the grub4dos warning while mapping the drive

So try that! :)

:mellow:
Scott

#5 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 14 January 2011 - 01:27 PM

Many thanks sbaeder! :thumbup:

Issue fixed with the /R switch!

Peter ;)

#6 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 15 January 2011 - 11:16 AM

To further clarify the non-issue (it falls in category "RTFM" :thumbsup:), grub4dos analyzes the CHS data in the partition table of an image it maps, checking:
  • that partition table has data conforming to "Cylinder boundary respected" partition style <- this is ALWAYS done by the batches
  • that there are no "exceeding sectors" <- this is done by hddimage.cmd ONLY if the /R switch is used

If something is not OK, a WARNING (NOT an Error) is thrown.

In other words, you can use "not /R" made images allright, up to you if you want to suppress the WARNING by setting grub4dos to "errorcheck OFF":
http://diddy.boot-la....htm#errorcheck

:ph34r:
jaclaz




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users