From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LeaX8-0006AG-HA for mharc-grub-devel@gnu.org; Tue, 03 Mar 2009 14:44:06 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LeaX7-00069l-4v for grub-devel@gnu.org; Tue, 03 Mar 2009 14:44:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LeaX6-00069I-Ki for grub-devel@gnu.org; Tue, 03 Mar 2009 14:44:04 -0500 Received: from [199.232.76.173] (port=40493 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LeaX6-000696-Al for grub-devel@gnu.org; Tue, 03 Mar 2009 14:44:04 -0500 Received: from fg-out-1718.google.com ([72.14.220.159]:56659) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LeaX5-0003Jz-7b for grub-devel@gnu.org; Tue, 03 Mar 2009 14:44:03 -0500 Received: by fg-out-1718.google.com with SMTP id l27so126764fgb.30 for ; Tue, 03 Mar 2009 11:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=smrDDoAujJT0WW6Bypi5n2Kdp22GF45PNsOI70T84Xs=; b=mYO4T8tnWuR87eR5U4LCNAVjm2hn0Cad7PyWMN6L/UIESZ9BTL3uzagPL8JvJWkY4R uQwJGVEqYLn2N56i9MNVoRqEhurx8TU86A4LnVRfEhu34E4BOXNXOAGtmR/npTwfXDMU zksYAzfiV7PBF2pfAUWxcC7G/K+EeMwQ8B5Cc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=rJK+jKKkfd9UN4XFxv02nHLfRe3RMxdhAou+6NfQALwZsRfyiUhTxpp8jgg6gKzYpI xqN+NX23Rr0e7qYz4rQfn9PI2B5ykh5YH3R1RHawES5nPZQVwAhoT2AWEH80h4QTFDbV GWgvLtZ9Ym+Poocd3WjY7VFfJmSJ4++rlbefA= Received: by 10.86.59.2 with SMTP id h2mr407793fga.30.1236109441634; Tue, 03 Mar 2009 11:44:01 -0800 (PST) Received: from ?192.168.1.2? (20-72.3-85.cust.bluewin.ch [85.3.72.20]) by mx.google.com with ESMTPS id 4sm1077406fge.24.2009.03.03.11.44.01 (version=SSLv3 cipher=RC4-MD5); Tue, 03 Mar 2009 11:44:01 -0800 (PST) Message-ID: <49AD8881.3000903@gmail.com> Date: Tue, 03 Mar 2009 20:44:01 +0100 From: phcoder User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: The development of GRUB 2 References: <49AD55C3.9030202@gmail.com> <49AD738E.4070000@gmail.com> In-Reply-To: <49AD738E.4070000@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Solaris assumptions X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 19:44:05 -0000 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