From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OtwxU-0000xk-Sc for mharc-grub-devel@gnu.org; Fri, 10 Sep 2010 02:19:37 -0400 Received: from [140.186.70.92] (port=45711 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OtwxR-0000w1-N0 for grub-devel@gnu.org; Fri, 10 Sep 2010 02:19:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OtwxP-0005Kl-Pa for grub-devel@gnu.org; Fri, 10 Sep 2010 02:19:32 -0400 Received: from mail-wy0-f169.google.com ([74.125.82.169]:37200) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OtwxP-0005Io-Iz for grub-devel@gnu.org; Fri, 10 Sep 2010 02:19:31 -0400 Received: by mail-wy0-f169.google.com with SMTP id 36so2810979wyb.0 for ; Thu, 09 Sep 2010 23:19:31 -0700 (PDT) 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=7gn8iPAbM12CAeh/D4A6t8yN1j/+i+2cnORCHGM5b94=; b=Jfz3Py+zXAZxeem4AOO1qk5mkmT4SOMJmcgh6PRoFDzg87zkyx8EpHx8OtepNt/bAm DnMp++lZQPdmk2gmPJABoTxU7PzDvxBnNve2f38KG++Uya5ANvVq1Px0QgOLnMig1qf5 g+giXQHpBPjbWDvijnRlHGiK6eC17Y7HFB2f8= 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=lFqT0p1fjfaCp9nc7GFIHmIxg4jYvQx4BxXiEcbsB2mpX/6IErHVt66Z1NvqlwG4f8 Lm5/JcVXjCWRPvF/4tcxEoul8MEUg1IiWiODpgHl65RnaXdrAV/TYTw3ipK+JOmv2IXN UO4NZ282LSae7XvHOGD1OzzSavvunjws2dOdA= Received: by 10.227.129.7 with SMTP id m7mr271774wbs.44.1284099571249; Thu, 09 Sep 2010 23:19:31 -0700 (PDT) Received: from debian.yeeloong.phnet (vig38-2-82-225-223-122.fbx.proxad.net [82.225.223.122]) by mx.google.com with ESMTPS id u11sm1424251weq.7.2010.09.09.23.19.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 09 Sep 2010 23:19:30 -0700 (PDT) Message-ID: <4C888D4D.3010301@gmail.com> Date: Thu, 09 Sep 2010 09:31:25 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux mips64; en-US; rv:1.9.1.11) Gecko/20100805 Icedove/3.0.6 MIME-Version: 1.0 To: grub-devel@gnu.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Questions regarding bzr Install Branch 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: Fri, 10 Sep 2010 06:19:35 -0000 On 09/04/10 11:27, KESHAV P.R. wrote: > How to detect whether a system has booted using (U)EFI and if so what > is the efi processor arch? This is not only for the grub-install > script but also the configure script. > > Most of systems supporting EFI also support BIOS. Also some users like me have an annoying custom to moving HDDs from one computer to another. The HDD which is in this machine right now is even bootable on 2 different ISAs (mipsel, i386 and x86_64). So the default behaviour should be to install every available platform (we have a task on savannah for this). > If configure is run in a non-Apple UEFI system (mostly x86_64-efi and > without bios compatibility) configure still sets up the makefiles as > i386-pc. My suggestion would be to test for existence of either > /proc/efi dir or /sys/firmware/efi dir to confirm that the kernel has > booted in efi. It feels like such kind of check is outside of the scope of configure. Also most of the users obtain their binaries from package manager in which case the firmware of build machine is 100% irrelevant. > Even if the dir(s) exist(s), I do not know of any way > how to detect the booted efi arch (which can be independent of linux > kernel arch). My question is if a linux system is booted using grub2 > efi (arch unknown to the user) and he/she runs configure in that > system, is it possible for the configure system to detect the platform > (efi) and the efi arch (whatever it is) correctly. > > I recommend in such case to build and install both variants and let the firmware take whatever it needs. > If the user runs ./configure in a non-Apple Pure UEFI system it should > automatically setup > > AFAIK most of "pure"-EFI systems are actualy servers. I expect server admins to have a smallest clue what system they are running > ./configure --with-platform=efi --target=(detected efi arch) > > instead of > > ./configure --with-platform=pc --target-i386 > > which is what happens currently. It's an idea to make --with-platform a comma-separated list and have aliases efi64 and efi32, however the amount of work for it compared to benefits is way too big, you're better of with a simple build script like I have. > Another question would be detecting > efi boot when "noefi" kernel parameter is used (in which case the > /rpoc/efi or /sys/firmware/efi dirs will not exist). In such a cease > dmesg output may be useful. > > "noefi" is specifically to ignore any possible EFI. If you're able to distinguish efi and non-efi system both booted with noefi parameter it's a bug. > Regarding grub-install in install branch, does it detect the efisys > partition by checking the partition guids of the device (in case of > GPT) or checking for 0xEF type code (in case of MBR) or does it use > parted to check for existence of "boot" flag on any partition of a GPT > disk and then checking for FAT16/32 FS? I suggest adding guid > detection functionality in grub-probe for this purpose as that would > be the most accurate way of detecting efisys part (atleast in a GPT > disk). Also UEFI spec does not enforce any "only 1 efisys partition > per disk" rule. So if there are multiple FAT32 efisys partitions in a > disk, it is better to use the first such partition in the disk for > setting grub2 efi. > > Right now it doesn't do anything fancy, it just relies on user to mount it at the right place. > Finally since efi allows multiple bootloaders, apart from the > /EFI/BOOT or/EFI/GRUB or > /EFI/, I would like to setupgrub2 > in the following way :- > > /EFI/GRUB2 and/EFI/GRUB2_EXP and such. > > I implemented --bootloader-id in install branch. > I suggest a slight modification in grub-install script like below - > > grub-install --modules="" > --root-directory="" > --grub-prefix="/EFI/grub2_Keshav" /dev/sda > > You shouldn't ever use --modules. > such that --grub-prefix overrides all grubprefix env variables in the > grub-install script and allow the user to specify in which folder in > the efisys should grub2 be installed. I may want to install grub2 > mainline in/EFI/grub2 and grub2 experimental branch in > /EFI/grub2_exp and the install branch in > /EFI/grub2_ins etc. > > The current grub-install script sets up grub2 in /boot/grub or > /boot/. This --grub-prefix parameter in grub > install will enable the grub2 dir naming independent of the renaming > if the grub utils according to program_transform_name parameter passed > to configure. > --grub-prefix is a bad idea because you'll always find users who'll do --grub-prefix= and have their root filled with modules. > Regards. > > Keshav > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > -- Regards Vladimir 'φ-coder/phcoder' Serbinenko