Difference between revisions of "Talk:GRUB"

From ArchWiki
Jump to navigation Jump to search
(Need simplified steps)
m (Stiked through the discussion to indicate ripeness for removal)
 
(267 intermediate revisions by 42 users not shown)
Line 1: Line 1:
== GRUB Legacy stuff should be removed ==
+
== Alpha sorting for kernel names without versions ==
  
I mean, seriously, the page is loaded with too much information anyway. And also because of this: http://www.archlinux.org/news/grub-legacy-no-longer-supported/ --[[User:DSpider|DSpider]] ([[User talk:DSpider|talk]]) 17:41, 29 August 2012 (UTC)
+
When installing the "linux" and "linux-lts" kernels on a basic install, the ''/etc/grub.d/10_linux'' in 2.02-beta1 will try and use a numeric-oriented sorting routine that doesn't work well for kernels without any versions in the names of the files. I've submitted a feature request and patch for this upstream:
  
== EFI ==
+
* https://savannah.gnu.org/bugs/index.php?42597
  
Is there any reason why grub should be installed to /boot/efi/efi/grub and not to /boot/efi? UEFI wants to have the efi-image unter <EFI SYSTEM PARTITION>/efi/name, so /boot/efi/grub should do the trick.
+
Forum discussion w/patch:
Additionally, mounting (e.g.) /dev/sda1 to /boot/efi and just placing the grub there will possibly conflict with having a LVM+LUKS setup, where /boot will then be encrypted. At the moment I'm running a funtoo installation on a thinkpad x121e with /dev/sda1 (200MB, fat32, sectors 1 - 201) mounted to /boot and /dev/sda2 being a LUKS encrypted system. /boot contains the bzImage and /boot/efi/boot/bootx64.efi is the grub-image.
 
  
Note: there should possibly be a section/table here containing information what firmware expects what name. having /boot/efi/grub/grub.efi didn't work for me, and as noted in the thinkwiki for an x220, /boot/efi/boot/bootx64.efi works fine. --[[User:Rochus|Rochus]] 13:59, 16 August 2011 (EDT)
+
* https://bbs.archlinux.org/viewtopic.php?pid=1428523
  
 +
: [//gist.github.com/fstirlitz/7639129 I solved this (and other problems) long ago…] why nobody applied this patch to the Arch package is beyond me. [[User:Fstirlitz|felix]] ([[User talk:Fstirlitz|talk]]) 14:11, 8 August 2014 (UTC)
  
@Rochus: You have mounted your EFISYS partition at /boot ir you are using same part as both EFISYS and /boot and it is FAT32 formatted. The actual path is <EFI_SYS_PART>/efi/grub/grub.efi wherein <EFI_SYS_PART> is usually /boot/efi or in your case /boot itself.
+
::What is the current sate of this issue? --[[User:Stevenmw|Stevenmw]] ([[User talk:Stevenmw|talk]]) 10:56, 6 December 2014 (UTC)
  
But I do not understand your argument about mounting EFISYS at /boot/efi conflicting with LVM+LUKS. I don't have such a config in my system to understand what you are coming to say. <EFI_SYS_PART>/efi/boot/bootx64.efi is just a fallback path incase there's no boot entry in UEFI Boot Manager (see efibootmgr section). I already mentioned in the article that "If you have mounted EFISYS part at a different mountpoint, replace /boot/efi with that mountpoint in all the commands". I suppose that explains it. It is better to have /boot separate from EFISYS partition. I have /dev/sda1 as 200 MiB FAT32 EFISYS mounted at /boot/efi and /dev/sda3 as 400 MiB ext4 /boot part. For /boot/efi/grub/grub.efi to work you have to add a boot entry to grub.efi in the UEFI Boot Manager using efibootmgr utility. -- [[User:the.ridikulus.rat|Keshav P R]] 23:15, 28 August 2011 (IST)
+
:::I'd leave this open right now, as it seems a candidate for merging with [[GRUB/Tips and tricks#Multiple entries]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:36, 22 December 2014 (UTC)
  
== GRUB_GFXMODE may not work with a depth parameter ==
+
== Manually generate grub.cfg ==
  
I'm installing on an i5 system with Intel graphics, and found that I could not get a background image if I used any depth parameter in GRUB_GFXMODE=; if I used the 0x value I got the same errors. I would get a black screen with a blue box, titled "Out of Range" and some H. Frequency and V. Frequency parametersThe boot continued in the background, and eventually I got the normal scroll of information during the boot. What I found was that if I just used a resolution, e.g., 800x600, with nothing more, it worked fine. Not sure if this is something for the wiki here or elsewhere, or something to post in the forums; but it should be somewhere to save the next person the hassle of figuring it out, I think. -- [[User:Timm|Timm]] 13:08, 29 October 2011 (EDT)
+
In previous revisions, instructions on manually creating a grub.cfg were removed [https://wiki.archlinux.org/index.php?title=GRUB&diff=347960&oldid=347954], and later added to [[GRUB/Tips and tricks]] [https://wiki.archlinux.org/index.php?title=GRUB/Tips_and_tricks&oldid=349645#Manually_creating_grub.cfg]. This was discussed with [https://wiki.archlinux.org/index.php?title=Talk:GRUB&diff=349659&oldid=349657].
 +
However, as it turns out manually creating a grub.cfg is in fact ''encouraged'' upstream [https://www.gnu.org/software/grub/manual/html_node/Simple-configuration.html#Simple-configuration]. This is especially true in Arch as we don't have versioned kernels: {{Bug|16702}} (and thus no changing vmlinuz/initrd paths). As such I believe we should reduce the role of grub-mkconfig, expand on grub.cfg and move it back to the main article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:24, 27 June 2015 (UTC)
 +
: I don't see a problem with this.
 +
: From upstream: '' In the meantime, those who feel that it would be easier to write grub.cfg directly are encouraged to do so... and to '''disable any system provided by their distribution to automatically run grub-mkconfig.'''''
 +
: Correct me if I'm wrong here but I don't think we have anything that automatically calls grub-mkconfig. Therefore manually creating/editing grub.cfg shouldn't be a problem. -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 15:01, 27 June 2015 (UTC)
 +
 
 +
::+1, this will also avoid random notes [https://wiki.archlinux.org/index.php?title=Multiboot_USB_drive&diff=379818&oldid=379749 like this] in other articles. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:21, 27 June 2015 (UTC)
 +
 
 +
::Nothing calls grub-mkconfig, no. Yet, I tend to disagree. Reasons: (1) the article is still too long anyway and the fresh start on manually creating grub.cfg is a good base to expand in tips&tricks. (2) Reducing grub-mkconfig basically also means having to touch most content that covers the main options in /etc/default/grub. If I see it right, the Arch package comes with defaults there. (3) Thankfully grub-mkconfig automatically figures menu entry names, but also determines a root= UUID by default these days. The latter not a big problem for simple roots, but cumbersome to describe for others (e.g. when a device mapper is used, lvm, luks, ...). Likewise, grub-mkconfig also uses output from {{Pkg|os-prober}} to automatically generate entries.
 +
::So, I don't think it is a straight-forward task and make things clearer. The instances one would save on "Now re-generate the configuration: ..." would probably have to be replaced with "Now better check the result with grub-script-check /boot/grub/grub.cfg" ... I think it would be better to give [[GRUB/Tips and tricks#Manually creating grub.cfg]] more prominence and expand the fresh base there as required/wanted. Also some of the lengthy menu entry examples of [[GRUB#Automatically generating using .2Fetc.2Fgrub.d.2F40 custom and grub-mkconfig]] could be moved to a section there; they basically work/serve as examples for both (copy pasting into /etc/grub.d/40_custom or /boot/grub/grub.cfg). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:51, 27 June 2015 (UTC)
 +
 
 +
:::I agree with [[User:Indigo|Indigo]]. -- [[User:6arms1leg|6arms1leg]] ([[User talk:6arms1leg|talk]]) 12:48, 28 June 2015 (UTC)
 +
 
 +
::About (1), the inclusion on manually generating grub.cfg would be accompanied by (another, but needed) rewrite of the GRUB article. On (2), similar argument as in (1), and things like modules can be expanded on where needed. (3) It's not because you're not using grub-mkconfig, that you won't use tools such as ''grub-probe'' and ''grub-script-check'' to facilitate some tasks.
 +
::As to clarity, most people just run "grub-mkconfig" without understanding the process at hand, and as such, have difficulties when problems arise.
 +
::Note: I won't have much time to work on this (besides other tasks, I'd prefer to create [[fdisk]] first). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:48, 28 July 2015 (UTC)
 +
 
 +
:Some work was done by Nl6720 recently to merge the manual section into the main page. I have a more fully featured rewrite at [[User:Eschwartz/Grub#Configuration]] and I think I'm more or less happy with it now. I'd like to consider it for merging, and we can then drop some/most/all of the overly specific examples that have accumulated for {{ic|/etc/grub.d/40_custom}} (which IMO add very little if anything).
 +
 
 +
:Proposal: Drop the entire section [[GRUB#Custom grub.cfg]] and prepend my modifications before [[GRUB#Generated grub.cfg]]. Thoughts? -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 15:28, 8 January 2019 (UTC)
 +
 
 +
::Must everything in [[GRUB#Custom grub.cfg]] be removed? Can't the examples from [[GRUB#Boot menu entries]] be integrated in [[User:Eschwartz/Grub#Examples]]? I find them useful. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:41, 8 January 2019 (UTC)
 +
 
 +
:::I'm open to expanding the examples section, but I think many of them are needlessly ornate. It's redundant to, for example, include multiple full copy-paste definitions of menuentries to execute halt/reboot (which I don't see as particularly useful), or to chainload the specific .efi executable used for the UEFI Shell. I'm unsure how much Windows stuff might be valuable to merge, but I'm highly suspicious that most of it could be made smaller at least. Like, I have no idea why this stuff checks {{ic|$grub_platform}} ''per default''. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 15:54, 8 January 2019 (UTC)
 +
 
 +
::::I don't really see a problem with having a lot of detailed examples, working examples should make it easier for the reader to understand the syntax.
 +
::::The {{ic|$grub_platform}} check in the Windows entries is most likely useless since AFAIK for Windows changing the boot mode is not that simple and I don't think it supports both at the same time. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:11, 8 January 2019 (UTC)
 +
 
 +
:::::I'm myself looking at the expansion template in [https://wiki.archlinux.org/index.php?title=User:Eschwartz/Grub&oldid=563131#Examples], which end the new part. What I would do in that subsection is move and link the windows examples to the later detached examples section, replacing them with a very typical Linux one. For example, one with systemd hook boot parameters and one which crosslinks how to derive the correct lvm uuid. I agree it is still necessary to sieve the other existing examples, perhaps add a bullet list linking the most important ones. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:37, 13 January 2019 (UTC)
 +
 
 +
::::::General examples section merged out of the grub-mkconfig subsection and linked in my examples section. Looking at options for further streamlining, suggestions welcome! -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 20:13, 13 January 2019 (UTC)
 +
 
 +
::::Hi, first, the intro you wrote for the manual section is super, very clear already and enhances the upstream doc. IMO it would be totally helpful to merge in as a drop-in replacement for [[GRUB#Custom grub.cfg]] right away.
 +
::::At this point I'm not convinced it should prepend the [[GRUB#Generated grub.cfg]] as the first [[GRUB#Configuration]] section though. Let me give two examples:
 +
::::Look at [[User:Eschwartz/Grub#RAID]], it's inside the [[User:Eschwartz/Grub#Generate_the_configuration_file_using_grub-mkconfig|grub-mkconfig]] but actually describes grub-install and grub modules as well. I.e. the grub-mkconfig section mixes in the parts relevant for a first install. All this would have to be dis-entangled and crosslinked between both config sections first. What I am getting it is: Yes, a custom.cfg can be a slick three lines, but all that magic making them a working 50+ lines is shipped with supported defaults ([https://git.archlinux.org/svntogit/packages.git/tree/trunk/0003-10_linux-detect-archlinux-initramfs.patch?h=packages/grub&id=d60f7037b8122c9f3ef6b33787ed6b8d2101c706] [https://git.archlinux.org/svntogit/packages.git/commit/trunk/grub.install?h=packages/grub&id=d60f7037b8122c9f3ef6b33787ed6b8d2101c706]), because the major GRUB configuration task is to (1) install the boot loader image correctly to the disk and (2) have a initramfs with matching boot options for the machine setup based on configured defaults. Just one more example for this: nowhere in the article there is an explicit mention of an "-fallback" menu entry. --> Because the /etc/grub.d/ script handles it, sourcing /etc/default/grub <-- variables in that file are a lot explanation to cover for any meaningful manual examples... or not?
 +
::::So, to pre-pend the manual method as the first configuration section, there should first be a plan how to proceed with the more complex rest. My suggestion is to
 +
::::# drop-in your new part to start existing "3.2 [[GRUB#Custom grub.cfg]],
 +
::::# Separate the dispensable {{ic|menuentry{}}} examples into a new top-level "Examples" section (IMO ideally below current "4. [[GRUB#Using the command shell]]", because your new explanation is super helpful to lead over for command shell too), and remove/move/merge menuentries as appropriate (btw, I assume ordering [[User:Eschwartz/Grub#Multiple entries]] ff into "Encryption" is simply a glitch.). Meanwhile,
 +
::::# work-out where the "configuration from scratch" should end/what of the not-straight-forward three-line .cfg's are covered in which section.
 +
::::What do you think? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:29, 13 January 2019 (UTC)
 +
 
 +
:::::First off, my rewrite and the main page have diverted a bit and I did not merge changes. I've now merged the current main page as-is with my rewrite dropped in where I suggested; this means there are now two sections for generating the custom grub.cfg, the latter of which is a boatload of custom.cfg things for grub-mkconfig to do like shutdown entries and stuff. Also, it is now much easier to grok the high-level organization of the page at a glance.
 +
:::::On the topic of things like RAID, would this be sufficient to include as references to how to write a filesystem path? I have no practical experience with RAID. Maybe we should merge this section into its own section as a child of [[User:Eschwartz/Grub#Configuration]].
 +
:::::If it doesn't provide a suitable explanation linked to writing your own grub.cfg, I'm hesitant to merge as-is, because it shouldn't depend on grub-mkconfig docs whether listed before or after. On an unrelated note, I really don't want to relegate this to second, because I want people to see what I believe the superior method first. :p I guess that could be fixed later, true...-- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 15:05, 13 January 2019 (UTC)
 +
 
 +
::::::Yes, please don't start to merge as-is. If options are presented neutral, the order is secondary, exactly. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:37, 13 January 2019 (UTC)
 +
 
 +
:::::::I'm wondering if the best option would be to simply drop it altogether. The handwritten cfg already describes the need to insmod the drivers for additional partitions, and this includes both grub and lvm. Make a new toplevel section #4, "Filesystem-specific issues", in between [[GRUB#Configuration]] and [[GRUB#Using the command shell]], which describes issues specific to ''installation'' in some given situation, and describe 1) the need to grub-install twice for RAID and 2) move [[GRUB#Encrypted /boot]] under that header.
 +
 
 +
:::::::Maybe expand the mkconfig section to specify how to preload a module -- though I'm unsure why it doesn't autodetect the need, what is this huge script even useful for? :p -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 00:04, 15 January 2019 (UTC)
 +
 
 +
::::::::Luckily I still kept my VMs with [[dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)]] and a slightly modified [[dm-crypt/Encrypting an entire system#LUKS on software RAID]]. Adding modules to {{ic|GRUB_PRELOAD_MODULES}} is not needed, grub-mkconfig detects them and puts them in {{ic|grub.cfg}} where needed. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:55, 15 January 2019 (UTC)
 +
:::::::::I've implemented this in my rewrite as [[Special:Diff/563411]], do you agree with this? EDIT: reworked it several more times -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 17:22, 15 January 2019 (UTC)
 +
 
 +
::::::::::I don't think that is what nl6720 (pls correct if wrong) implied: Unfortunately, not that simple. grub-mkconfig will detect its required modules according to what's running, but that does not mean you can leave the user alone with the determination. LUKS is likely worst case (~5 out of a 22 gcry_*.mod). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 23:34, 15 January 2019 (UTC)
 +
:::::::Actually, I suggest to stop this branch here as long as there is so much draft(ing)-in-progress. I know I started it too with making individual suggestions which Eschwartz integrated into his draft quickly, but at the same time my intention was also to reach a quick consensus to merge the new part over, so that reorganisation of existing other sections can be collaborated on step-by-step.
 +
:::::::@Eschwartz: how about you open a talk item on [[User talk:Eschwartz/Grub]] or similar, ideally with a short wip status, then leave a link here? I'm sure nl6720 and others will contribute there equally. I will too; in fact I have at least one suggestion I consider ''extremely'' relevant for the current draft. Later, i.e. as soon as you see sections of the draft ready to merge, it is time to pick up here again. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 23:34, 15 January 2019 (UTC)
 +
 
 +
::::::::Done, further discussion will take place at [[User_talk:Eschwartz/Grub]] and I've copied over the two existing discussions. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 00:07, 16 January 2019 (UTC)
  
 
== Custom keyboard layout ==
 
== Custom keyboard layout ==
 +
 
Hi. Could we add a section explaining how you can set your preferred keyboard layout within GRUB2? As i found [http://lists.gnu.org/archive/html/grub-devel/2011-06/msg00008.html here], we need the ckbcomp script, which can be obtained from Debian console-setup package.
 
Hi. Could we add a section explaining how you can set your preferred keyboard layout within GRUB2? As i found [http://lists.gnu.org/archive/html/grub-devel/2011-06/msg00008.html here], we need the ckbcomp script, which can be obtained from Debian console-setup package.
  
 
Here's how I made things work:
 
Here's how I made things work:
  
  ckbcomp it | grub-mklayout -o /boot/grub/it.gkb
+
sudo mkdir /boot/grub/layouts
 +
  ckbcomp it |sudo grub-mklayout -o /boot/grub/layouts/it.gkb
  
 
Then, I manually edited {{ic|/boot/grub/grub.cfg}}, adding the following lines:
 
Then, I manually edited {{ic|/boot/grub/grub.cfg}}, adding the following lines:
Line 31: Line 91:
 
<nowiki>
 
<nowiki>
 
terminal_input at_keyboard
 
terminal_input at_keyboard
keymap (hd0,2)/boot/grub/it.gkb
+
keymap it
 
</nowiki>}}
 
</nowiki>}}
  
Line 38: Line 98:
 
Cheers. --[[User:Hilinus|Hilinus]] 12:50, 26 December 2011 (EST)
 
Cheers. --[[User:Hilinus|Hilinus]] 12:50, 26 December 2011 (EST)
  
 
+
:I followed [http://lists.gnu.org/archive/html/grub-devel/2011-03/msg00051.html instructions] on the grub-devel mailing list. First you insert  
 
 
I followed [http://lists.gnu.org/archive/html/grub-devel/2011-03/msg00051.html instructions] on the grub-devel mailing list. First you insert  
 
  
 
{{hc|/etc/default/grub|
 
{{hc|/etc/default/grub|
Line 47: Line 105:
 
</nowiki>}}
 
</nowiki>}}
  
in {{ic|/etc/default/grub}}. Then you get ckbcomp Perl script from Ubuntu or Debian and execute (for Slovene layout)
+
:in {{ic|/etc/default/grub}}. Then you get ckbcomp Perl script from Ubuntu or Debian and execute (for Slovene layout)
  
$ ckbcomp si | grub-mklayout -o si.gkb
+
:{{bc|<nowiki>
Unknown key KP_Comma
+
$ ckbcomp si | grub-mklayout -o si.gkb
Unknown key KP_Comma
+
Unknown key KP_Comma
Unknown key KP_Comma
+
Unknown key KP_Comma
Unknown key KP_Comma
+
Unknown key KP_Comma
Unknown keycode 0x79
+
Unknown key KP_Comma
$ sudo mv si.gkb /boot/grub/
+
Unknown keycode 0x79
 +
$ sudo mv si.gkb /boot/grub/
 +
</nowiki>}}
  
After that you add  
+
:After that you add  
  
 
{{hc|/etc/grub.d/40_custom|
 
{{hc|/etc/grub.d/40_custom|
Line 65: Line 125:
 
</nowiki>}}
 
</nowiki>}}
  
to {{ic|/etc/grub.d/40_custom}} and finally generate new grub.cfg with
+
:to {{ic|/etc/grub.d/40_custom}} and finally generate new grub.cfg with
 +
 
 +
:{{bc|$ sudo grub-mkconfig -o /boot/grub/grub.cfg}}
 +
 
 +
:Cheers. --[[User:drevo|drevo]] 17:47, 6 January 2012 (EST)
 +
 
 +
::The version  of ckbcomp I got from Debian Squeeze kept giving this error:
 +
 
 +
::{{bc|Unknown name $sun_t6_custom}}
 +
 
 +
::The Ubuntu Precise version worked out of the box.
 +
 
 +
::A temporary solution for layouts would be an AUR package for ckbcomp or to distribute .gkb files somehow, but the proper solution would be for grub-mklayout to accept keymaps(5) files.
 +
 
 +
::--[[User:Schizius|Schizius]] ([[User talk:Schizius|talk]]) 18:44, 26 July 2012 (UTC)
 +
 
 +
:::This won't work if /boot is on another root partition. At home / is on lvm and /boot on standard MBR partition. This was historical. But since grub.cfg is generated with the root partition in lvm, it can't find my keyboard layout.
 +
:::The clean solution is to create a new file ''/etc/grub.d/50_keymap''and put this:
 +
 
 +
:::{{bc|<nowiki>
 +
#!/bin/sh
 +
set -e
 +
# Include the GRUB helper library for grub-mkconfig.
 +
. /usr/share/grub/grub-mkconfig_lib
 +
KEYMAP_FILE=/boot/grub/bepo.gkb
 +
if ! prepare_grub_to_access_device "`${grub_probe} --target=device "${KEYMAP_FILE}"`"; then
 +
return 6--~~~~
 +
fi
 +
KEYMAP_FILE=$(make_system_path_relative_to_its_root "${KEYMAP_FILE}")
 +
cat <<EOF
 +
insmod keylayouts
 +
keymap "${KEYMAP_FILE}"
 +
EOF
 +
</nowiki>}}
 +
 
 +
:::So that the root partition is detected, loaded, and then the file is read within that partition.
 +
 
 +
:::--[[User:Glandos|Glandos]] ([[User talk:Glandos|talk]]) 08:23, 14 November 2013 (UTC)
 +
 
 +
::::Is Glandos's solution to be used in addition to the Perl script, or is it a standalone solution? I get the vague sense that it is to be used as an additional step only when your /boot is located in its own partition. If someone can clarify this, I will add the above steps to the wiki and test them out, because I was looking for a solution to this same issue. [[User:Ingengnue|ingegnue]] ([[User talk:Ingengnue|talk]]) 09:39, 5 October 2014 (UTC)
 +
 
 +
::::::There is a discussion further down the page about restructuring and cleaning up the GRUB article. I will make a suggestion to add a section like this in that discussion. This way we can see how much demand there is for it and get suggestions about where to put it and how to structure it. I will make a note of all of this information, and gather some more to build content for the section. Since I am moving this suggestion to the main discussion below, I move to close this. If anyone has any feedback regarding this please add it please. I move to close this so I may add it to the main section below. (All information has been saved in roder to reproduce if necessary.)
 +
::::::--[[User:Stevenmw|Stevenmw]] ([[User talk:Stevenmw|talk]]) 19:30, 3 December 2014 (UTC)
 +
 
 +
:::::::Reopening this talk since I've hit this issue myself... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:31, 3 August 2015 (UTC)
 +
 
 +
:::::::This issue gets very important now that disk encryption becomes more popular and users have to type their passphrase during grub boot phase. I think there has to be something in the documentation for setting a locale in grub2. As for Ubuntu, it works out of the box and I'd love to have a clean howto to change the keymap in GRUB2. Guess what ? A complete guaranteed recipe is hard to find on the net. Those comments where very handy for me.
 +
:::::::[[User:Skizorutabaga|Skizorutabaga]] ([[User talk:Skizorutabaga|talk]]) 18:05, 23 July 2016 (UTC)
 +
 
 +
::::::::There is, for UEFI: [[GRUB/Tips_and_tricks#Manual_configuration_of_core_image_for_early_boot]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:10, 23 July 2016 (UTC)
 +
 
 +
:::::::: grub-kbdcomp /tmp/fr.gkb fr can also create keyboard layout for at_keyboard
 +
::::::::Note that at_keyboard does not always work. If at_keyboard freeze your system, you may have to use use usb_keyboard or console, so you could not use your layout...
 +
::::::::cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741464
 +
::::::::{{unsigned|04:11, 29 July 2017‎|Ryuta}}
 +
 
 +
== grub standalone ==
 +
 
 +
two things:
 +
 
 +
<s>1- I think the switch
 +
--fonts="unicode"
 +
have to be removed since it is already the default behaviour
 +
(source: man grub-mkstandalone)
 +
 
 +
2- before executing the command `grub-mkstandalone ...`, create the directory in your ''esp'' (e.g. /boot/EFI)
 +
otherwise it will fail
 +
 
 +
--[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 09:34, 9 April 2016 (UTC)
 +
</s>
 +
'''done!''' --[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 17:28, 8 February 2017 (UTC)
 +
 
 +
== Grub Shell normal linux booting ==
 +
 
 +
A little improvement in GRUB Shell secction.
 +
When it is described the following example in [[GRUB#Using_the_rescue_console]]
 +
 
 +
----
 +
 
 +
An example, booting Arch Linux:
 +
 
 +
set root=(hd0,5)
 +
linux /boot/vmlinuz-linux root=/dev/sda5
 +
initrd /boot/initramfs-linux.img
 +
boot
 +
 
 +
With a separate boot partition (e.g. when using EFI), again change the lines accordingly:
 +
{{Note|Since boot is a separate partition and not part of your root partition, you must address the boot partition manually, in the same way as for the prefix variable.}}
 +
 
 +
set root=(hd0,5)
 +
linux (hdX,Y)/vmlinuz-linux root=/dev/sda6
 +
initrd (hdX,Y)/initramfs-linux.img
 +
boot
 +
----
 +
 
 +
I think it's imortant to say which partition is the root (/) and which is /boot, because it says sda5 and sda6, but it could be confusing. For example, to me, I don't really understand which is each one.
 +
Can someone explain it better? Thank you.
 +
 
 +
[[User:Cmolina|Cmolina]] ([[User talk:Cmolina|talk]]) 17:54, 13 August 2016 (UTC)
 +
 
 +
:That is indeed confusing. I don't use GRUB, but I would guess that {{ic|1=set root=}} is setting the root of the ''console'' so that you can specify where the kernel/ramdisk is, which would be {{ic|/boot}}. Then when you boot linux you need to pass the usual kernel parameter {{ic|1=root=}} specifying where the linux filesystem is.
 +
:[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 19:34, 13 August 2016 (UTC)
  
$ sudo grub-mkconfig -o /boot/grub/grub.cfg
 
  
Cheers. --[[User:drevo|drevo]] 17:47, 6 January 2012 (EST)
+
:: Yes, I think is what you say. In facts, I tried to {{ic|1=set root=}} to my {{ic|/boot}} partition and then I specified the {{ic|1=root=}} for linux system, which is my partition mounted to {{ic|/ }} and it was OK. So I think we could explain it better in the wiki.
 +
::[[User:Cmolina|Cmolina]] ([[User talk:Cmolina|talk]]) 19:47, 13 August 2016 (UTC)
  
 +
== De-duplication of section header ==
  
 +
ATM there is a duplicate header anchor:
 +
* "Installation" links to the installation procedure for BIOS.
 +
* "Installation" &rarr; "Installation_2" links to the installation procedure for UEFI.
 +
After some chat in IRC #archlinux-wiki, I am changing the second header from "Installation" to "Install", so to avoid this duplication of headers.
  
 +
In the same edition, I am also leaving a temporal manual anchor for "Installation_2", so as to minimize breaking links, considering the importance of this particular section of this particular wiki page.
 +
The reasoning for leaving a temporal manual anchor is that internal links are relatively easy to correct (right after renaming the header), whereas external links aren't.
  
The version  of ckbcomp I got from Debian Squeeze kept giving this error:
+
Examples of "external links" I am thinking about are:
 +
* Current / recent forum posts with links to the particular header / section.
 +
* Current / recent email threads / discussions with links to the particular header / section.
 +
* Other current / recent / relevant places / pages / sites with links to the particular header / section.
 +
The intention of this ''temporal'' manual anchor is to allow such potential recent links to still be valid (instead of leaving broken links), so users / readers / participants of conversations would still be able to make sense of such links and surrounding text / context, at least for some time.
  
Unknown name $sun_t6_custom
+
Not every single header's renaming deserves leaving a (temporal) manual anchor (i.e. in most cases, I wouldn't be leaving a manual anchor) but in this case I consider this wiki page and this section to be particularly important / popular / relevant for too many users.
  
The Ubuntu Precise version worked out of the box.
+
After some time, once current potential posts / emails containing links to the aforementioned section would be considered "old enough" (say, a month?), the manual anchor could be removed.
  
A temporary solution for layouts would be an AUR package for ckbcomp or to distribute .gkb files somehow, but the proper solution would be for grub-mklayout to accept keymaps(5) files.
+
When I'm done with the edition I'll add a comment here. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 16:53, 6 March 2017 (UTC)
  
--[[User:Schizius|Schizius]] ([[User talk:Schizius|talk]]) 18:44, 26 July 2012 (UTC)
+
:What exactly was wrong with the duplicate header? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:14, 6 March 2017 (UTC)
  
== Please make the different options for changing the MBR more clear ==
+
:: Duplication of section headers are a potential problem because they generate an '''automatic''' anchor with a trailing number ("Installation", "Installation_2", "Installation_3") which can _vary_ depending on the location / order of the header within the page. IOW, moving a section means that a link such as <nowiki>[[GRUB#Installation_2]]</nowiki> would point to a different section than what was originally intended.
 +
:: Anyway, the edition is done [https://wiki.archlinux.org/index.php?title=GRUB&diff=469963&oldid=468802] and I also corrected the corresponding internal links (in the main namespace).
 +
:: I intend to remove the manual anchor in some time (a month?). [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 17:31, 6 March 2017 (UTC)
  
The three options [https://wiki.archlinux.org/index.php/GRUB2#Install_grub-bios_boot_files here] are only separated by a bit unclear titles, and if people follow the links, they might be confused.[[User:Jasper1984|Jasper1984]] ([[User talk:Jasper1984|talk]]) 16:03, 20 July 2012 (UTC)
+
:::Do you plan to change the order of these sections? Otherwise you're just solving a fabricated problem - the headings are like this this since [https://wiki.archlinux.org/index.php?title=GRUB&oldid=351695 2014] when they were changed from something completely different, I don't think there was ever a change which just changed the order of two sections with the same heading. If such problem really appeared in practice, the best solution would be to rename the sections after swapping them, which would invalidate the old links. This way old links will be invalidated for no reason and probably the first person wondering why these headings are different might rename them back for coherence. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:08, 6 March 2017 (UTC)
  
== Backing up grub-legacy bootcode ==
+
::::Just in case and FWIW, for the very basic info about the matter, see https://en.wikipedia.org/wiki/Help:Link#Duplicate_section_names
 +
::::Renaming, moving, restructure... It happens all the time, with consequences. The fact that (some/many) editors don't notice / know / care about consequences of their editions doesn't mean that section header duplication is not a problem.
 +
::::Some editors don't even bother to summarize their editions, some of which are not always "the right thing to do".
 +
::::OTOH, I ask for feedback at IRC #archlinux-wiki, I explain the reasoning in the Talk Page, I perform the edition, I fill in a relevant edition summary, I take care of the internal links that are affected by the edition, and I also minimize the potential impact on external links (which many wiki editors and maintainers don't even consider before performing editions). Then I come back to the Talk Page to inform about the changes that were performed. I think I've done the right thing, and I think my edition was adequate. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 08:07, 7 March 2017 (UTC)
  
Both grub2 and grub-legacy write to the space between the end of the MBR and the beginning of the first partition.  I'm no expert on this matter; I just learned about it today.  That said, it makes me question the usefulness of the dd backup/restore method in the [https://wiki.archlinux.org/index.php/GRUB2#Backup_Important_Data Backup Important Data] section. --[[User:Alphaniner|Alphaniner]] ([[User talk:Alphaniner|talk]]) 20:07, 25 July 2012 (UTC)
+
:::::I vote for reverting [https://wiki.archlinux.org/index.php?title=GRUB&curid=5984&diff=469963&oldid=468802], [https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&curid=17198&diff=469964&oldid=467081] and [https://wiki.archlinux.org/index.php?title=Samsung_NP740U3L-L02US&diff=prev&oldid=469965]: having an "Installation" heading in the BIOS section, and "Install" in UEFI looks incoherent/unnatural, and as Lahwaacz points out, it just begs for somebody to fix it, which will happen sooner or later especially after removing the anchor (and hence breaking all its remaining backlinks), and even more especially if the article will really ever be radically restructured. In [[w:Help:Link#Duplicate_section_names]] the numbered suffix is presented as a feature, not a problem to work around, and IMO in general the least problematic way to edit the wiki is to do it in the way that the MediaWiki devs designed it. If one day we will have to swap "GRUB#Installation" links with "GRUB#Installation_2" we'll easily do it with a bot. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:48, 8 March 2017 (UTC)
:As far as I know, only GRUB2 uses the post-MBR gap. GRUB2 will notice when there is not enough space at the post-MBR gap and return a warning message (without overwriting anything, see [[https://wiki.archlinux.org/index.php/GRUB2#msdos-style_error_message]]) [[User:6arms1leg|6arms1leg]] ([[User talk:6arms1leg|talk]]) 15:45, 22 August 2012 (UTC)
 
  
== GRUB2 + Windows 7 TrueCrypt-encrypted partition ==
+
::::::The Wikipedia link is the description of the feature, not the problem. The fact that the feature exists doesn't mean that duplication of headers is recommended or welcomed; on the contrary.
 +
::::::Had I performed a simple renaming on both headers and nothing more (as most editors do all the time, without caring / understanding its consequences), we would not be wasting time with this. Possibly I should not even care to edit at all. I think this simple matter is not worth spending more time on it. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 10:25, 8 March 2017 (UTC)
  
[http://www.reddit.com/r/archlinux/comments/xdwsa/finally_did_the_grub2_update_migrating_away_from/ here is a link to my notes from my experience going thru this] and [http://ubuntuforums.org/showpost.php?p=10113708&postcount=25 Ubuntu Forum post which helped me a GREAT DEAL with this issue]
+
:::::::>"Possibly I should not even care to edit at all"
- below is a quick HOWTO ::
+
:::::::What I don't understand is why apparently it's often impossible to accept disagreement and different opinions without taking them as personal affronts. Even if an edit is minor it doesn't mean that it's accepted just because of that, nonetheless nobody has reverted your edits yet, Lahwaacz hasn't even taken a definitive stance on the matter, can we please keep calm an reasonable, also considering the very minor nature of this issue?
 +
:::::::Instead of winging we could discuss compromises such as renaming those headings in neater ways, e.g. "BIOS installation" and "UEFI installation". As I said we can always use bots to change the backlinks.
 +
:::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:29, 8 March 2017 (UTC)
  
# ls -al /mnt/win7drive/Users/me/Documents/TrueCrypt\ Rescue\ Disk.iso
+
::::::::I'm not taking this personally (although I do value my own time), and I'm OK with disagreements. My point is that if I would had performed the renaming in the same way as others do all the time, then we wouldn't be discussing it. I could say more, but I'd rather focus on practical results and not waste more time.
    -rwx------ 2 me users 1835008 Sep  5  2011 /mnt/win7/Users/me/Documents/TrueCrypt Rescue Disk.iso
+
::::::::WRT a different renaming as a compromise, I am very much in favor. In fact, my initial idea was to rename both headers, "Installation on BIOS" and "Installation on UEFI" (or "Install on..") respectively. But renaming both headers in this way would mean that:
 +
*even more external links could be potentially affected;
 +
*many more internal links would need to be updated in comparison to renaming only one of the headers (and I was doing them manually, one by one);
 +
*there was a disagreement in IRC #archlinux-wiki about adding "... BIOS" and "... UEFI" in the headers when they are already subsections under the respective BIOS and UEFI sections.
 +
::::::::Now, if ("Install on BIOS" and) "Install on UEFI" is/are acceptable &mdash; they are to me &mdash; please go ahead.
 +
::::::::In such case, leaving a temporal manual anchor also for the first header would be a plus IMO. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 12:44, 8 March 2017 (UTC)
  
# sudo cp /mnt/win7/Users/me/Documents/TrueCrypt\ Rescue\ Disk.iso /boot/
+
:::::::::I agree with Kynikos that we should revert to the original, unproblematic state of headings until somebody comes up with a radical way to restructure the article's sections.
# mv /boot/TrueCrypt\ Rescue\ Disk.iso /boot/truecryptDesktop.iso
+
:::::::::>"My point is that if I would had performed the renaming in the same way as others do all the time, then we wouldn't be discussing it."
 +
:::::::::You are right about this, in that case I would have simply reverted the renaming instead of joining this discussion.
 +
:::::::::>"leaving a temporal manual anchor also for the first header would be a plus"
 +
:::::::::FWIW I don't see any value in doing that. Internal links to the affected sections can be updated so quickly (with a bot) that it would be a waste of time, external links from resources that "don't care for updates" won't be updated anyway and external resources that absolutely need to preserve the temporal validity of the links should use [https://wiki.archlinux.org/index.php?title=GRUB&oldid=468802#Installation_2 permalinks]. Which alternative am I missing?
 +
:::::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:50, 8 March 2017 (UTC)
  
# pacman -S syslinux
+
::::::::::A simple reversion of those 3 edits was still my first choice, so I've jsut done it. I'm closing this discussion since apparently it didn't attract anybody else's interest: according to [[Help:Discussion]] it will still be visible at least for another week anyway. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:32, 9 March 2017 (UTC)
  
  # cp /usr/lib/syslinux/memdisk /boot/
+
== Dual Booting Windows. ==
  
# ls -alt /boot
+
In the section on dual booting windows there is a section giving instructions for people booting BIOS-MBR
    total 26388
 
    drwxr-xr-x  5 root root    4096 Jul 29 04:01 .
 
    -rw-r--r--  1 root root    26140 Jul 29 04:01 memdisk
 
    -rwx------  1 root root  1835008 Jul 29 03:59 truecryptDesktop.iso
 
            ....  ....
 
  
#mount | grep /boot
 
    /dev/sda3 on /boot type ext3 (rw,relatime,data=ordered)
 
  
# vi /etc/grub.d/40_custom
+
{{bc|1=
+
if [ "${grub_platform}" == "pc" ]; then
  menuentry "Microsoft Windows 7 x64 Home Premium" {
+
  menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {
    insmod part_msdos
+
  insmod part_msdos
     set root='(hd0,msdos3)'
+
  insmod ntfs
    linux16 ($root)/memdisk iso raw
+
  insmod search_fs_uuid
    initrd16 ($root)/truecryptDesktop.iso
+
  insmod ntldr      
 +
  search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE
 +
  ntldr /bootmgr
 
  }
 
  }
 +
}
 +
}}
  
# sudo grub-mkconfig -o /boot/grub/grub.cfg
+
This probably works fine for most people. but if you run a BIOS-GPT setup to load GRUB and then want to load a BIOS-MBR windows setup on a separate drive. this wont work unless you remove the if statement. presumably the original author did not consider the fact that you could have both GPT and MBR in the same system on different drives.
  
--[[User:Fnord0|Fnord0]] ([[User talk:Fnord0|talk]]) 17:59, 30 July 2012 (UTC)
+
{{unsigned|18:46, 23 May 2017‎|Theholyduck}}
  
== grub-mkconfig with several os ==
+
:Perhaps what you indicated should be added in the same section or in another section regarding dual booting  Windows. Have you tested exactly what you stated and you know it works when you remove the if statement?
  
I use several OS (Windows, Arch, Ubuntu, Gentoo) on different partitions.  os-prober only found Arch, Windows and Ubuntu -- strangely not Gentoo.  But when I mount the gentoo partition, it's found.  I don't know, whether this is the case, because I resized the partition, gentoo lives on, or whether this is the `default' behaviour.  If so, should the Wiki mention that mounting the partitions help?
+
:[[User:Alchemek|Alchemek]] ([[User talk:Alchemek|talk]]) 17:07, 12 June 2017 (UTC)
  
--[[User:Skunk|Skunk]] ([[User talk:Skunk|talk]]) 19:46, 30 July 2012 (UTC)
+
Has anyone besides the contributor got directly booting to work? [https://wiki.archlinux.org/index.php/GRUB#Windows_installed_in_BIOS-MBR_mode] I am the person who has added in the chainloading method because after some significant time I could not get the direct booting method working on my machine despite the fact that I do indeed have a BIOS-MBR configuration with Windows 10. I think we should have both methods because, as far as I know, the Arch Wiki has had the chainloading method available for a very long time and it always works. Further, Microsoft tends to do weird things with its files, so there's no telling when direct booting will or will not work depending on what Microsoft decides to do. By contrast, the chainloading method avoids this issue almost entirely.
  
== Need simplified steps ==
+
[[User:Alchemek|Alchemek]] ([[User talk:Alchemek|talk]]) 17:07, 12 June 2017 (UTC)
  
I think [[GRUB2#Preliminary_Requirements_for_GRUB2]] part is optional in some cases. If so, it should be noted as optional.
+
:I'm chainloading too, tested the "normal" method to no avail when i got some problems installing GRUB. I would like to add, if one's machine is eqipped with an UEFI firmware, and the chosen partition table is MBR, before running through the installation it's better to check the boot preferences and/or select the proper USB drive method to boot, since UEFI boot manager may have a higher priority and "corrupt" the bootloader installation. Also, in this case, when booting an USB Archiso live one should be good-to-go if the coloured Arch Linux boot menu appears (instead of a minimal black screen/white font boot menu with some UEFI options). Forgetting or ignoring to check this before installing and configuring GRUB, lead to the result that Windows (in my case, 8.1) won't be booted (even after adding a proper 40_custom configuration) nor os-prober will be able to find it. Finally, as @Alchemek may guess, even in this case Windows needs to be booted by chainloading its boot manager. Documentation about this seems missing/scarce due to the singularity of the case, but i think adding it to the Wiki should do no harm. [[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 20:40, 25 October 2017 (UTC)Lo1
  
{{Pkg|os-prober}} is quite useful, it should be put at the beginning of the articles, such as preparation.
+
== <s>GRUB with EFI partition on NVMe drive</s> ==
  
In my case, I only did the backup, install grub-bios, install os-prober, [[GRUB2#Install_to_440-byte_MBR_boot_code_region]], edit {{ic|/etc/grub.d/40_custom}}, and finally grub-mkconfig. My computer is dual-boot with Windows 7.
+
So I managed to finally get GRUB to work on a system that has an NVMe SSD as its main drive and an HDD as it's secondary drive. As you can imagine the NVMe drive is called {{ic|/dev/nvme0n1}} and the HDD {{ic|/dev/sda}}. I mounted the second partition of my nvme drive under the /boot directory and installed grub there. However what I ended up wasting hours is the fact that GRUB ended up making an EFI entry for  {{ic|/dev/sda2}} (which was not mounted, nor was it even detectable at the time of running {{ic|grub-install}}) instead of {{ic|/dev/nvme0n1p2}}, which was mounted at the time. I ended up noticing this because the partition UUID was incorrect for the partition it was supposed to point to.
  
--[[User:Allencch|Allencch]] ([[User talk:Allencch|talk]]) 00:23, 1 August 2012 (UTC)
+
So my question is whether I should add a warning somewhere on the page to make sure to check the partition UUID when creating an entry when using an NVMe drive or if I should add a subtitle in the Troubleshooting section explaining the issue and it's solution?
  
== <s> edit note </s>==
+
::After looking into this more, I found out that this seems to be a weird issue with my BIOS changing it on the first time the machine is booted with a newly created boot entry, after which I just deleted it and manually recreated it in the BIOS Setup. I will also add this to the page about my specific laptop in the [[Laptop]] page. As such I consider this closed but have no idea how to close a discussion... [[User:Deathary II|Deathary II]] ([[User talk:Deathary II|talk]]) 02:25, 18 January 2019 (UTC)
I edited Note under grub installation section to specify that --target=i386-pc doesn't need to be changed for 64-bit systems. --[[User:Ottoshmidt|Ottoshmidt]] ([[User talk:Ottoshmidt|talk]]) 15:33, 7 October 2012 (UTC)
 
: Thanks. Close. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 05:25, 9 October 2012 (UTC)
 

Latest revision as of 02:27, 18 January 2019

Alpha sorting for kernel names without versions

When installing the "linux" and "linux-lts" kernels on a basic install, the /etc/grub.d/10_linux in 2.02-beta1 will try and use a numeric-oriented sorting routine that doesn't work well for kernels without any versions in the names of the files. I've submitted a feature request and patch for this upstream:

Forum discussion w/patch:

I solved this (and other problems) long ago… why nobody applied this patch to the Arch package is beyond me. felix (talk) 14:11, 8 August 2014 (UTC)
What is the current sate of this issue? --Stevenmw (talk) 10:56, 6 December 2014 (UTC)
I'd leave this open right now, as it seems a candidate for merging with GRUB/Tips and tricks#Multiple entries. -- Alad (talk) 19:36, 22 December 2014 (UTC)

Manually generate grub.cfg

In previous revisions, instructions on manually creating a grub.cfg were removed [1], and later added to GRUB/Tips and tricks [2]. This was discussed with [3]. However, as it turns out manually creating a grub.cfg is in fact encouraged upstream [4]. This is especially true in Arch as we don't have versioned kernels: FS#16702 (and thus no changing vmlinuz/initrd paths). As such I believe we should reduce the role of grub-mkconfig, expand on grub.cfg and move it back to the main article. -- Alad (talk) 14:24, 27 June 2015 (UTC)

I don't see a problem with this.
From upstream: In the meantime, those who feel that it would be easier to write grub.cfg directly are encouraged to do so... and to disable any system provided by their distribution to automatically run grub-mkconfig.
Correct me if I'm wrong here but I don't think we have anything that automatically calls grub-mkconfig. Therefore manually creating/editing grub.cfg shouldn't be a problem. -- Chazza (talk) 15:01, 27 June 2015 (UTC)
+1, this will also avoid random notes like this in other articles. -- Lahwaacz (talk) 19:21, 27 June 2015 (UTC)
Nothing calls grub-mkconfig, no. Yet, I tend to disagree. Reasons: (1) the article is still too long anyway and the fresh start on manually creating grub.cfg is a good base to expand in tips&tricks. (2) Reducing grub-mkconfig basically also means having to touch most content that covers the main options in /etc/default/grub. If I see it right, the Arch package comes with defaults there. (3) Thankfully grub-mkconfig automatically figures menu entry names, but also determines a root= UUID by default these days. The latter not a big problem for simple roots, but cumbersome to describe for others (e.g. when a device mapper is used, lvm, luks, ...). Likewise, grub-mkconfig also uses output from os-prober to automatically generate entries.
So, I don't think it is a straight-forward task and make things clearer. The instances one would save on "Now re-generate the configuration: ..." would probably have to be replaced with "Now better check the result with grub-script-check /boot/grub/grub.cfg" ... I think it would be better to give GRUB/Tips and tricks#Manually creating grub.cfg more prominence and expand the fresh base there as required/wanted. Also some of the lengthy menu entry examples of GRUB#Automatically generating using .2Fetc.2Fgrub.d.2F40 custom and grub-mkconfig could be moved to a section there; they basically work/serve as examples for both (copy pasting into /etc/grub.d/40_custom or /boot/grub/grub.cfg). --Indigo (talk) 21:51, 27 June 2015 (UTC)
I agree with Indigo. -- 6arms1leg (talk) 12:48, 28 June 2015 (UTC)
About (1), the inclusion on manually generating grub.cfg would be accompanied by (another, but needed) rewrite of the GRUB article. On (2), similar argument as in (1), and things like modules can be expanded on where needed. (3) It's not because you're not using grub-mkconfig, that you won't use tools such as grub-probe and grub-script-check to facilitate some tasks.
As to clarity, most people just run "grub-mkconfig" without understanding the process at hand, and as such, have difficulties when problems arise.
Note: I won't have much time to work on this (besides other tasks, I'd prefer to create fdisk first). -- Alad (talk) 15:48, 28 July 2015 (UTC)
Some work was done by Nl6720 recently to merge the manual section into the main page. I have a more fully featured rewrite at User:Eschwartz/Grub#Configuration and I think I'm more or less happy with it now. I'd like to consider it for merging, and we can then drop some/most/all of the overly specific examples that have accumulated for /etc/grub.d/40_custom (which IMO add very little if anything).
Proposal: Drop the entire section GRUB#Custom grub.cfg and prepend my modifications before GRUB#Generated grub.cfg. Thoughts? -- Eschwartz (talk) 15:28, 8 January 2019 (UTC)
Must everything in GRUB#Custom grub.cfg be removed? Can't the examples from GRUB#Boot menu entries be integrated in User:Eschwartz/Grub#Examples? I find them useful. -- nl6720 (talk) 15:41, 8 January 2019 (UTC)
I'm open to expanding the examples section, but I think many of them are needlessly ornate. It's redundant to, for example, include multiple full copy-paste definitions of menuentries to execute halt/reboot (which I don't see as particularly useful), or to chainload the specific .efi executable used for the UEFI Shell. I'm unsure how much Windows stuff might be valuable to merge, but I'm highly suspicious that most of it could be made smaller at least. Like, I have no idea why this stuff checks $grub_platform per default. -- Eschwartz (talk) 15:54, 8 January 2019 (UTC)
I don't really see a problem with having a lot of detailed examples, working examples should make it easier for the reader to understand the syntax.
The $grub_platform check in the Windows entries is most likely useless since AFAIK for Windows changing the boot mode is not that simple and I don't think it supports both at the same time. -- nl6720 (talk) 16:11, 8 January 2019 (UTC)
I'm myself looking at the expansion template in [5], which end the new part. What I would do in that subsection is move and link the windows examples to the later detached examples section, replacing them with a very typical Linux one. For example, one with systemd hook boot parameters and one which crosslinks how to derive the correct lvm uuid. I agree it is still necessary to sieve the other existing examples, perhaps add a bullet list linking the most important ones. --Indigo (talk) 18:37, 13 January 2019 (UTC)
General examples section merged out of the grub-mkconfig subsection and linked in my examples section. Looking at options for further streamlining, suggestions welcome! -- Eschwartz (talk) 20:13, 13 January 2019 (UTC)
Hi, first, the intro you wrote for the manual section is super, very clear already and enhances the upstream doc. IMO it would be totally helpful to merge in as a drop-in replacement for GRUB#Custom grub.cfg right away.
At this point I'm not convinced it should prepend the GRUB#Generated grub.cfg as the first GRUB#Configuration section though. Let me give two examples:
Look at User:Eschwartz/Grub#RAID, it's inside the grub-mkconfig but actually describes grub-install and grub modules as well. I.e. the grub-mkconfig section mixes in the parts relevant for a first install. All this would have to be dis-entangled and crosslinked between both config sections first. What I am getting it is: Yes, a custom.cfg can be a slick three lines, but all that magic making them a working 50+ lines is shipped with supported defaults ([6] [7]), because the major GRUB configuration task is to (1) install the boot loader image correctly to the disk and (2) have a initramfs with matching boot options for the machine setup based on configured defaults. Just one more example for this: nowhere in the article there is an explicit mention of an "-fallback" menu entry. --> Because the /etc/grub.d/ script handles it, sourcing /etc/default/grub <-- variables in that file are a lot explanation to cover for any meaningful manual examples... or not?
So, to pre-pend the manual method as the first configuration section, there should first be a plan how to proceed with the more complex rest. My suggestion is to
  1. drop-in your new part to start existing "3.2 GRUB#Custom grub.cfg,
  2. Separate the dispensable menuentry{} examples into a new top-level "Examples" section (IMO ideally below current "4. GRUB#Using the command shell", because your new explanation is super helpful to lead over for command shell too), and remove/move/merge menuentries as appropriate (btw, I assume ordering User:Eschwartz/Grub#Multiple entries ff into "Encryption" is simply a glitch.). Meanwhile,
  3. work-out where the "configuration from scratch" should end/what of the not-straight-forward three-line .cfg's are covered in which section.
What do you think? --Indigo (talk) 12:29, 13 January 2019 (UTC)
First off, my rewrite and the main page have diverted a bit and I did not merge changes. I've now merged the current main page as-is with my rewrite dropped in where I suggested; this means there are now two sections for generating the custom grub.cfg, the latter of which is a boatload of custom.cfg things for grub-mkconfig to do like shutdown entries and stuff. Also, it is now much easier to grok the high-level organization of the page at a glance.
On the topic of things like RAID, would this be sufficient to include as references to how to write a filesystem path? I have no practical experience with RAID. Maybe we should merge this section into its own section as a child of User:Eschwartz/Grub#Configuration.
If it doesn't provide a suitable explanation linked to writing your own grub.cfg, I'm hesitant to merge as-is, because it shouldn't depend on grub-mkconfig docs whether listed before or after. On an unrelated note, I really don't want to relegate this to second, because I want people to see what I believe the superior method first. :p I guess that could be fixed later, true...-- Eschwartz (talk) 15:05, 13 January 2019 (UTC)
Yes, please don't start to merge as-is. If options are presented neutral, the order is secondary, exactly. --Indigo (talk) 18:37, 13 January 2019 (UTC)
I'm wondering if the best option would be to simply drop it altogether. The handwritten cfg already describes the need to insmod the drivers for additional partitions, and this includes both grub and lvm. Make a new toplevel section #4, "Filesystem-specific issues", in between GRUB#Configuration and GRUB#Using the command shell, which describes issues specific to installation in some given situation, and describe 1) the need to grub-install twice for RAID and 2) move GRUB#Encrypted /boot under that header.
Maybe expand the mkconfig section to specify how to preload a module -- though I'm unsure why it doesn't autodetect the need, what is this huge script even useful for? :p -- Eschwartz (talk) 00:04, 15 January 2019 (UTC)
Luckily I still kept my VMs with dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB) and a slightly modified dm-crypt/Encrypting an entire system#LUKS on software RAID. Adding modules to GRUB_PRELOAD_MODULES is not needed, grub-mkconfig detects them and puts them in grub.cfg where needed. -- nl6720 (talk) 09:55, 15 January 2019 (UTC)
I've implemented this in my rewrite as Special:Diff/563411, do you agree with this? EDIT: reworked it several more times -- Eschwartz (talk) 17:22, 15 January 2019 (UTC)
I don't think that is what nl6720 (pls correct if wrong) implied: Unfortunately, not that simple. grub-mkconfig will detect its required modules according to what's running, but that does not mean you can leave the user alone with the determination. LUKS is likely worst case (~5 out of a 22 gcry_*.mod). --Indigo (talk) 23:34, 15 January 2019 (UTC)
Actually, I suggest to stop this branch here as long as there is so much draft(ing)-in-progress. I know I started it too with making individual suggestions which Eschwartz integrated into his draft quickly, but at the same time my intention was also to reach a quick consensus to merge the new part over, so that reorganisation of existing other sections can be collaborated on step-by-step.
@Eschwartz: how about you open a talk item on User talk:Eschwartz/Grub or similar, ideally with a short wip status, then leave a link here? I'm sure nl6720 and others will contribute there equally. I will too; in fact I have at least one suggestion I consider extremely relevant for the current draft. Later, i.e. as soon as you see sections of the draft ready to merge, it is time to pick up here again. --Indigo (talk) 23:34, 15 January 2019 (UTC)
Done, further discussion will take place at User_talk:Eschwartz/Grub and I've copied over the two existing discussions. -- Eschwartz (talk) 00:07, 16 January 2019 (UTC)

Custom keyboard layout

Hi. Could we add a section explaining how you can set your preferred keyboard layout within GRUB2? As i found here, we need the ckbcomp script, which can be obtained from Debian console-setup package.

Here's how I made things work:

sudo mkdir /boot/grub/layouts
ckbcomp it |sudo grub-mklayout -o /boot/grub/layouts/it.gkb

Then, I manually edited /boot/grub/grub.cfg, adding the following lines:

/boot/grub/grub.cfg

terminal_input at_keyboard
keymap it

This worked for me, but as of now, i think it's a very dirty method. Is there some support for keyboard layouts within /etc/default/grub?

Cheers. --Hilinus 12:50, 26 December 2011 (EST)

I followed instructions on the grub-devel mailing list. First you insert
/etc/default/grub

GRUB_TERMINAL_INPUT=at_keyboard
in /etc/default/grub. Then you get ckbcomp Perl script from Ubuntu or Debian and execute (for Slovene layout)
$ ckbcomp si | grub-mklayout -o si.gkb
Unknown key KP_Comma
Unknown key KP_Comma
Unknown key KP_Comma
Unknown key KP_Comma
Unknown keycode 0x79
$ sudo mv si.gkb /boot/grub/
After that you add
/etc/grub.d/40_custom

insmod keylayouts
keymap /boot/grub/si.gkb
to /etc/grub.d/40_custom and finally generate new grub.cfg with
$ sudo grub-mkconfig -o /boot/grub/grub.cfg
Cheers. --drevo 17:47, 6 January 2012 (EST)
The version of ckbcomp I got from Debian Squeeze kept giving this error:
Unknown name $sun_t6_custom
The Ubuntu Precise version worked out of the box.
A temporary solution for layouts would be an AUR package for ckbcomp or to distribute .gkb files somehow, but the proper solution would be for grub-mklayout to accept keymaps(5) files.
--Schizius (talk) 18:44, 26 July 2012 (UTC)
This won't work if /boot is on another root partition. At home / is on lvm and /boot on standard MBR partition. This was historical. But since grub.cfg is generated with the root partition in lvm, it can't find my keyboard layout.
The clean solution is to create a new file /etc/grub.d/50_keymapand put this:
#!/bin/sh
set -e
# Include the GRUB helper library for grub-mkconfig.
. /usr/share/grub/grub-mkconfig_lib
KEYMAP_FILE=/boot/grub/bepo.gkb
if ! prepare_grub_to_access_device "`${grub_probe} --target=device "${KEYMAP_FILE}"`"; then
	return 6--~~~~
fi
KEYMAP_FILE=$(make_system_path_relative_to_its_root "${KEYMAP_FILE}")
cat <<EOF
insmod keylayouts
keymap "${KEYMAP_FILE}"
EOF
So that the root partition is detected, loaded, and then the file is read within that partition.
--Glandos (talk) 08:23, 14 November 2013 (UTC)
Is Glandos's solution to be used in addition to the Perl script, or is it a standalone solution? I get the vague sense that it is to be used as an additional step only when your /boot is located in its own partition. If someone can clarify this, I will add the above steps to the wiki and test them out, because I was looking for a solution to this same issue. ingegnue (talk) 09:39, 5 October 2014 (UTC)
There is a discussion further down the page about restructuring and cleaning up the GRUB article. I will make a suggestion to add a section like this in that discussion. This way we can see how much demand there is for it and get suggestions about where to put it and how to structure it. I will make a note of all of this information, and gather some more to build content for the section. Since I am moving this suggestion to the main discussion below, I move to close this. If anyone has any feedback regarding this please add it please. I move to close this so I may add it to the main section below. (All information has been saved in roder to reproduce if necessary.)
--Stevenmw (talk) 19:30, 3 December 2014 (UTC)
Reopening this talk since I've hit this issue myself... -- Alad (talk) 06:31, 3 August 2015 (UTC)
This issue gets very important now that disk encryption becomes more popular and users have to type their passphrase during grub boot phase. I think there has to be something in the documentation for setting a locale in grub2. As for Ubuntu, it works out of the box and I'd love to have a clean howto to change the keymap in GRUB2. Guess what ? A complete guaranteed recipe is hard to find on the net. Those comments where very handy for me.
Skizorutabaga (talk) 18:05, 23 July 2016 (UTC)
There is, for UEFI: GRUB/Tips_and_tricks#Manual_configuration_of_core_image_for_early_boot. -- Lahwaacz (talk) 18:10, 23 July 2016 (UTC)
grub-kbdcomp /tmp/fr.gkb fr can also create keyboard layout for at_keyboard
Note that at_keyboard does not always work. If at_keyboard freeze your system, you may have to use use usb_keyboard or console, so you could not use your layout...
cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741464
—This unsigned comment is by Ryuta (talk) 04:11, 29 July 2017‎. Please sign your posts with ~~~~!

grub standalone

two things:

1- I think the switch

--fonts="unicode"

have to be removed since it is already the default behaviour (source: man grub-mkstandalone)

2- before executing the command `grub-mkstandalone ...`, create the directory in your esp (e.g. /boot/EFI) otherwise it will fail

--nTia89 (talk) 09:34, 9 April 2016 (UTC) done! --nTia89 (talk) 17:28, 8 February 2017 (UTC)

Grub Shell normal linux booting

A little improvement in GRUB Shell secction. When it is described the following example in GRUB#Using_the_rescue_console


An example, booting Arch Linux:

set root=(hd0,5)
linux /boot/vmlinuz-linux root=/dev/sda5
initrd /boot/initramfs-linux.img
boot

With a separate boot partition (e.g. when using EFI), again change the lines accordingly:

Note: Since boot is a separate partition and not part of your root partition, you must address the boot partition manually, in the same way as for the prefix variable.
set root=(hd0,5)
linux (hdX,Y)/vmlinuz-linux root=/dev/sda6
initrd (hdX,Y)/initramfs-linux.img
boot

I think it's imortant to say which partition is the root (/) and which is /boot, because it says sda5 and sda6, but it could be confusing. For example, to me, I don't really understand which is each one. Can someone explain it better? Thank you.

Cmolina (talk) 17:54, 13 August 2016 (UTC)

That is indeed confusing. I don't use GRUB, but I would guess that set root= is setting the root of the console so that you can specify where the kernel/ramdisk is, which would be /boot. Then when you boot linux you need to pass the usual kernel parameter root= specifying where the linux filesystem is.
Silverhammermba (talk) 19:34, 13 August 2016 (UTC)


Yes, I think is what you say. In facts, I tried to set root= to my /boot partition and then I specified the root= for linux system, which is my partition mounted to / and it was OK. So I think we could explain it better in the wiki.
Cmolina (talk) 19:47, 13 August 2016 (UTC)

De-duplication of section header

ATM there is a duplicate header anchor:

  • "Installation" links to the installation procedure for BIOS.
  • "Installation" → "Installation_2" links to the installation procedure for UEFI.

After some chat in IRC #archlinux-wiki, I am changing the second header from "Installation" to "Install", so to avoid this duplication of headers.

In the same edition, I am also leaving a temporal manual anchor for "Installation_2", so as to minimize breaking links, considering the importance of this particular section of this particular wiki page. The reasoning for leaving a temporal manual anchor is that internal links are relatively easy to correct (right after renaming the header), whereas external links aren't.

Examples of "external links" I am thinking about are:

  • Current / recent forum posts with links to the particular header / section.
  • Current / recent email threads / discussions with links to the particular header / section.
  • Other current / recent / relevant places / pages / sites with links to the particular header / section.

The intention of this temporal manual anchor is to allow such potential recent links to still be valid (instead of leaving broken links), so users / readers / participants of conversations would still be able to make sense of such links and surrounding text / context, at least for some time.

Not every single header's renaming deserves leaving a (temporal) manual anchor (i.e. in most cases, I wouldn't be leaving a manual anchor) but in this case I consider this wiki page and this section to be particularly important / popular / relevant for too many users.

After some time, once current potential posts / emails containing links to the aforementioned section would be considered "old enough" (say, a month?), the manual anchor could be removed.

When I'm done with the edition I'll add a comment here. Ady (talk) 16:53, 6 March 2017 (UTC)

What exactly was wrong with the duplicate header? -- Lahwaacz (talk) 17:14, 6 March 2017 (UTC)
Duplication of section headers are a potential problem because they generate an automatic anchor with a trailing number ("Installation", "Installation_2", "Installation_3") which can _vary_ depending on the location / order of the header within the page. IOW, moving a section means that a link such as [[GRUB#Installation_2]] would point to a different section than what was originally intended.
Anyway, the edition is done [8] and I also corrected the corresponding internal links (in the main namespace).
I intend to remove the manual anchor in some time (a month?). Ady (talk) 17:31, 6 March 2017 (UTC)
Do you plan to change the order of these sections? Otherwise you're just solving a fabricated problem - the headings are like this this since 2014 when they were changed from something completely different, I don't think there was ever a change which just changed the order of two sections with the same heading. If such problem really appeared in practice, the best solution would be to rename the sections after swapping them, which would invalidate the old links. This way old links will be invalidated for no reason and probably the first person wondering why these headings are different might rename them back for coherence. -- Lahwaacz (talk) 18:08, 6 March 2017 (UTC)
Just in case and FWIW, for the very basic info about the matter, see https://en.wikipedia.org/wiki/Help:Link#Duplicate_section_names
Renaming, moving, restructure... It happens all the time, with consequences. The fact that (some/many) editors don't notice / know / care about consequences of their editions doesn't mean that section header duplication is not a problem.
Some editors don't even bother to summarize their editions, some of which are not always "the right thing to do".
OTOH, I ask for feedback at IRC #archlinux-wiki, I explain the reasoning in the Talk Page, I perform the edition, I fill in a relevant edition summary, I take care of the internal links that are affected by the edition, and I also minimize the potential impact on external links (which many wiki editors and maintainers don't even consider before performing editions). Then I come back to the Talk Page to inform about the changes that were performed. I think I've done the right thing, and I think my edition was adequate. Ady (talk) 08:07, 7 March 2017 (UTC)
I vote for reverting [9], [10] and [11]: having an "Installation" heading in the BIOS section, and "Install" in UEFI looks incoherent/unnatural, and as Lahwaacz points out, it just begs for somebody to fix it, which will happen sooner or later especially after removing the anchor (and hence breaking all its remaining backlinks), and even more especially if the article will really ever be radically restructured. In w:Help:Link#Duplicate_section_names the numbered suffix is presented as a feature, not a problem to work around, and IMO in general the least problematic way to edit the wiki is to do it in the way that the MediaWiki devs designed it. If one day we will have to swap "GRUB#Installation" links with "GRUB#Installation_2" we'll easily do it with a bot. — Kynikos (talk) 09:48, 8 March 2017 (UTC)
The Wikipedia link is the description of the feature, not the problem. The fact that the feature exists doesn't mean that duplication of headers is recommended or welcomed; on the contrary.
Had I performed a simple renaming on both headers and nothing more (as most editors do all the time, without caring / understanding its consequences), we would not be wasting time with this. Possibly I should not even care to edit at all. I think this simple matter is not worth spending more time on it. Ady (talk) 10:25, 8 March 2017 (UTC)
>"Possibly I should not even care to edit at all"
What I don't understand is why apparently it's often impossible to accept disagreement and different opinions without taking them as personal affronts. Even if an edit is minor it doesn't mean that it's accepted just because of that, nonetheless nobody has reverted your edits yet, Lahwaacz hasn't even taken a definitive stance on the matter, can we please keep calm an reasonable, also considering the very minor nature of this issue?
Instead of winging we could discuss compromises such as renaming those headings in neater ways, e.g. "BIOS installation" and "UEFI installation". As I said we can always use bots to change the backlinks.
Kynikos (talk) 11:29, 8 March 2017 (UTC)
I'm not taking this personally (although I do value my own time), and I'm OK with disagreements. My point is that if I would had performed the renaming in the same way as others do all the time, then we wouldn't be discussing it. I could say more, but I'd rather focus on practical results and not waste more time.
WRT a different renaming as a compromise, I am very much in favor. In fact, my initial idea was to rename both headers, "Installation on BIOS" and "Installation on UEFI" (or "Install on..") respectively. But renaming both headers in this way would mean that:
  • even more external links could be potentially affected;
  • many more internal links would need to be updated in comparison to renaming only one of the headers (and I was doing them manually, one by one);
  • there was a disagreement in IRC #archlinux-wiki about adding "... BIOS" and "... UEFI" in the headers when they are already subsections under the respective BIOS and UEFI sections.
Now, if ("Install on BIOS" and) "Install on UEFI" is/are acceptable — they are to me — please go ahead.
In such case, leaving a temporal manual anchor also for the first header would be a plus IMO. Ady (talk) 12:44, 8 March 2017 (UTC)
I agree with Kynikos that we should revert to the original, unproblematic state of headings until somebody comes up with a radical way to restructure the article's sections.
>"My point is that if I would had performed the renaming in the same way as others do all the time, then we wouldn't be discussing it."
You are right about this, in that case I would have simply reverted the renaming instead of joining this discussion.
>"leaving a temporal manual anchor also for the first header would be a plus"
FWIW I don't see any value in doing that. Internal links to the affected sections can be updated so quickly (with a bot) that it would be a waste of time, external links from resources that "don't care for updates" won't be updated anyway and external resources that absolutely need to preserve the temporal validity of the links should use permalinks. Which alternative am I missing?
-- Lahwaacz (talk) 15:50, 8 March 2017 (UTC)
A simple reversion of those 3 edits was still my first choice, so I've jsut done it. I'm closing this discussion since apparently it didn't attract anybody else's interest: according to Help:Discussion it will still be visible at least for another week anyway. — Kynikos (talk) 11:32, 9 March 2017 (UTC)

Dual Booting Windows.

In the section on dual booting windows there is a section giving instructions for people booting BIOS-MBR


if [ "${grub_platform}" == "pc" ]; then
 menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {
   insmod part_msdos
   insmod ntfs
   insmod search_fs_uuid
   insmod ntldr     
   search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE
   ntldr /bootmgr
 }
}

This probably works fine for most people. but if you run a BIOS-GPT setup to load GRUB and then want to load a BIOS-MBR windows setup on a separate drive. this wont work unless you remove the if statement. presumably the original author did not consider the fact that you could have both GPT and MBR in the same system on different drives.

—This unsigned comment is by Theholyduck (talk) 18:46, 23 May 2017‎. Please sign your posts with ~~~~!

Perhaps what you indicated should be added in the same section or in another section regarding dual booting Windows. Have you tested exactly what you stated and you know it works when you remove the if statement?
Alchemek (talk) 17:07, 12 June 2017 (UTC)

Has anyone besides the contributor got directly booting to work? [12] I am the person who has added in the chainloading method because after some significant time I could not get the direct booting method working on my machine despite the fact that I do indeed have a BIOS-MBR configuration with Windows 10. I think we should have both methods because, as far as I know, the Arch Wiki has had the chainloading method available for a very long time and it always works. Further, Microsoft tends to do weird things with its files, so there's no telling when direct booting will or will not work depending on what Microsoft decides to do. By contrast, the chainloading method avoids this issue almost entirely.

Alchemek (talk) 17:07, 12 June 2017 (UTC)

I'm chainloading too, tested the "normal" method to no avail when i got some problems installing GRUB. I would like to add, if one's machine is eqipped with an UEFI firmware, and the chosen partition table is MBR, before running through the installation it's better to check the boot preferences and/or select the proper USB drive method to boot, since UEFI boot manager may have a higher priority and "corrupt" the bootloader installation. Also, in this case, when booting an USB Archiso live one should be good-to-go if the coloured Arch Linux boot menu appears (instead of a minimal black screen/white font boot menu with some UEFI options). Forgetting or ignoring to check this before installing and configuring GRUB, lead to the result that Windows (in my case, 8.1) won't be booted (even after adding a proper 40_custom configuration) nor os-prober will be able to find it. Finally, as @Alchemek may guess, even in this case Windows needs to be booted by chainloading its boot manager. Documentation about this seems missing/scarce due to the singularity of the case, but i think adding it to the Wiki should do no harm. Lo1 (talk) 20:40, 25 October 2017 (UTC)Lo1

GRUB with EFI partition on NVMe drive

So I managed to finally get GRUB to work on a system that has an NVMe SSD as its main drive and an HDD as it's secondary drive. As you can imagine the NVMe drive is called /dev/nvme0n1 and the HDD /dev/sda. I mounted the second partition of my nvme drive under the /boot directory and installed grub there. However what I ended up wasting hours is the fact that GRUB ended up making an EFI entry for /dev/sda2 (which was not mounted, nor was it even detectable at the time of running grub-install) instead of /dev/nvme0n1p2, which was mounted at the time. I ended up noticing this because the partition UUID was incorrect for the partition it was supposed to point to.

So my question is whether I should add a warning somewhere on the page to make sure to check the partition UUID when creating an entry when using an NVMe drive or if I should add a subtitle in the Troubleshooting section explaining the issue and it's solution?

After looking into this more, I found out that this seems to be a weird issue with my BIOS changing it on the first time the machine is booted with a newly created boot entry, after which I just deleted it and manually recreated it in the BIOS Setup. I will also add this to the page about my specific laptop in the Laptop page. As such I consider this closed but have no idea how to close a discussion... Deathary II (talk) 02:25, 18 January 2019 (UTC)