From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LeZ8e-0004DF-1z for mharc-grub-devel@gnu.org; Tue, 03 Mar 2009 13:14:44 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LeZ8c-0004Cw-4b for grub-devel@gnu.org; Tue, 03 Mar 2009 13:14:42 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LeZ8a-0004CU-Bu for grub-devel@gnu.org; Tue, 03 Mar 2009 13:14:41 -0500 Received: from [199.232.76.173] (port=59417 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LeZ8a-0004CR-4P for grub-devel@gnu.org; Tue, 03 Mar 2009 13:14:40 -0500 Received: from mail-fx0-f172.google.com ([209.85.220.172]:47479) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LeZ8Z-00071L-Lz for grub-devel@gnu.org; Tue, 03 Mar 2009 13:14:39 -0500 Received: by fxm20 with SMTP id 20so2555924fxm.42 for ; Tue, 03 Mar 2009 10:14:38 -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=8iKRy3IApMke12aFjd3JoYqJT/uof1Qg4gLNO6tgUPg=; b=IKsz3Xe4Zni6J6k/USi5Bj811VPgKj+ZqE1kkEGedauT/I0x+wlOfrJs/+/vbXBbAW xHGo5+sR21lFDbyXGVLgClf3iw8cTDuB34SqQ6cdIUAFL6ae6BHV/7rAN/mtUfGSO9XN n7P/1UzCyBZA4FSW72ZM2oi0j25BEp770Wz0w= 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=k6TrgJ6dXhE3zHBbqlAZhkkZecXtVRbnrOFsaHVJ/27JgYISfSx1PTdiqIYtkPSoPd 6DfskcmcYPgiBoxF3CO6KrfHt67N0ZoGDXplzu7LwQTsSybqMqL37IliRx7xbj7d/th6 9yEs0BC5F5Em/CuQNEr5UCujI3C3BS5WNdP4s= Received: by 10.86.27.9 with SMTP id a9mr2882385fga.39.1236104078874; Tue, 03 Mar 2009 10:14:38 -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 d4sm958969fga.25.2009.03.03.10.14.38 (version=SSLv3 cipher=RC4-MD5); Tue, 03 Mar 2009 10:14:38 -0800 (PST) Message-ID: <49AD738E.4070000@gmail.com> Date: Tue, 03 Mar 2009 19:14:38 +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> In-Reply-To: <49AD55C3.9030202@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 18:14:42 -0000 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