Correction: Third point goes away as it was revealed that it was enough
to put these 2 structures in multiboot payload. Now fixed solaris kernel
boots fine with latest svn+my elf fix. And the first two points are
solaris bugs
phcoder wrote:
My previous letter was scarce on details. Here some more comments:
grub1 and grub2 if they detect an elf executable with AOUT_KLUDGE bit
set they follow the specification and load the file using addresses from
multiboot header. grub-solaris however in the same case uses elf
headers. This error has been known to sun for some moment but for an
unknown reason they don't fix their multiboot header.
2) Some kind of in-kernel debugger tries to open the kernel file. For
ths it uses the zeroth argument from command line and assumes it's a
solaris filename on disk pointed by BOOTDEV. It doesn't work in many
case e.g. if kernel is loaded with drive prefix
3) I made grub2 put mbi, cmdline and mmap before the protected mode heap
. With this I'm able to boot solaris succesfully. If I use, however
standard code it creates a range of nasty effects including out of
memory error, kernel panic and triple fault
First two are entirely sun's fault but some kind of option to make grub2
behave like grub-solaris is possible.
The third one is more controversial for already the fact that more OSes
fall into this trap. Of course it's against specification but I feel
like grub2 should be able to boot the same kernels as grub1. For a very
list to avoid a flow of bug reports and to help in transitioning to
grub2. These issues are fixed in multiboot2 because it doesn't use
pointers anymore.
phcoder wrote:
Hello, investigating Solaris/OpenSolaris/Pulsar kernel I found that it
makes assumptions which are false in grub2 environment. Now we should
decide what to do. Assumptions:
1) Bad multiboot header. AOUT_KLUDGE bit is set but no aout multiboot
fields. Actually the image is elf. I fixed it by just putting this bit
to zero in the binary. It's possible to add a workaround but it's
basically a sun's issue
2) solaris is able to open its own kernels file by the name from
grub's cmdline. It's also a bad assumption which is entirely sun's fault
3) mbi, cmdline and mmap are in low memory. These bits are
discuttable. Specification doesn't guarantee these parts to be on low
memory however different OSes assume that and it makes mapping memory
much easier. If we want to superseed grub1 we should use daChaac's
memory management and allocate the space for these parts on low memory
--
Regards
Vladimir 'phcoder' Serbinenko
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
