Talk:GRUB

From ArchWiki
Latest comment: 26 November 2023 by Durag in topic LUKS2 in 2.12rc1

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)Reply
What is the current sate of this issue? --Stevenmw (talk) 10:56, 6 December 2014 (UTC)Reply
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)Reply

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)Reply

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)Reply
+1, this will also avoid random notes like this in other articles. -- Lahwaacz (talk) 19:21, 27 June 2015 (UTC)Reply
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)Reply
I agree with Indigo. -- 6arms1leg (talk) 12:48, 28 June 2015 (UTC)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply

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)Reply
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)Reply
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)Reply
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)Reply
Reopening this talk since I've hit this issue myself... -- Alad (talk) 06:31, 3 August 2015 (UTC)Reply
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)Reply
There is, for UEFI: GRUB/Tips_and_tricks#Manual_configuration_of_core_image_for_early_boot. -- Lahwaacz (talk) 18:10, 23 July 2016 (UTC)Reply
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 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)Reply

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)Reply


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)Reply

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)Reply

What exactly was wrong with the duplicate header? -- Lahwaacz (talk) 17:14, 6 March 2017 (UTC)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
>"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)Reply
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)Reply
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)Reply
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)Reply

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)Reply

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)Reply

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)Lo1Reply

Graphics card maybe cause shell output some log

My laptop has two card: intel (mesa intel uhd graphics 620) and NVDIAI 1050. And i use optimuse-manager to manage my card. Then I have install intel-media-driver , libvdpau, xf86-video-intel, libva-mesa-driver, mesa-vdpau, vulkan-intel, vulkan-mesa-layers, and lib32*

I install these packages for hardware acceleration.

Now, I login KDE through Intel Card, and run grub-mkconfig -o /boot/grub/grub.cfg, some information were be given:

Generating grub configuration file ...
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9880: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9880: /usr/bin/grub-probe
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9880: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9880: /usr/bin/grub-probe
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9906: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9906: /usr/bin/grub-probe
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9906: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9906: /usr/bin/grub-probe
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9930: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9930: /usr/bin/grub-probe
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9930: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9930: /usr/bin/grub-probe
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9955: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9955: /usr/bin/grub-probe
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9955: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9955: /usr/bin/grub-probe
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9979: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9979: /usr/bin/grub-probe
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9979: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9979: /usr/bin/grub-probe
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10074: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10074: /usr/bin/grub-probe
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10074: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10074: /usr/bin/grub-probe
Found linux image: /boot/vmlinuz-linux
Found initrd image: /boot/intel-ucode.img /boot/initramfs-linux.img
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10167: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10167: /usr/bin/grub-probe
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10167: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10167: /usr/bin/grub-probe
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10192: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10192: /usr/bin/grub-probe
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10192: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10192: /usr/bin/grub-probe
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10216: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10216: /usr/bin/grub-probe
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10216: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10216: /usr/bin/grub-probe
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10241: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10241: /usr/bin/grub-probe
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10241: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10241: /usr/bin/grub-probe
Found fallback initrd image(s) in /boot: initramfs-linux-fallback.img
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10425: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10425: /usr/bin/grub-probe
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10425: /usr/bin/grub-probe
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10425: /usr/bin/grub-probe
Found Windows Boot Manager on /dev/nvme0n1p2@/EFI/Microsoft/Boot/bootmgfw.efi
done

This situation have happended some times beform today.

You see, so much log were given me, I watch this: /dev/dri/renderD128, I guess it maybe caused by card driver. So I relogin KDE thourgh NVIDIA card, rerun this command, there is nothing happend, no so much log.

So, I guess hardware acceleration driver maybe cause shell output more log. But I cannot whether this information should write in this wiki.

Dragonwater (talk) 13:15, 27 July 2020 (UTC)Reply

Add information how to generate the bootable files

After the creation of both BIOS and UEFI partitions (probably in the subsection Installation) one has to be sure that bootable images are actually present in /boot before running grub-mkconfig (I'm not sure that that is needed for UEFI though, because an .efi is generated by grub, but I think it's needed too). In BIOS/Legacy setup if the /boot contains only grub/ subfolder (not kernel images), grub loads only the command shell, not the OS.

I suggest adding a line about that and that they can be generated with

pacman -S

This seems to be a small duplication, but I think the easiest would be to add this line both to BIOS and UEFI sections. I also remember that I already suggested that on EFISTUB page.

Another option would be to create a "Generate bootable images (?)" page and link to there in every place. But I think that for a short instruction a small insertion is better than a whole reference.

Ynikitenko (talk) 16:37, 16 November 2020 (UTC)Reply

Nothing about this makes sense. You deleted your kernel, then expect the docs to know that you screwed up? Scimmia (talk) 14:34, 17 November 2020 (UTC)Reply
Everything about this makes sense. You have to install a kernel in between "create the partition" and "install GRUB". The page should be self-consistent, and not assume you are using a recipe from a page somewhere else. Ynikitenko (talk) 14:54, 17 November 2020 (UTC)Reply
If you're not using the official Installation Guide, you're not on Arch and are on your own anyway. Scimmia (talk) 14:58, 17 November 2020 (UTC)Reply
GRUB page is not a subpage of "Installation Guide", is it? A user may install and change their partitions and files during or after Arch installation. Do you propose to repeat the installation process if you format the boot partition? Ynikitenko (talk) 15:02, 17 November 2020 (UTC)Reply
I propose that if you format the boot partition, you have some idea what you're doing. Scimmia (talk) 15:05, 17 November 2020 (UTC)Reply
I did that, and I share my findings to improve this article. If you have other arguments against or for this edit, feel free to write them. Ynikitenko (talk) 15:42, 17 November 2020 (UTC)Reply

grub 2.06 "error: verification requested but nobody cares"

When using boot encryption with grub 2.06, error "verification requested but nobody cares" can be worked around by using method described on https://wejn.org/2021/09/fixing-grub-verification-requested-nobody-cares.

In short, after issuing "grub-install --target=x86_64-efi ..." and before signing the image, do sed -i 's/SecureBoot/SecureB00t/' /efi/EFI/GRUB/grubx64.efi

I've added a comment to https://aur.archlinux.org/packages/cryptboot/ if anyoe is usign this tool. Dominik (talk) 15:06, 7 January 2022 (UTC)Reply

I fixed it by doing this
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB --modules="normal test efi_gop efi_uga search echo linux all_video gfxmenu gfxterm_background gfxterm_menu gfxterm loadenv configfile tpm" --disable-shim-lock
I don't think the solution listed here is secure? Afader (talk) 23:13, 26 January 2022 (UTC)Reply

Highlight importance of adding or removing '/boot' from path in 'initrd=..' lines in configuration

Many of the initrd lines in grub configuration consider boot as a directory in root, But the note on changing the line to remove the /boot in the case of separate /boot partitions should be mentioned more strictly and widely as otherwise users will end up with unbootable systems with ... not found errors. —This unsigned comment is by RaZorr (talk) 13:41, 24 March 2022 (UTC). Please sign your posts with ~~~~!Reply

Grub fallback variable

Grub has a fallback variable that has been used elsewhere [1,2 and 3] to manage unsuccessful boots. Do you think is worth mentioning it under GRUB#Boot_menu_entry_examples? Rahcor (talk) 00:55, 17 April 2022 (UTC)Reply

Upgrade to 2.06

It seems lots of users (included myself) have errors with the migration from grub 2.0.6.r566.g857af0e17-1 tom 2.06(-rc). We need to use `--disable-shim-lock` as an option in grub-install. It could deserve to mention--Xan (talk) 09:56, 16 July 2023 (UTC)Reply

LUKS2 in 2.12rc1

I recently did the setup for an encrypted boot partition using the new version 2.12rc1 and LUKS2. Basically, all I had to do is to set GRUB_ENABLE_CRYPTODISK=y in /etc/default/grub and make sure the LUKS2 volume is using PBKDF2 instead of Argon2id or Argon2i. Since I'm unsure about LVM or Btrfs, I was using an ext4 filesystem, I haven't updated the section yet. But the /boot/grub/grub-pre.cfg is definitely not required for a simple setup like mine anymore. --Moabeat (talk) 17:16, 26 September 2023 (UTC)Reply

I changed this in https://wiki.archlinux.org/index.php?title=GRUB&oldid=791197 after confirming that my previous scripts involving grub-mkconfig are no longer needed. grub-install creates a bootable image for me using grub 2:2.12rc1-5. Lekensteyn (talk) 17:46, 26 October 2023 (UTC)Reply
I just tried to use LUKS2 with PBKDF2 on an completely encrypted system with encrypted boot and BTRFS as filesystem. I was not able to decrypt my drive on boot. No problem with the same configuration and LUKS1. Durag (talk) 17:57, 27 October 2023 (UTC)Reply
I was able to solve it - had to set the hash to sha256. Durag (talk) 10:33, 9 November 2023 (UTC)Reply
With which version is booting with LUKS2 possible? I tried with 2.06-13+deb12u1 but I couldn't get it to work even after converting the keyslot to PBKDF2. Maybe because it used sha512 while the AF hash was sha256. I then tried converting it to LUKS1 with `cryptsetup convert` but it refused to do so. Reading through the source of cryptsetup I found that it checks that the keyslot hash needs to be equal to the AF hash. After editing the keyslot again to change the hash to sha256, I converted it to LUKS1 and could decrypt and boot from it. I didn't try LUKS2 with sha256 all-around. Jjakob (talk) 13:44, 26 November 2023 (UTC)Reply
I've tested with the official Arch GRUB package and grub-improved-luks2-git from the AUR - both in version 2.12.rc1.
I was only able to use LUKS2 with PBKDF2 and sha256.
LUKS2, PBKDF2 and sha512 didn't work with neither of both versions. Durag (talk) 14:16, 26 November 2023 (UTC)Reply

Split off boot loader installation from package installation

To follow a change that was initially started in rEFInd, I propose to split GRUB installation into two top level sections: "Installation" for package installation instructions and "Installing the boot loader" for the instructions on installing GRUB to the disk and using it as the boot loader. Basically, the structure would change from:

  1. Supported file systems
  2. UEFI systems
    1. Installation
    2. Secure Boot support
      1. CA Keys
      2. Shim-lock
      3. Using Secure Boot
  3. BIOS systems
    1. GUID Partition Table (GPT) specific instructions
    2. Master Boot Record (MBR) specific instructions
    3. Installation

to something like this (subsection names are subject to change):

  1. Supported file systems
  2. Installation
  3. Installing the boot loader
    1. UEFI systems
      1. Secure Boot support
        1. CA Keys
        2. Shim-lock
        3. Using Secure Boot
    2. BIOS systems
      1. Prerequisites for GUID Partition Table (GPT)
      2. Installing on BIOS systems

-- nl6720 (talk) 12:49, 12 November 2023 (UTC)Reply