Difference between revisions of "Talk:GRUB"

From ArchWiki
Jump to: navigation, search
(Grub Article Clean Up Discussion)
m (Grub Article Suggested Changes, Additions, Edits, Etc: rm repetition)
(One intermediate revision by the same user not shown)
Line 264: Line 264:
  
 
* [[GRUB#Basic configuration]] and [[GRUB#Advanced configuration]] should be merged and simplified where approriate. Remaining "advanced" topics should be brought in a [[Help:Style#.22Tips_and_tricks.22_sections|Tips and tricks section]], or separate page (depending on amount).
 
* [[GRUB#Basic configuration]] and [[GRUB#Advanced configuration]] should be merged and simplified where approriate. Remaining "advanced" topics should be brought in a [[Help:Style#.22Tips_and_tricks.22_sections|Tips and tricks section]], or separate page (depending on amount).
 +
 
* [[GRUB#Preface]] should be removed. [[Grub legacy]] is deprecated over two years now. [https://www.archlinux.org/news/grub-legacy-no-longer-supported/].
 
* [[GRUB#Preface]] should be removed. [[Grub legacy]] is deprecated over two years now. [https://www.archlinux.org/news/grub-legacy-no-longer-supported/].
 
::Deleted legacy sections. [https://wiki.archlinux.org/index.php?title=GRUB&diff=347949&oldid=346626] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:29, 3 December 2014 (UTC)
 
::Deleted legacy sections. [https://wiki.archlinux.org/index.php?title=GRUB&diff=347949&oldid=346626] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:29, 3 December 2014 (UTC)
 +
 
* Any unsupported or harmful section should be deleted. Users that want those instructions will find them anyway.
 
* Any unsupported or harmful section should be deleted. Users that want those instructions will find them anyway.
 
::Removed ''Install to partionless disk'': [https://wiki.archlinux.org/index.php?title=GRUB&diff=347954&oldid=347953] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:34, 3 December 2014 (UTC)
 
::Removed ''Install to partionless disk'': [https://wiki.archlinux.org/index.php?title=GRUB&diff=347954&oldid=347953] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:34, 3 December 2014 (UTC)
 
::Removed ''Manually creating grub.cfg'': [https://wiki.archlinux.org/index.php?title=GRUB&diff=347960&oldid=347954] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:38, 3 December 2014 (UTC)
 
::Removed ''Manually creating grub.cfg'': [https://wiki.archlinux.org/index.php?title=GRUB&diff=347960&oldid=347954] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:38, 3 December 2014 (UTC)
 +
 +
:::About these removals I was wondering, just wondering, if they're going a bit too far: the Arch Way is to present all the options and let the users decide for themselves, without hiding anything; "unsupported" doesn't have a precise meaning in Arch, and I'm afraid that deleting those sections will result, sooner or later, in somebody else re-adding something similar just because they're experimenting on it and want to share their discoveries; in general, if we delete this kind of "non-standard" observations systematically, we risk turning the wiki into a mere introduction (when not even duplication) to external manuals, perhaps inhibiting a bit the spirit of curiosity and experimentation that could instead be seen as one of the most important engines that has built this wiki through all these years. After all, those sections were properly introduced by warnings (well, a Note and a Warning to be exact), so it was very clear that anyone following them would take all responsibilities for any bad consequences. Any opinions about this? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:17, 5 December 2014 (UTC)
 +
 
* Shorted the introduction at the top of the article by removing the definition of a bootloader, moved definition to the ''Preface'' section of the article
 
* Shorted the introduction at the top of the article by removing the definition of a bootloader, moved definition to the ''Preface'' section of the article
 
:--[[User:Stevenmw|Stevenmw]] ([[User talk:Stevenmw|talk]]) 15:45, 4 December 2014 (UTC)
 
:--[[User:Stevenmw|Stevenmw]] ([[User talk:Stevenmw|talk]]) 15:45, 4 December 2014 (UTC)
 +
 
* The MBR and EFI sections need a major overhaul / restructure. (will draft something out this weekend) --[[User:Stevenmw|Stevenmw]] ([[User talk:Stevenmw|talk]]) 15:52, 4 December 2014 (UTC)
 
* The MBR and EFI sections need a major overhaul / restructure. (will draft something out this weekend) --[[User:Stevenmw|Stevenmw]] ([[User talk:Stevenmw|talk]]) 15:52, 4 December 2014 (UTC)

Revision as of 15:20, 5 December 2014

EFI

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. Additionally, mounting (e.g.) /dev/sda1 to /boot/efi and just placing the grub there will possibly conflict with having a LVM+LUKS setup, where /boot will then be encrypted. At the moment I'm running a funtoo installation on a thinkpad x121e with /dev/sda1 (200MB, fat32, sectors 1 - 201) mounted to /boot and /dev/sda2 being a LUKS encrypted system. /boot contains the bzImage and /boot/efi/boot/bootx64.efi is the grub-image.

Note: there should possibly be a section/table here containing information what firmware expects what name. having /boot/efi/grub/grub.efi didn't work for me, and as noted in the thinkwiki for an x220, /boot/efi/boot/bootx64.efi works fine. --Rochus 13:59, 16 August 2011 (EDT)

@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.
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. -- Keshav P R 23:15, 28 August 2011 (IST)
I am moving to close this discussion. Nothing has been added to it since 2011. I am assuming these users have aquired the information they were after? In 3 days I will close this.
--Stevenmw (talk) 19:15, 3 December 2014 (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)

GRUB2 + Windows 7 TrueCrypt-encrypted partition

here is a link to my notes from my experience going thru this and Ubuntu Forum post which helped me a GREAT DEAL with this issue - below is a quick HOWTO ::

# ls -al /mnt/win7drive/Users/me/Documents/TrueCrypt\ Rescue\ Disk.iso
   -rwx------ 2 me users 1835008 Sep  5  2011 /mnt/win7/Users/me/Documents/TrueCrypt Rescue Disk.iso
# sudo cp /mnt/win7/Users/me/Documents/TrueCrypt\ Rescue\ Disk.iso /boot/
# mv /boot/TrueCrypt\ Rescue\ Disk.iso /boot/truecryptDesktop.iso
# pacman -S syslinux
# cp /usr/lib/syslinux/memdisk /boot/
# ls -alt /boot
   total 26388
   drwxr-xr-x  5 root root     4096 Jul 29 04:01 .
   -rw-r--r--  1 root root    26140 Jul 29 04:01 memdisk
   -rwx------  1 root root  1835008 Jul 29 03:59 truecryptDesktop.iso
            ....   ....
#mount | grep /boot
   /dev/sda3 on /boot type ext3 (rw,relatime,data=ordered)
# vi /etc/grub.d/40_custom

menuentry "Microsoft Windows 7 x64 Home Premium" {
   insmod part_msdos
   set root='(hd0,msdos3)'
   linux16 ($root)/memdisk iso raw
   initrd16 ($root)/truecryptDesktop.iso
}
# sudo grub-mkconfig -o /boot/grub/grub.cfg

--Fnord0 (talk) 17:59, 30 July 2012 (UTC)

encrypted /boot

Just so I remember when I come back to edit the article, grub-install (2.00) currently requires the GRUB_CRYPTODISK_ENABLE environment variable be set to "y". --Buhman (talk) 05:58, 10 October 2012 (UTC)

Since this note is from 2012 I move to close.
--Stevenmw (talk) 17:26, 4 December 2014 (UTC)

Boot Arch iso from LVM (LVM hook in Arch iso?)

I added the following in /etc/grub.d/40_custom:

menuentry "archlinux-2013.03.01-dual.iso" --class iso {
    insmod loopback
    insmod iso9660
    insmod part_gpt
    insmod lvm
    insmod ext2
    set root='lvm/vg0-arch'
    set isofile='/home/jordy/data/isos/archlinux-2013.03.01-dual.iso'
    loopback loop $isofile
    linux (loop)/arch/boot/x86_64/vmlinuz archisolabel=ARCH_201303 img_dev=$root img_loop=$isofile earlymodules=loop
    initrd (loop)/arch/boot/x86_64/archiso.img
}

My / is on LVM, the iso boots, but it can't mount the loop device (the iso) because the LVM hook hasn't been run before that. Is there a way to fix this and enable the LVM hook in the iso (without modifying it)

jordz (talk) 22:34, 24 March 2013 (UTC)

How to create EFI directory?

According to GRUB#Check_if_you_have_GPT_and_an_ESP, 'On [the EFI partition], there should be a folder called "EFI".' How is this created? I followed the instructions:

parted /dev/sda print
[...]
Number [...] File system Name       Flags
 1           fat32       EFI System boot

First, the instructions result in a "fat32" file system, and not a "vfat" one (as described in GRUB#Check_if_you_have_GPT_and_an_ESP). AFAICT "fat32" is not a subclass of "vfat", so that should probably be changed. Second, this partition, when mounted, does not contain anything at all, and I could find no instructions on how the "EFI" directory is supposed to be created. I expect some tool other than mkdir is supposed to do this (and possibly more)?

Other articles have mentioned a directory "/boot/efi". I guess that's just a case of FAT file systems being case insensitive, or does it actually matter?

os-prober does not require partition to be mounted

it says that os-probe only works for mounted drives, but this is incorrect. I've removed that statement, but I'm wondering why it was there. Are there conditions where this is true?

Thanks for the correction, I'm responsible for adding that information.[1] It was based mainly on this old "discussion": [2]. Even if there are cases when it is necessary to mount the partition, it's certainly not necessary... -- Lahwaacz (talk) 20:14, 5 December 2013 (UTC)
Moving to close this discussion. If there are any concerns regarding this issue or adding / removing related information from the wiki article please add them to the clean up discussion below. Thanks.
--Stevenmw (talk) 15:13, 4 December 2014 (UTC)

Is there something missing?

I tried this on a Virtual Machine and on two physical machines and i always end up with "EFI variables are not supported on this system"

This seems due to an bug that arch-chroot does not mount the efivars directory at all inside the chroot.

You have to run

# mount -t efivarfs efivarfs /sys/firmware/efi/efivars

or it will not work so this should be in the article.

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)

EFI Single Standard?

As some firmware isn't fussy about the name of the directory after $esp/EFI/ - nor apparently the name of the efi stub contained within it - then logically bootx64.efi in $esp/EFI/boot should work for them as well.

For example, the standard Grub UEFI installation command:

# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug

Could possibly be changed to:

grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=boot --recheck --debug

To install to $esp/EFI/boot rather than $esp/EFI/grub. All that would be required then is to rename the efi stub, which again - logically - should work for all firmware.

Does anyone have any experience of this, or be willing to test? Unfortunatly my UEFI hardware only works with bootx64.efi in $esp/EFI/boot.

Did a bit more research, and $esp/EFI/boot/bootx64.efi is essentially used to set the "default" bootloader for most UEFI firmware, hence having a higher chance of detection. The negative of this is that it would cause issues where using multiple bootloaders... Carlduff (talk) 22:59, 24 September 2014 (UTC)

Grub Article Clean Up Discussion

GRUB is a highly used package, and the Arch wiki standard has risen a great deal over the years. I feel like this article could really use several small changes and even a small amount of restructuring. It could definitely use use clarification and rephrasing in certain areas,

Here is the course of action I am proposing;

  • First we go through this discussion page and address everything. We give people a chance to provide feedback. Then within a reasonable amount of time we slowly close the discussions. (Several haven't had a response in over a year, and by closing them we can start fresh and handle things a piece at a time.)
  • Then we start one master discussion where we can all discuss changes / concerns regarding this article.
  • Then we gradually roll out these changes in an order that best fits the changes we decided needed to happen.

This afternoon I will be starting at the top of this page and researching each concern / issue. I will slowly work my way down the page over the rest of the week. I encourage other Arch users to contribute to this page as it exists right now so we can address any concerns regarding open discussions and get them closed out so we can start from scratch.

After reading over the discussion rules page I realized I had a couple of violations when adding this discussion topic. I've corrected them.

--Stevenmw (talk) 18:23, 3 December 2014 (UTC)

I was the one who added the template, so thank you very much for the initiative. Improving GRUB was planned as part of the Beginners' guide merge, and a big gripe is how information is scattered throughout the article, with none distinction between essential and dubious (corner-case to dirty hack) approaches. Feel free to add to this list. -- Alad (talk) 18:25, 3 December 2014 (UTC)
Grub Legacy has been deprecated a while. It really is a waste of space right now. One thing that should be done is removing traces of it from the GRUB page. Maybe even make a separate page for Legacy instructions if people really want them.
--Stevenmw (talk) 18:32, 3 December 2014 (UTC)
This section should be used to discuss reasons behind suggested changes to the GRUB article. I'm slowly going through the discussions on the page. My goal is to address any concerns in these discussions and get them closed. Once closed, we can address all concerns relating to the article as it exists now and the current state of GRUB. The reason being several of these discussions are very old.
--Stevenmw (talk) 15:17, 4 December 2014 (UTC)
I've read over the GRUB article a dozen times over the past couple of days. Just trying to weed out what is relevant information, and what should be removed all together or moved out of a section and into another one. I'm currently focusing on the preface. Could I please get feedback from other users on this? I'd likesome opinions on better organization, what is relevant, what could use better clarification, etc. Thanks.
--Stevenmw (talk) 14:55, 5 December 2014 (UTC)
Regarding GRUB Legacy, I think you're not aware of the GRUB Legacy article. -- Kynikos (talk) 14:52, 5 December 2014 (UTC)
I am aware it exists. If we need to move information to it we can. --Stevenmw (talk) 15:05, 5 December 2014 (UTC)

Grub Article Suggested Changes, Additions, Edits, Etc

Deleted legacy sections. [4] -- Alad (talk) 18:29, 3 December 2014 (UTC)
  • Any unsupported or harmful section should be deleted. Users that want those instructions will find them anyway.
Removed Install to partionless disk: [5] -- Alad (talk) 18:34, 3 December 2014 (UTC)
Removed Manually creating grub.cfg: [6] -- Alad (talk) 18:38, 3 December 2014 (UTC)
About these removals I was wondering, just wondering, if they're going a bit too far: the Arch Way is to present all the options and let the users decide for themselves, without hiding anything; "unsupported" doesn't have a precise meaning in Arch, and I'm afraid that deleting those sections will result, sooner or later, in somebody else re-adding something similar just because they're experimenting on it and want to share their discoveries; in general, if we delete this kind of "non-standard" observations systematically, we risk turning the wiki into a mere introduction (when not even duplication) to external manuals, perhaps inhibiting a bit the spirit of curiosity and experimentation that could instead be seen as one of the most important engines that has built this wiki through all these years. After all, those sections were properly introduced by warnings (well, a Note and a Warning to be exact), so it was very clear that anyone following them would take all responsibilities for any bad consequences. Any opinions about this? -- Kynikos (talk) 15:17, 5 December 2014 (UTC)
  • Shorted the introduction at the top of the article by removing the definition of a bootloader, moved definition to the Preface section of the article
--Stevenmw (talk) 15:45, 4 December 2014 (UTC)
  • The MBR and EFI sections need a major overhaul / restructure. (will draft something out this weekend) --Stevenmw (talk) 15:52, 4 December 2014 (UTC)