grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Solaris assumptions


From: phcoder
Subject: Re: Solaris assumptions
Date: Tue, 03 Mar 2009 20:44:01 +0100
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]