Ok, sounds good. Thanks for the quick reply.

--Henry


On Mon, May 14, 2012, at 12:28 AM, C. Masloch wrote:
> > However, I get a warning on boot: "InitDisk Warning: using suspect
> > partition Pri: 1 FS 0C with calculated values 970-42-42 instead of
> > 1018-8-40". I've tried partitioning the disk with different CHS values,
> > but it always complains that the calculated values are different than
> > those other values(I guess the bios supplies them). Neither set of
> > values are exactly the same CHS that I actually used to partition the
> > disk in the first place. Anyway I think it should be using lba anyway,
> > so does it even matter? and if it does, is there a way to fix it?
> 
> initdisk.c contains the following notice in one of the comments:
> 
> > However we need to be safe, and with varying CHS at different levels
> > that might be difficult. Hence we _only_ trust the LBA values in the
> > partition tables and the heads and sectors values the BIOS gives us.
> > After all these are the values the BIOS uses to process our CHS values.
> > So unless the BIOS is buggy, using CHS on one partition and LBA on  
> > another
> > should be safe. The CHS values in the partition table are NOT trusted.
> > We print a warning if there is a mismatch with the calculated values.
> 
> So that seems to be the warning you see. According to the notice, then,  
> this simply means the kernel determined that the exposed geometry[*] of  
> the actual CHS interface (as provided by _the currently running_ ROM
> BIOS)  
> doesn't match what was apparently used to record the partition table  
> entries' CHS information. If the ROM BIOS's interface works as it is  
> supposed to, this condition will not cause any further problems.
> (However,  
> primarily some boot loaders rely on the CHS information in the partition  
> table to be correct instead of re-calculating CHS information using the  
> LBA information as well as what a geometry query to the ROM BIOS
> returned.  
> These programs will fail to function correctly. If the boot process  
> appears to work correctly for you, then the loaders you are using are not 
> affected.)
> 
> [*] As usual, this generally does not directly correspond to a disk's  
> physical geometry nowadays.
> 
> Regards,
> Chris
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user

-- 
http://www.fastmail.fm - Choose from over 50 domains or use your own


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Reply via email to