Hi, i think this should help you:
(From the NOTES.TXT in the Folder linuxboot) - snip - The disk geometry nightmare =========================== The Linux HDIO_GETGEO ioctl() returns the geometry (cylinders/heads/sectors) of a hard disk. Unfortunately, these values are not always the same as that returned by the BIOS, especially the legacy INT 13/AH=08h interface (see http://www.ctyme.com/intr/rb-0621.htm). After some discussion on the SYSLINUX list, my solution (see http://www.zytor.com/pipermail/syslinux/2004-February/003269.html) was to patch the kernel to invoke the BIOS calls at startup, and modify the EDD device driver to expose those values under /sys/firmware/edd. My patch was accepted into Linux 2.6.5 (http://groups.google.com/groups?threadm=1xXh2-850-17%40gated-at.bofh.it) and modified somewhat in Linux 2.6.7 (http://article.gmane.org/gmane.linux.kernel/208395). So, our scripts can read the files under /sys/firmware/edd, use them to set some environment variables (LEGACY_BIOS_HEAD and LEGACY_BIOS_SECT), and fix the kernel's notion of the geometry by writing "bios_cyl:<C> bios_head:<H> bios_sect:<S>" into the /proc/ide/hdX/settings file. This corrects the values returned by HDIO_GETGEO, which both Parted and Dosemu use. Without this correction, Windows Setup creates a partition which its own loader cannot boot ("NTLDR not found"). I am not completely sure whether the partition table (more likely) or Dosemu environment (less likely) is responsible, but it does not matter because this fixes both. Note that /proc/ide/hdX/settings only exists for IDE devices. Browsing the Linux kernel source, I have some hope that most SCSI and RAID drivers already return the BIOS-friendly geometry in HDIO_GETGEO. So far, this hope has been validated by our users. If this turns out to be wrong, we will need to find some way to manually feed the geometry into Dosemu (easy) and Parted (hard). There is a related issue, which is that we assume BIOS device 80h (the boot device) is the one onto which we are installing. Our selection algorithm (look for amiraid/ar0, then ataraid/d0, etc.) is much too primitive and certainly wrong for complex multi-disk setups. This may be our biggest FIXME at present. - snap - Regards, Tobias Richter ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ unattended-info mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/unattended-info
