Difference between revisions of "Talk:GRUB"

From ArchWiki
Jump to: navigation, search
(Close finished topic.)
m
 
(266 intermediate revisions by 48 users not shown)
Line 1: Line 1:
== <s> Grub2 vs grub-gfx </s> ==
+
== Alpha sorting for kernel names without versions ==
'''Q:''' So what are the advantages of using grub2 instead of grub-gfx ? --[[User:Oliwer|Oliwer]] 23:44, 26 December 2008 (EDT)
 
  
'''A''': Grub-gfx only adds the support for .xpm files, grub2 instead has builtin support for .tga, .jpeg/.jpg and .png formats. At some point the .tft files will also be supported (the ones that grub2-gxmenu supports) but I dunno when that's gonna happen.
+
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:
--[[User:Det|Det]] 10:22, 24 February 2010 (EST)
 
  
== System Recovery Section ==
+
* https://savannah.gnu.org/bugs/index.php?42597
  
I suggest we something like this for people who do not back up there old grub installation and forgot to generate their cfg file.
+
Forum discussion w/patch:
  
From an Arch Live Cd Do Prepare Hard Drives, Manually Configure Mount Points, Make Sure These Are the Same as your original Arch Installation
+
* https://bbs.archlinux.org/viewtopic.php?pid=1428523
  
Switch to Another Window and Chroot into Your Installed Arch
+
: [//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)
  
mount -o bind /dev /mnt/dev
+
::What is the current sate of this issue? --[[User:Stevenmw|Stevenmw]] ([[User talk:Stevenmw|talk]]) 10:56, 6 December 2014 (UTC)
  
mount -t proc /proc /mnt/proc/
+
:::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)
  
mount -t sysfs /sys /mnt/sys/
+
== Manually generate grub.cfg ==
  
chroot /mnt bash
+
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)
  
Then generate the config file.
+
::+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)
  
GRUB_PREFIX="/boot/grub" grub-mkconfig -o /boot/grub/grub.cfg
+
::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)
  
== Grub2 1.98 ==
+
:::I agree with [[User:Indigo|Indigo]]. -- [[User:6arms1leg|6arms1leg]] ([[User talk:6arms1leg|talk]]) 12:48, 28 June 2015 (UTC)
  
The new stuff brought by 1.98 should probably be explained. --[[User:Det|Det]] 10:57, 16 March 2010 (EDT)
+
::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)
  
'''E:''' I added a few "/etc/default/grub notes". The article only needs a bit expansion and the move from those notes I made to the actual instructions, anymore. --[[User:Det|Det]] 13:44, 28 March 2010 (EDT)
+
== Custom keyboard layout ==
  
'''E2:''' OK, done. I changed the notes to the actual instructions and removed the '''Expansion''' flag. If somebody feels that the other stuff too, such as what's in /etc/grub.d/* should be mentioned here, you are free to re-add the flag. I did some other stuff too, which you can check from the page history if you are interested. The only problem is that I'm still that stupid that I test the changes by updating the page itself, which makes the page history go nuts. Just give me some time to get used to the magic *Show preview* button :). --[[User:Det|Det]] 15:58, 8 April 2010 (EDT)
+
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.
  
== Upgrading from grub 0.97 to grub2 - MBR ==
+
Here's how I made things work:
  
To fix the problem described on section [[GRUB2#Other]] you can remove grub 0.97 from MBR by following command:
+
sudo mkdir /boot/grub/layouts
<pre>dd if=/dev/zero of=/dev/sdX bs=446 count=1</pre>
+
ckbcomp it |sudo grub-mklayout -o /boot/grub/layouts/it.gkb
where /dev/sdX is hard disk with grub installed in MBR (I have no idea if that works when you have grub installed on partition instead of hd, like /dev/sda1).
 
  
It is good idea to create backup of bootloader before that by executing:
+
Then, I manually edited {{ic|/boot/grub/grub.cfg}}, adding the following lines:
<pre>dd if=/dev/sdX of=your/backup.img bs=446 count=1</pre>
 
After that you can install grub2 on MBR, and it works (hopefully) without any dirty hacks.
 
  
== Make up your mind on when to modprobe dm-mod ==
+
{{hc|/boot/grub/grub.cfg|
@Skodabenz & NTia89
+
<nowiki>
:On Feb 17 NTia89 took the time to suggest the probing of dm-mod at the beginning of the Installation section, not deleting it from the section below but just inserting a note. On Mar 15 Skodabenz only removed the modprobe command inserted by NTia89, but not the related note, so this leaves the article inaccurate on stating when to load dm-mod. I think either the note should be removed (if Skodabenz is right), or the modprobe dm-mod command should be moved to the beginning of the Installation section (if NTia89 is right)). I cannot test this at the moment. -- [[User:Kynikos|Kynikos]] 14:13, 15 March 2011 (EDT)
+
terminal_input at_keyboard
 +
keymap it
 +
</nowiki>}}
  
@Kynikos: Whether grub2 install happens during Arch Linux installation or in a existing system, dm-mod (device-mapper module) needs to be loaded for the sake of grub-setup utility. Even during Arch Linux installation, the user has to anyway go to one of the bootloader installation section where dm-mod loading comes again. Therefore i do not think it is appropriate to move it to the beginning of the Installation section since it is not specific to Arch Linux installation. Also where is the 'related note' you are talking about? -- [[User:the.ridikulus.rat|Keshav P R]] 17:37, 16 March 2011 (EDT)
+
This worked for me, but as of now, i think it's a very dirty method. Is there some support for keyboard layouts within {{ic|/etc/default/grub}}?
  
:Perfectly explained, thanks. The "related note" is this one I've just removed ([https://wiki.archlinux.org/index.php?title=GRUB2&action=historysubmit&diff=133989&oldid=133721 see diff]); it was added by NTia89 when he edited the article. -- [[User:Kynikos|Kynikos]] 19:53, 16 March 2011 (EDT)
+
Cheers. --[[User:Hilinus|Hilinus]] 12:50, 26 December 2011 (EST)
  
== EFI ==
+
:I followed [http://lists.gnu.org/archive/html/grub-devel/2011-03/msg00051.html instructions] on the grub-devel mailing list. First you insert
  
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.
+
{{hc|/etc/default/grub|
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.
+
<nowiki>
 +
GRUB_TERMINAL_INPUT=at_keyboard
 +
</nowiki>}}
  
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)
+
:in {{ic|/etc/default/grub}}. Then you get ckbcomp Perl script from Ubuntu or Debian and execute (for Slovene layout)
 +
 
 +
:{{bc|<nowiki>
 +
$ 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/
 +
</nowiki>}}
  
 +
:After that you add
  
@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.
+
{{hc|/etc/grub.d/40_custom|
 +
<nowiki>
 +
insmod keylayouts
 +
keymap /boot/grub/si.gkb
 +
</nowiki>}}
  
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)
+
:to {{ic|/etc/grub.d/40_custom}} and finally generate new grub.cfg with
  
== grub-mkconfig and UEFI ==
+
:{{bc|$ sudo grub-mkconfig -o /boot/grub/grub.cfg}}
  
The grub-mkconfig script seems to be hardcoded to have /boot/grub as the grub install. Is the best answer for this to mount /efi/grub as /boot/grub or edit the script?
+
:Cheers. --[[User:drevo|drevo]] 17:47, 6 January 2012 (EST)
  
http://comments.gmane.org/gmane.comp.boot-loaders.grub.devel/17950 -- [[User:The.ridikulus.rat|Keshav P R]] 09:57, 19 October 2011 (EDT)
+
::The version  of ckbcomp I got from Debian Squeeze kept giving this error:
  
== Confusing information on a running system; combining MBR and GPT information; an initial MBR portion that seems contradicted later ==
+
::{{bc|Unknown name $sun_t6_custom}}
  
I started working through this; it looks like the installation is easy, at the top.  Then there are more MBR instructions that require additional preparation, but it isn't clear if this is replacement information to the initial instructions, or more detailed information.  If the top information is inadequate, it should be deleted and put into the MBR detailed instructions.  If it is one way of doing it that does not require the more detailed instructions, that should be noted as well.
+
::The Ubuntu Precise version worked out of the box.
  
Should be clear now -- [[User:The.ridikulus.rat|Keshav P R]] 14:53, 24 October 2011 (EDT)
+
::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.
  
Ok, another one.  I know I'm literal, and sometimes that's good, other times bad.
+
::--[[User:Schizius|Schizius]] ([[User talk:Schizius|talk]]) 18:44, 26 July 2012 (UTC)
  
The page talks about installing to the 440-byte area.
+
:::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.
Then later it talks about replacing legacy in that area.
+
:::The clean solution is to create a new file ''/etc/grub.d/50_keymap''and put this:
That doesn't make sense to me.
 
  
What I'm really seeing, I think, is that there are so many ways of going about this that it might make sense to split this page into a couple; EFI - GPT - MBR. There may be some duplication in that, but trying to figure out what applies to what is difficult, at least for me. I think the overlapping technology changes make it seem more difficult than it is.
+
:::{{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>}}
  
I've been trying unsuccessfully to install this for a couple of days (gave up on a running system and just started from scratch; good backups are handy things); and while it may make more sense for me to do it in a different order, I don't understand it enough to feel comfortable contributing many changes to the article, as my interpretation may well be wrong.  I'm no newbie, but neither am I a master.
+
:::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)
  
There are many ways to install grub2 - UEFI is easy part, only one way (to the UEFI SYSTEM PARTITION). But in case of bios, you can install to the disk's MBR boot code region (in which case it becomes the primary or the only bootloader of the system), to a partition (in which case it need to be chainloaded from the primary bootloader) or generate the core.img (again needs to be chainloaded by another bootloader, difference being chainloading a file instead of partition boot sector). I created the sections in the article based on my understanding of the sectioning etc. I tried to avoid duplication mainly.
+
::::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)
  
About your problem, its better to open a thread in the forum wherein we can discuss what exactly is preventing you from installing grub2. I have installed grub2-bios to MBR 440-byte area (GPT partitioning) and grub2-efi-x86_64 to UEFISYS partition (both in the same system and in the same disk).
+
::::::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)
  
(also please sign your text - I don't know who is talking here) -- [[User:The.ridikulus.rat|Keshav P R]] 17:44, 27 October 2011 (EDT)
+
:::::::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)
  
Ok, sorry about that.  I'm a long time arch user but new to working in the wiki. -- [[User:Timm|Timm]] 11:24, 29 October 2011 (EDT)
+
::::::::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)
  
== Moving the partitioning information to the preface ==
+
:::::::: 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}}
  
In the article, I think it would be a good idea to move the information on partitions to the preface section, as I think it is a preliminary consideration that people should see as they begin, rather than running across it in the text.  I know people should read all of the instructions before beginning, but in real life that rarely happens.  However, since that's a significant change in the page, I didn't want to do that when I wasn't involved in the original page creation; not sure of the etiquette on that.  -- [[User:Timm|Timm]] 11:33, 29 October 2011 (EDT)
+
== grub standalone ==
  
I rearranged the text. Is it ok now? -- [[User:The.ridikulus.rat|Keshav P R]] 11:47, 29 October 2011 (EDT)
+
two things:
  
I don't think so.  If you are installing on a new install, the information about the partitions still isn't evident, as it is down in the sections about installing on a running system, or in the UEFI section. I'd suggest moving the information up to a new section either in the preface or right after it, called partitioning information or such.  Either something like "Note: In a GPT system you will need a partition, etc.  In a UEFI system you will need a partition, etc.", or just moving the existing text on the partition information, which seems to cover the information well.  That way people get their system hardware set up before they begin the process of installing.  No matter how much you simplify this, it is a complex process, and IMHO will be far less frustrating to people if they don't get halfway through the install and only then realize they don't have the necessary partitions.  This is, I think, even more important to those of us who are used to being able to set up our partitions in the install, because at least as far as I understand it, you can't do some of this through the arch install process. -- [[User:Timm|Timm]] 13:00, 29 October 2011 (EDT)
+
<s>1- I think the switch
 +
  --fonts="unicode"
 +
have to be removed since it is already the default behaviour
 +
(source: man grub-mkstandalone)
  
== GRUB_GFXMODE may not work with a depth parameter ==
+
2- before executing the command `grub-mkstandalone ...`, create the directory in your ''esp'' (e.g. /boot/EFI)
 +
otherwise it will fail
  
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 parameters.  The 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)
+
--[[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-mkstandalone? ==
+
== Grub Shell normal linux booting ==
  
And where is that coming from? It's not part of grub2-common.
+
A little improvement in GRUB Shell secction.
 +
When it is described the following example in [[GRUB#Using_the_rescue_console]]
  
Future update https://bugs.archlinux.org/task/23901 , but grub-mkstandalone is a very important tool -- [[User:The.ridikulus.rat|Keshav P R]] 15:13, 24 December 2011 (EST)
+
----
  
== Why did you remove double quotes in efibootmgr part ==
+
An example, booting Arch Linux:
  
@Fallacy: Why did you do https://wiki.archlinux.org/index.php?title=GRUB2&diff=175798&oldid=174885 . You even removed the part that explained why this is being done. I am reverting it because that command simply will not work without double backward slashes.
+
set root=(hd0,5)
 +
linux /boot/vmlinuz-linux root=/dev/sda5
 +
initrd /boot/initramfs-linux.img
 +
boot
  
: You mean FelipeC? Notice that I changed from to double quotes (") to single quotes ('), thus the backslash escaping is not needed. See:
+
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.}}
  
  % echo -E "\\foo\\bar"
+
  set root=(hd0,5)
  \foo\bar
+
  linux (hdX,Y)/vmlinuz-linux root=/dev/sda6
  % echo -E '\foo\bar'
+
  initrd (hdX,Y)/initramfs-linux.img
  \foo\bar
+
  boot
 +
----
  
: The two strings are exactly identical. -- [[User:Felipec|FelipeC]] 16:03, 24 December 2011 (EST)
+
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.
  
== Standalone UEFI ==
+
[[User:Cmolina|Cmolina]] ([[User talk:Cmolina|talk]]) 17:54, 13 August 2016 (UTC)
  
I went through the ordeal of trying to figure out how to make the section "Create GRUB2 Standalone UEFI Application" work, however, it's a complete mess.
+
: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)
  
First of all, grub-mkstandalone does not exist. Secondly, grub_efi_x86_64-install already has an option to specify which modules you want to install in the image (maybe this should be added as a note on the section that explains grub_efi_x86_64-install). And thirdly, the script is doing a bunch of unnecessary steps, like saving and restoring $PWD, while it's always changing directory to $PWD, so doing nothing at all, and also unsetting the environment variables, which happens when the script finishes anyway.
 
  
I rewrote the whole thing so it actually works, and it's actually simple. Too much stuff to write as the summary of the change. -- [[User:Felipec|FelipeC]] 16:32, 24 December 2011 (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)
  
grub-mkstandalone does exist (http://bzr.savannah.gnu.org/lh/grub/trunk/grub/annotate/head:/util/grub-mkstandalone.in). Like I mentioned it is coming in a update to grub2-common for which I have sent the updated PKGBUILD to Ronald Van Haren (pressh). Do you have any idea how grub2 actually works internally and how different tools are involved. The upstream does not recommend using --modules directly in grub-install or grub-mkimage for the sake of stability. Like I mentioned grub-mkstandalone embeds a memdisk inside the generated grub_standalone.efi file and the prefix is (memdisk)/boot/grub . For the record I wrote most of the UEFI related stuff in this page. Maybe unsetting the env variables were unnecessary (I rewrote another local script of mine which had export and unset commands) but the $PWD etc are required once you understand how grub-mkstandalone works. Go to https://bugs.archlinux.org/task/23901#comment84826 for the updated PKGBUILDs. With grub_standalone.efi, you don't need the modules to exist in the same directory since they are present in the file itself. It is not same as using grub-install with --modules. -- [[User:The.ridikulus.rat|Keshav P R]] 17:04, 24 December 2011 (EST)
+
== De-duplication of section header ==
  
:The fact that you wrote a lot of stuff doesn't mean you are automatically right. I looked at the script, and it's '''clearly''' not intended for what you want to use it. It's intended to create a '''rescue''' image, and if you look at the code, at the end of the day it's using grub-mkimage, the same as grub*-install. The only difference is that, as you say, it creates a memdisk image, but it uses that image to put '''all''' modules inside. So really, there's no advantage to the normal GRUB 2 setup, except that you don't need a filesystem. But given that EFI already requires a filesystem anyway, there's no point in using a tool that is intended for rescue images.
+
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.
  
:And BTW, I tried grub*-install specifying all the modules that I use and the dependencies, and then I removed all the contents in /boot/efi/efi/grub (except grub.efi and grub.cfg), and guess what... It works perfectly fine. So that solution is already better.
+
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.
  
:-- [[User:Felipec|FelipeC]] 12:56, 10 January 2012 (EST)
+
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.
  
Specifying all the modules embeds all the modules in the grub.efi and thus all the modules are already loaded when grub.efi is launched, which can cause stability issues, as some modules conflict with another and stuff like that. The reason the script is named grub-mkstandalone is because it is a creates a standalone image which is portable, the difference being all the modules are part of memdisk, not directly part of the image. If you want to know the finer details as to why mkstandalone is recommended I suggest you talk to grub2 lead developer phcoder in #grub irc channel in freenode.  
+
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 "script" you looked at puts all the modules in the memdisk image, but in that way the modules are not automatically loaded when grub.efi is launched, thus maintaining stability. THAT IS NOT THE CASE WITH grub*-install <all modulues> or grub-mkimage <all modules>. -- [[User:The.ridikulus.rat|Keshav P R]] 11:14, 15 January 2012 (EST)
+
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.
  
@FelipeC: Read [[GRUB2#Create_GRUB2_Standalone_UEFI_Application]] now. That is basically what my script used to do. -- [[User:The.ridikulus.rat|Keshav P R]] 11:32, 15 January 2012 (EST)
+
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)
  
:Did I say specify "all the modules" in grub*-install? No. I said all the modules I '''use'''. The modules being used are going to be loaded regardless of which method you use.
+
:What exactly was wrong with the duplicate header? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:14, 6 March 2017 (UTC)
  
:Having all the modules in a memdisk, or having all the modules in a directory in the EFI system partition makes practically no difference. Having the modules you '''use''' directly into the image should make a performance difference, as the image loaded is smaller, and there's no overhead in loading modules.
+
:: 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)
  
:-- [[User:Felipec|FelipeC]] 11:55, 18 January 2012 (EST)
+
:::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)
  
== Custom keyboard layout ==
+
::::Just in case and FWIW, for the very basic info about the matter, see https://en.wikipedia.org/wiki/Help:Link#Duplicate_section_names
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.
+
::::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)
  
Here's how I made things work:
+
:::::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)
  
ckbcomp it | grub-mklayout -o /boot/grub/it.gkb
+
::::::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)
  
Then, I manually edited {{ic|/boot/grub/grub.cfg}}, adding the following lines:
+
:::::::>"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.
 +
:::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:29, 8 March 2017 (UTC)
  
{{hc|/boot/grub/grub.cfg|
+
::::::::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.
<nowiki>
+
::::::::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:
terminal_input at_keyboard
+
*even more external links could be potentially affected;
keymap (hd0,2)/boot/grub/it.gkb
+
*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);
</nowiki>}}
+
*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)
  
This worked for me, but as of now, i think it's a very dirty method. Is there some support for keyboard layouts within {{ic|/etc/default/grub}}?
+
:::::::::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 [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)
  
Cheers. --[[User:Hilinus|Hilinus]] 12:50, 26 December 2011 (EST)
+
::::::::::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)
  
 +
== Dual Booting Windows.  ==
  
 +
In the section on dual booting windows there is a section giving instructions for people booting BIOS-MBR
  
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|
+
{{bc|1=
<nowiki>
+
if [ "${grub_platform}" == "pc" ]; then
GRUB_TERMINAL_INPUT=at_keyboard
+
menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {
</nowiki>}}
+
  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
 +
}
 +
}
 +
}}
  
in {{ic|/etc/default/grub}}. Then you get ckbcomp Perl script from Ubuntu or Debian and execute (for Slovene layout)
+
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.
  
$ ckbcomp si | grub-mklayout -o si.gkb
+
{{unsigned|18:46, 23 May 2017‎|Theholyduck}}
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
+
: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?
  
{{hc|/etc/grub.d/40_custom|
+
:[[User:Alchemek|Alchemek]] ([[User talk:Alchemek|talk]]) 17:07, 12 June 2017 (UTC)
<nowiki>
 
insmod keylayouts
 
keymap /boot/grub/si.gkb
 
</nowiki>}}
 
  
to {{ic|/etc/grub.d/40_custom}} and finally generate new grub.cfg with
+
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.
  
$ sudo grub-mkconfig -o /boot/grub/grub.cfg
+
[[User:Alchemek|Alchemek]] ([[User talk:Alchemek|talk]]) 17:07, 12 June 2017 (UTC)
  
Cheers. --[[User:drevo|drevo]] 17:47, 6 January 2012 (EST)
+
: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

Latest revision as of 19:04, 14 December 2017

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/
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 [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)

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