From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OobAf-0000GT-7O for mharc-grub-devel@gnu.org; Thu, 26 Aug 2010 08:03:05 -0400 Received: from [140.186.70.92] (port=50016 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OobAc-0000Bu-0y for grub-devel@gnu.org; Thu, 26 Aug 2010 08:03:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OobAa-0005ZW-EN for grub-devel@gnu.org; Thu, 26 Aug 2010 08:03:01 -0400 Received: from mail-wy0-f169.google.com ([74.125.82.169]:65220) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OobAa-0005ZL-AO for grub-devel@gnu.org; Thu, 26 Aug 2010 08:03:00 -0400 Received: by wyb36 with SMTP id 36so2457851wyb.0 for ; Thu, 26 Aug 2010 05:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=0zr+3kn+F0G6vOQorInsjnzQD5jZNgvpI7cub7i5clc=; b=tqCoow1C9W9zcN5S0TGcmHa7U0CjisH7U5bY9moQHuvrytM6mSUH/gbU9eFm2aPi7F fOfXQuxISnw10oOaPw6Pf6UMEZ4mNQkoYf9VqMJwgUvbQXmxhoPdupibJcwOYTit69ej Kx0nNeH68eMuakHcNmuJ04vaTJ9LR3JOoJuv8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=sfaD6IEHXg+SlBoYzcK1pGY6L+TmdFQM1VOBAvaAkBY79Y3cFHQenWcoJkR/5BkskR GfNQ3Fte+Am+XmOkYHk/KHCMTityrqjAezYHM6Zg5kjUkzx057K2fKUheaXG6fmydqKL y5mILDGeMHumFrnBeUCkPthCuevpWIpjesN2k= Received: by 10.227.146.149 with SMTP id h21mr8768540wbv.153.1282824179264; Thu, 26 Aug 2010 05:02:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.137.9 with HTTP; Thu, 26 Aug 2010 05:02:39 -0700 (PDT) In-Reply-To: References: <4C747249.4080205@gmail.com> <4C74E602.1060308@gmail.com> <4C762609.303@gmail.com> <4C76415C.2060609@gmail.com> From: "KESHAV P.R." Date: Thu, 26 Aug 2010 17:32:39 +0530 Message-ID: To: The development of GNU GRUB Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Completely disable graphics support in grub2 x86_64-efi X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 12:03:03 -0000 On Thu, Aug 26, 2010 at 17:17, Vladimir 'phcoder' Serbinenko wrote: > Nicest way would be to implement multiboot for efildr.-d do it myself > (and I still might). If > I had more time I efildr might be loadable by ntldr command. Also if > you chainload be sure to use dumped sector and not the one from the > compiled result. If you plan to implement this I can test it for you in real hardware. > It's usually better to make sane way work than reverting to > suboptimally designed one. >> I like the way UEFI works > The main part visible to user is loading files instead of sectors. > This is a good decision. However the rest is a mess. > Also coreboot+grub loads files too. I have known about coreboot but I do not want to mess up my bios. DUET acts like a uefi wrapper for bios. I used it because no "flashing the motherboard" was involved. I do not want to try flashing coreboot to my motherboard. >> and I >> have no plans to revert back to MBR partitioning for the sake of >> windows compatibility. > Robert investigated the issue following my idea of replacing MBR > sector on BIOS read calls. It was enough to make bootmgr work on > non-hybrid GPT. However ntoskrnl fails early. With some runtime > patching I think it's possible to achieve the goal however nobody > investig >> The tianocore guys recommended using OVMF under qemu or VirtualBox for >> UEFI booting, but the prblem is I want UEFI booting in real hardware >> using my real HDD (not some virtual HDD file). > With OVMF grub-efi works fine >> grub2 efi works fine in my VirtualBox 3.2.8 PUEL. IN edk1 duet it has these graphics problems. It works fine in edk2 duet. >> The bootsector files used by duet are > I specifically asked for the DUET qemu image. I'm in no mood to > assemble boot puzzle. Sorry, but i do not have a qemu image because I am using actual hardware. I guess you are asking for qemu image of my DUET USB pendrive. Can you provide link to instructions on how to create one? Can virtualbox be used to create the image. Regards. Keshav