From ArchWiki
Revision as of 18:23, 24 December 2011 by Felipec (talk | contribs) (grub-mkstandalone?: new section)
Jump to navigation Jump to search

Q: So what are the advantages of using grub2 instead of grub-gfx ? --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. --Det 10:22, 24 February 2010 (EST)

Grub2 1.98

The new stuff brought by 1.98 should probably be explained. --Det 10:57, 16 March 2010 (EDT)

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. --Det 13:44, 28 March 2010 (EDT)

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 :). --Det 15:58, 8 April 2010 (EDT)

Upgrading from grub 0.97 to grub2 - MBR

To fix the problem described on section GRUB2#Other you can remove grub 0.97 from MBR by following command:

dd if=/dev/zero of=/dev/sdX bs=446 count=1

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:

dd if=/dev/sdX of=your/backup.img bs=446 count=1

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

@Skodabenz & NTia89

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. -- Kynikos 14:13, 15 March 2011 (EDT)

@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? -- Keshav P R 17:37, 16 March 2011 (EDT)

Perfectly explained, thanks. The "related note" is this one I've just removed (see diff); it was added by NTia89 when he edited the article. -- Kynikos 19:53, 16 March 2011 (EDT)


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)

grub-mkconfig and UEFI

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? -- Keshav P R 09:57, 19 October 2011 (EDT)

Confusing information on a running system; combining MBR and GPT information; an initial MBR portion that seems contradicted later

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.

Should be clear now -- Keshav P R 14:53, 24 October 2011 (EDT)

Ok, another one. I know I'm literal, and sometimes that's good, other times bad.

The page talks about installing to the 440-byte area. Then later it talks about replacing legacy in that area. 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.

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.

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.

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

(also please sign your text - I don't know who is talking here) -- Keshav P R 17:44, 27 October 2011 (EDT)

Ok, sorry about that. I'm a long time arch user but new to working in the wiki. -- Timm 11:24, 29 October 2011 (EDT)

Moving the partitioning information to the preface

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. -- Timm 11:33, 29 October 2011 (EDT)

I rearranged the text. Is it ok now? -- Keshav P R 11:47, 29 October 2011 (EDT)

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. -- Timm 13:00, 29 October 2011 (EDT)

GRUB_GFXMODE may not work with a depth parameter

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. -- Timm 13:08, 29 October 2011 (EDT)

Remove Manual Compilation part ?

GRUB2 is now in official repo, so is it necessary to include a manual Compilation instruction? Manual compilation in arch is not a recommend way anyway. Fengchao 22:44, 6 December 2011 (EST)

Removed -- Keshav P R 14:20, 12 December 2011 (EST)


And where is that coming from? It's not part of grub2-common.