Difference between revisions of "Talk:GRUB"

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)

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/

/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 [5] 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 [6], [7] and [8]: 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? [9] 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)