j
: Next unread message k
: Previous unread message j a
: Jump to all threads
j l
: Jump to MailingList overview
Hi all,
I've had a bug report off-list indicating that r1199 broke booting Solaris from hard disk. Some investigation shows that the simple reason is because the boot list in arch/sparc32/openbios.c is missing a slice letter, and so the boot device in romvec is set incorrectly.
As the disk device in OpenBIOS/QEMU is effectively modelled as sd(0,0,0), then I believe the correct solution should be this:
diff --git a/openbios-devel/arch/sparc32/openbios.c b/openbios-devel/arch/sparc32/openbios.c index abdfe7c..6d1c3dc 100644 --- a/openbios-devel/arch/sparc32/openbios.c +++ b/openbios-devel/arch/sparc32/openbios.c @@ -887,7 +887,7 @@ arch_init( void ) push_str("floppy"); break; case 'c': - push_str("disk"); + push_str("disk:a disk"); break; default: case 'd':
Unfortunately I only have a couple of SPARC disk images as my main test suite is ISO based, and so while it works for me (and the original reporter), I'm a bit nervous about just applying the change as-is.
Can anyone confirm that my understanding of Solaris slices is correct, and that this is indeed the correct solution to the problem?
Many thanks,
Mark.
On 08/12/13 12:43, Mark Cave-Ayland wrote:
Hi all,
I've had a bug report off-list indicating that r1199 broke booting Solaris from hard disk. Some investigation shows that the simple reason is because the boot list in arch/sparc32/openbios.c is missing a slice letter, and so the boot device in romvec is set incorrectly.
As the disk device in OpenBIOS/QEMU is effectively modelled as sd(0,0,0), then I believe the correct solution should be this:
diff --git a/openbios-devel/arch/sparc32/openbios.c b/openbios-devel/arch/sparc32/openbios.c index abdfe7c..6d1c3dc 100644 --- a/openbios-devel/arch/sparc32/openbios.c +++ b/openbios-devel/arch/sparc32/openbios.c @@ -887,7 +887,7 @@ arch_init( void ) push_str("floppy"); break; case 'c':
- push_str("disk");
- push_str("disk:a disk");
break; default: case 'd':
Unfortunately I only have a couple of SPARC disk images as my main test suite is ISO based, and so while it works for me (and the original reporter), I'm a bit nervous about just applying the change as-is.
Can anyone confirm that my understanding of Solaris slices is correct, and that this is indeed the correct solution to the problem?
In actual fact, it seems that this regression was a combination of two other bugs exposed by recent changes which have now been fixed in SVN. So I'm currently planning to leave this as it is unless anyone feels strongly otherwise...
ATB,
Mark.