Martin Bochnig wrote (in response to my posting):
>>Bob Nestor wrote:
>>
>>With his patch I get the console output from PROLL. I was actually
able to boot the first stage >>bootstrap of the Debian Sarge
distribution. Unfortunately the patch doesn't solve the problem of
>>booting a Solaris installation CD, but I think this may be due to
a disk block size problem.
>>
>
>Very unlikely, it would definitely show further progress (at least
is this the case if you experience >such an issue on a real sparc box).
>The unique Solaris(2.)6++ install media (CD/DVD) layout is a ways
more suspicious candidate >here.
>Especially that those media contain ufs slices among others
(strange enough that they got more >than one slice at all).
>BUT, unfortunately is is either NOT the reasons, OR it is one of at
least two reasons.
>I got exactly the same behaviour when trying to boot Solaris(2.)
8_hw2004 from the raw "/" slice of >my physical hdd :(
I see the same thing with a NetBSD CD that I created for the Sparc
and it doesn't have any UFS partitions on it. While the Solaris CD
is constructed in a unique way this doesn't seem to explain what is
happening. I'm not familiar with the Debian Sarge CD format, but
there's something about it that permits QEMU to at least find and
load the first stage boot. The PROLL output from all three CDs
(Debian, Solaris and NetBSD) indicate non-zero partition offsets for
the Debian but all zero offsets for the Solaris and NetBSD CD. I
know for a fact that this isn't correct for the NetBSD CD as I dumped
the partition offsets when I created the CD. Based on this I agree
with you that it is at least one of the two reasons booting fails. I
haven't tried booting directly from the actual hard disk from my IPX,
but I'm getting an image of it to try that next. Things seem to run
differently with QEMU on Intel vs. Mac so I'm going to try both hosts.
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel