> > > Alright, but here's the rub. If a drive can be booted by a machine. Why > can't it boot from Qemu if it's accessing the raw disk via the windows > interface? This needs no messing with bios or disksize to boot of a > regular machine. >
I hope someone else will chime in, but my guess is that the problem lies in that an MS Windows "drive" is really a partition, not the entire drive. Under Windows you're specifying the equivalent of the Linux /dev/hda1 , /dev/hda2, /dev/hdb1, /dev/hdb5 and not actually /dev/hda or /dev/hdb. In other words, to QEMU it looks like the drive got chopped off at some point. All of the data before a certain point and after another point on the HD is simply missing (and the indexing is incorrect if a non-zero number of bytes have been chopped from the beginning of the disk). I'm not sure if MS Windows includes the MBR in the first drive on the disk. In order to pass the "D drive" to qemu, and actually give QEMU access to the entire raw HD, the "D drive" partition would have to fill the entire HD, and MS Windows would have to make the MBR available as part of the first (only, in this case) partition on the HD. Presumably, you'd like QEMU to make up a fake partition table/MBR to present to the guest OS so that the guest OS sees a self-consistent disk. -Karl _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
