All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: grub-devel@gnu.org
Subject: Re: Questions regarding bzr Install Branch
Date: Thu, 09 Sep 2010 09:31:25 +0200	[thread overview]
Message-ID: <4C888D4D.3010301@gmail.com> (raw)
In-Reply-To: <AANLkTimhnFfOgx1ZhE6z4qYe-3HmB4=mx0jWe_QQ=_9j@mail.gmail.com>

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
> <EFISYS_PART>/EFI/BOOT or<EFISYS_PART>/EFI/GRUB or
> <EFISYS_PART>/EFI/<VENDOR or DISTRIBUTOR>, I would like to setupgrub2
> in the following way :-
>
>   <EFISYS_PART>/EFI/GRUB2 and<EFISYS_PART>/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="<My list of modules for grub2 efi app>"
> --root-directory="<EFISYS_PART_MountPoint>"
> --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<EFISYS_PART>/EFI/grub2 and grub2 experimental branch in
> <EFISYS_PART>/EFI/grub2_exp and the install branch in
> <EFISYS_PART>/EFI/grub2_ins etc.
>
> The current grub-install script sets up grub2 in /boot/grub or
> /boot/<program_transformed_name>. 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



  parent reply	other threads:[~2010-09-10  6:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-04  9:27 Questions regarding bzr Install Branch KESHAV P.R.
2010-09-04 17:59 ` Seth Goldberg
2010-09-08 12:49   ` KESHAV P.R.
2010-09-09  7:31 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2010-09-12  8:40   ` KESHAV P.R.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C888D4D.3010301@gmail.com \
    --to=phcoder@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.