From ArchWiki
Jump to: navigation, search

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:


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

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

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:
set -e
# Include the GRUB helper library for grub-mkconfig.
. /usr/share/grub/grub-mkconfig_lib
if ! prepare_grub_to_access_device "`${grub_probe} --target=device "${KEYMAP_FILE}"`"; then
	return 6--~~~~
KEYMAP_FILE=$(make_system_path_relative_to_its_root "${KEYMAP_FILE}")
cat <<EOF
insmod keylayouts
keymap "${KEYMAP_FILE}"
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 standalone

two things:

1- I think the switch


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

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

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)