Question about edit to Beginners' Guide
I noticed your recent edits in the Beginners' Guide, where you stated that the --target parameter is required. The man page however states that it defaults to the current platform (should be sufficient for beginners). I also just tested this (at least for BIOS), and it seems to work fine without the parameter.
Can you explain why it is needed?
AFAIK in the initial release of grub 2.00 grub-install explicitly required the user to provide the --target parameter, but then in some later bzr snapshot grub-install tries to guess the platform. In my experience grub-install defaults to i386-pc (BIOS) target most of the time, even in case of x86_64-efi (UEFI) system. I suggest changing all grub-install commands across the wiki to use --target parameter to remove this confusion. -- Keshav Amburay (talk) 15:21, 29 August 2013 (UTC)
- Ok, I understand, I thought the 'guessing' was more robust and failure-proof. Thanks for the reply! :) --Lonaowna (talk) 19:47, 29 August 2013 (UTC)
I noticed your recent changes to the Beginner's Guide on the 18th September, particularly around EFISTUB. You have certainly managed to reduce the number of lines on the page which is good.
However I wanted to confirm that the user really is no longer required to reload the efivars module before chroot ? I read your entry about Jones' new and improved efibootmgr and this should mean that the module reload is no longer required, but has the fork been mainlined into the Arch core repository yet ?
Also is there a way to simplify the call to efibootmgr especially to be easier for new Archers or at least some way to make it easier. For example : "root=/dev/sdaX may be a little more welcoming than "root=PARTUUID=xxxxxxxxxxxxxxxxx". What do you think ? Thanks. Kal (talk) 19:41, 18 September 2013 (UTC)
From core/linux-3.11.1-1 onwards efivars module is not even compiled in the kernel https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=ebf4d782ffe29e3b00e93011a493cbedffbd7415 . This is a deliberate change made by the devs http://email@example.com/msg21788.html . THis chaneg was made only after new efibootmgr moved to core, see 'Upstream URL' in https://www.archlinux.org/packages/core/x86_64/efibootmgr/ .
Reg /dev/sdaX vs PARTUUID, sdaX is very ambiguous and not recommended even in case of bios boot. IN case of UEFI boot, since we are already using GPT, PARTUUIDs are the best FS-independent unambiguous way of specifying a partition. You can even mention (FS) UUID here but in case of GPT I recommend PARTUUID. Even if they are no Archers, they should not be simply conpy-pasting the commands from this page. They should understand what efibootmgr is, what PARTUUID is etc. and then type the command on their own. My intention is not be more welcoming to newbies. I just don't want them to come back later complaining sdaX is not the partition they want when they make some changes in their system and then it refuses to boot due to using ambiguous sdaX. -- Keshav Amburay (talk) 04:43, 19 September 2013 (UTC)
Thanks for the full and prompt reply.
I am still on a 3.10 series kernel and was unaware of the recent changes that you mentioned. The links were informative and your information has brought me up to date, cheers.
I take your point about /dev/sdaX being more ambiguous than UUIDs and I agree that no-one should be copy-pasting instructions from the guide into their terminal (I hope no-one actually does that). You are right, it is important that everyone should be trying to understand what they are doing.
Therefore, what I propose to do is to add a note explaining what the efibootmgr options are and why UUIDs are recommended over the alternative . This will force users to actually read and think about what they are doing and then make an informed, intelligent decision.
What do you think ?
This really looks like the user should add all of the parameters. In fact, it does not make sense to add
nouveau.modeset=0 on a Radeon card. Also note that the
radeon driver/module requires modeseting. So I'll have to undo your edit. -- Lahwaacz (talk) 18:35, 7 October 2013 (UTC)
UEFI Bootable Media
just a quick note on your recent edit: the section Unified_Extensible_Firmware_Interface#Remove_UEFI_boot_support_from_ISO which was left in place refers to "previous section", which was merged into USB Flash Installation Media. I think it should be merged too, what is your opinion?
Otherwise I really like your work, keep up!
I have changed the "Note" to point directly to the USB Flash Installation Media#BIOS and UEFI Bootable USB. The Remove UEFI boot support from ISO actually talks about removing CD/DVD UEFI boot support. I changed the title of that section to Remove UEFI boot support from Optical Media to make it more clear.
To remove USB UEFI boot, you just have make sure <USB>/EFI/Boot/bootx64.efi (case-insensitive) file does not exist (simply delete or rename it, and the USB no longer supports UEFI boot). Setting up a USB drive to UEFI boot is much more easier and straight-forward compared to setting up a CD/DVD (or actually the ISO) (via the El-torito entry) to UEFI boot.
-- Keshav Amburay (talk) 18:08, 21 November 2013 (UTC)
- Thanks for taking care of this, and for the very useful explanation! -- Lahwaacz (talk) 19:22, 21 November 2013 (UTC)
Hi Keshav, as you seem to be the wiki's resident EFI-expert, I hope you don't mind me asking. :)
As I understand from UEFI#UEFI Variables Support in Linux Kernel,
/sys/firmware/efi/efivars is currently enabled and mounted on all default Arch setups (as is the case on my own machine).
If this is the case, does this mean that the line
mount -t efivarfs efivarfs /sys/firmware/efi/efivars # required even inside chroot if any, ignore if already mounted, which is present in most EFI-related articles (such as gummiboot and Beginners' Guide), can be removed, as it is no longer necessary? I find it quite messy as like this, especially without any explanation, so it would be great if it could be removed.