Talk:GRUB

Merging the GRUB2 articles
There are 3 articles detailing GRUB2 now: The GRUB2 article is huge and overly verbose in some places, GRUB2 Quick Start is IMHO more something that this article should lead with and GRUB2/Configuration variables should be probably weaved in under some #Config heading. Thoughts? /Ni1s 01:32, 20 March 2012 (UTC)
 * GRUB2
 * GRUB2 Config Variables
 * GRUB2 Quick Start


 * 1. I moved GRUB2 Config Variables to GRUB2/Configuration variables for now, but it should be merged with GRUB2, as there is a lot of overlap already.
 * 2. I think it is useful to keep GRUB2 Quick Start and the more extensive GRUB2 separate, as is. Make sure proper referral is present in the introduction of both articles.
 * 3. Some parts of GRUB2 can be moved to subpages, e.g. GRUB2 to "GRUB2/Troubleshooting"
 * — yngwin (wiki admin) (talk) 07:44, 17 July 2012 (UTC)


 * I noted collapsing syntax & pre-collapsed syntax on my user page. thus, we can have verbose explanations collapsed, and merging articles becomes feasible.  official documentation wikis should also profit from this.  concise information up front, verbose information collapsed.  666threesixes666 (talk) 05:02, 14 March 2014 (UTC)


 * I updated the article extensively. I separated content to subpages when the content is very specific (and not necessary for general readers), but included a small excerpt with then a reference to the subpage. For instance, for the configuration entries, the most common ones are shown while the reader is referred to the subpage for the more exhaustive list. I'm still not 100% satisfied with the installation part (I feel that the partitioning instructions are not that well written or could be made more clear) but it's easier to find the proper information now. --SwifT (talk) 18:49, 1 January 2015 (UTC)

Grub2 Unfocused and Imprecise Install Target Method Documentation
First, some quick background info on the trouble I started having with Grub2 aside from the partition numbering change.

If I'm correct, grub2 will only boot GPT (GUID) "Windows 7" partitions if grub2 is installed within the EFI|UEFI partition (ie. sda or hd0 within /efi).

The following is a typical "Windows 7" install to the hard drive using GPT (GUID) instead of MBR partition layout:

Or in English, /dev/sda1 is the 100MiB EFI/UEFI MS partition, /dev/sda2 Another MS reserved partition, /dev/sda3 is the actual Windows 7 install partition.

If a user tries to install grub2 to the usual /dev/sda device and tries doing:

When accidently specifying the "MS Reserved Partition" instead of the "Windows 7" partition Users will be presented with a wonderful mysterious "invalid signature" error. However, this seems to be a Grub/Grub2 specific lacking in user readable output... Grub2 should likely state the partition title along side the error.) Users can further try "chainloader --force", but may get a blank screen with no activity requiring a reboot.

Even trying to specify the proper Windows 7 GPT ntfs partition using a Grub2 install to /dev/sda, users will get a "BootMgr is Missing" error. (Hopefully, users trying to use Grub2 will now find that Grub2 needs to likely be installed to the EFI partition as a work around here? (...although, I see this as slightly rediculous and think Windows 7 GPT NTFS should be able to be started from any method of boot loading?)

AND NOW, ONWARD TO WHAT THIS TITLE IS REALLY ABOUT!

One definite vagueness of Grub2's documentation and Grub2's WIKI pages are it's specified install target. Users can either install Grub2 to /dev/sda or to /efi! From the current documentation, it wasn't immediately clear to me. From what I understand, users installing Grub2 to /efi which also requires manually adding a Grub2 boot line to the BIOS BOOT screen, avoid the Windows 7 "invalid signature" above. What joy. What even makes things more complicated, my ASUS P8Z77-V BIOS will not load the shellx64.efi from a GPT|EFI /dev/sda1 partition directly, and will only boot it using a USB flash drive.

As far as specifying partitions by UUID, I prefer to keep things simple encase I change or move partitions around. Not sure if the blkid UUID is preserved on partition resize.

In the end, prefer to keep things simple encase something breaks and not waste time making so many changes within config files when moving from different software versions. This way, if something breaks, I have more of a definite idea where something is broke. --Roger 13:30, 25 October 2012 (UTC)


 * As I look back at the sections, I think I can immediately see where this WIKI lacks the structure which inhibits the above problem.


 * 1 Installation
 * 2 Configuration
 * 3 BIOS/MBR
 * 4 UEFI/GPT
 * 5 BIOS/GPT
 * 6 Chainloading
 * 7 Troubleshooting


 * Should be something like:


 * 1 Installation
 * 2 Configuration
 * 3 Target Type (Choose either the normal BIOS/MBR or newer EFI/UEFI/GPT)
 * 3.1 BIOS/MBR
 * 3.2 UEFI/GPT
 * 3.3 BIOS/GPT
 * 4 Chainloading
 * 5 Troubleshooting


 * Each subsection of "Target Type" should include brief about or insight on why it would be used or deployed, or better yet, within the Target Type so users can immediate choose their install method rather :then reading it within each subsection (ie. 3.1, 3.2, ...). Another curiosity, there are three types of install methods mentioned here -- BIOS/MBR, UEFI/GPT and BIOS/GPT.  Are one of these hybrid :installs?  Without reading the whole WIKI page word for word, from start to finish, it's really confusing.  However, I think breaking these sections into appropriate sections would immediately provide more :clarity and will avoid readers from having to read the whole WIKI before making sense of it.  Remember, the reason we use sections or chapters in books, are so readers can clearly go to the sections :applicable for their desired layout.  The sections and subsections are like flow charts.  Oh, and I should mention, great write up... just appears slightly unorganized like my articles. ;-)  And I should :make mention, could probably recommend removing my large discussion blob here after things are fixed as it is quite large! --Roger 13:45, 25 October 2012 (UTC)


 * For those following this, either from Google searches from errors stated within this article or others, I'm considering just reverting back to MBR partition type for Windows instead of using the GPT layout as I think Windows 7 will simply allow simple booting via chainloading. However, the boot loader of my current Windows 7 install might become disfunctional because Windows 7 install might only have been installed/configured to use a GPT/GUID layout and not the old MBR layout.  So, moving/copying Windows 7 partition to another hard drive, low-level reformating the hard drive from GPT to MBR layout, then moving the Windows 7 partition back again, and configuring the /dev/sda1 installed Grub2 to simple chainload the old style MBR method might further fail.  I have no idea how a GPT installed Winodows 7 partition is configured to bootload, aside from know there's an additional two partition (efi/msftrsv).  Granted wasting 1TiB of a 3TiB hard drive as MBR is limited to <2TiB.  Another work around, I can manually load the Windows 7 GPT/EFI install from the ASUS BIOS using the BOOT screen as Windows 7 puts an entry there.  So, my options appear to be 1) Install Grub2 to EFI (for which seems more of a mystery and being forced to use the DOS style shell), 2) Revert to MBR (and wasting 1TiB of drive space), 3) Deal with my currently installed situation, and just use the BIOS BOOT entry for booting Windows 7 ... unless it is possible to boot Windows 7 GPT/EFI from /dev/sda installed Grub2, but sounds as if EFI was meant to only be booted from BIOS.... which then leads to the secure boot theology for which I don't need unless we're hit by a meteor and the squirrels & chipmunks rise and get smarter. ---Roger 14:26, 25 October 2012 (UTC)


 * The GRUB2 article structure has been updated to make it more clear. Issues are also moved to the GRUB2/Troubleshooting subpage, while GRUB2/Chainloading can go into more detail of dual-booting situations. --SwifT (talk) 19:00, 1 January 2015 (UTC)

EFI/UEFI is a Nightmare, including GRUB2!

 * 1) BIOS EFI/UEFI is simply a nightmare as already described above.  EFI/UEFI is very confusing and far from being simplified.
 * 2) I'm now finding-out GPT partition layout can cause further problems with partition ordering.  GPT (or maybe it's GParted's fault) will either insert new partitions starting at /dev/sda2 (ignoring existing, sda2, sda3, ... and push the numbering +1 on all existing partitions after /dev/sda2) or maybe simply editing labels of partitions will provoke this within GParted.  Extremely odd as I've never seen this happen with MBR/MSDOS layouts except for my present GPT partition layout.

And, once this happens, it will obviously screw-over your grub.cfg file. For my Windows 7 and Windows XP 32bit, I'm determined to stick with MBR or msdos partition layout to avoid further boot problems when using Grub as the loader for Windows. Just divide the partitions eveningly, or use extended partition containers to avoid the MBR or msdos partition layout 2TB limit. As far as Linux, I used a Fedora-17 LiveCD install automatically create the EFI/UEFI partition layout on the hard drive. Knowing what I know now, I would have likely remained using the MBR or msdos partition layout for all of my 3TB drives.
 * 1) Because of #2 problem just mentioned, I'm really starting to hate the new Grub2 grub.cfg layout, or the many automated partition numbered notations.  Because of problem #2 just previously mentioned, you'll spend a lot of extra time changing all your partition numbered notations within grub.cfg after a partition reorder.  And, you'll be changing several series of notations besides the hd#, which includes ahci/resume=, oh and don't forget the always forgotten swap device within /etc/fstab.  With Grub1, or Grub2 w/o automated generated grub.cfg we only had to worry about a few lines, or enough to hand-off.  The extra commands are suppose to auto-find the partition, and it really doesn't save any time, except cause more problems here.  Also, suppose to use the /etc/grub.d scripts to auto create/modify the /boot/grub2/grub.cfg file, but if you have custom items within grub.cfg, it's troublesome to use the /etc/grub.d files.  Keep it simple, keep it stupid is what I say.

EFI/UEFI and GPT definitely need more work, and looked somewhat hacked-together in my opinion as of 2013.01.11. And, it doesn't seem to make the BIOS any better. I keep thinking, LinuxBIOS/Coreboot was a far superior implementation. -Roger (talk) 13:24, 11 January 2013 (UTC)


 * Sir, your experiences with automated configuration scripts, GUI tools and os-installers (on other GNU/Linux distribution, I might add) are irrelevant to a discussion of the main article (someone with "more authority", please remove Mr Roger's comments). --Tox2ik (talk) 22:15, 31 January 2014 (UTC)


 * Should note, those notes of mine were made more than a year ago, and the EFI/UEFI coding since then has been most obviously changed since. Nor have I revisited UEFI for the entire year, simply remaining with MSDOS partition layout for Windows and migrated to GPT partition layout for Linux Distributions omitting the confusing EFI/UEFI partitions and UEFI code.  (ie. I tend to use a keep it simple principle here, in case things break.)  I find your explanation concerning irrelevancy only based on mer distribution usage for installation of UEFI is unsubstantiated, as GRUB2 did not automatically install by default UEFI under Gentoo at that time, and only Fedora installed EFI/UEFI by default.  Additionally, "How would Gentoo's package of GRUB2 be different from Fedora's, aside from the usual installer and maybe some additional patches or scripting (ie. Gentoo's Eselect packages) be much different?"  (You probably forgot to explain this part of your rational.)  However, with time these comments may become irrelevant, as people within open source continually fix EFI/UEFI for end users to more easily comprehend and use.  (I was going to state that the complexity of EFI/UEFI might be explained by the amount of documentation required to explain using EFI/UEFI, but then I just revisited the GRUB2 page and found the documentation extensively apparently shorter now.)  One change since I wrote this, I tended to sway with was using UUID within /etc/fstab instead of partition numbers.  Now, if you're stating the above should be removed because additionally UEFI is much easier to deal with since then, then I (as well as others) might agree!  (Although I enjoy the respectful usage of Sir and the respect for authority, respect alone by no means should be construed as providing grounds for adequate justification.)


 * It should additionally be noted at the time I wrote that bit, I think users had to perform much much more research a year ago, just to make any use of UEFI when possibly compared to now. (As I already speculated, evident of easier managing of UEFI by the shorter and more concise GRUB2 Wiki UEFI section now?)  I am curious as to whether UEFI is any easier to work with, but only do so on clean installs, which is extremely rare here.  Additionally, Grub2 also uses /etc/default/grub and other /etc/grub.d files, for which was or is still another issue.  I am just starting to use "/etc/default/grub" when using Fedora, but still prefer using "/boot/grub2/grub.cfg" for my main Gentoo O/S due to my many entries and customizations. ---Roger (talk) 02:39, 1 February 2014 (UTC)


 * BTW Tox2ik, nice English grammar corrections under the GRUB2 Wiki "Hybrid GPT/MBR" section. ---Roger (talk) 02:50, 1 February 2014 (UTC)


 * I moved hybrid away from the article, as it is too specific for setups that many users don't need, and gives the impression (or is even fact - I don't know) that it is highly experimental and not really supported. UEFI information is now isolated in the article. I wont close this discussion yet, but if there are issues please make them clear and isolated - don't group lots of things into one discussion thread as that will make it very hard to follow through. --SwifT (talk) 19:06, 1 January 2015 (UTC)


 * There is a proposal in the Hanbook discussion page. So why not fix it in the handbook, and then refer to it and remove all that confusing stuff here? One source of information should be sufficient but it must not confuse the reader. --Charles17 (talk) 07:10, 7 July 2017 (UTC)

Use File Templates instead of Code Templates for File Data
codes instead of file /path/to/config.cfg should be migrated to file so its more clear exactly what file is being manipulated. the previous lines of "merge this into grub.cfg" should be removed.


 * In other words, reformating Wiki text utilizing the Code templates and 'pre' snippets into using the File template. (ie. File|/etc/my.conf|some text) I whole heartedly agree as it makes the text easier to comprehend with the readily readable file name at the top of the block of text.  Those inserting only 'pre' statements, usually I, are likely those with only enough time to document and not enough time to struggle with template syntax.  I see a lot of Code templates used here in place of the File template.  Agreed.  I'll put this on my TODO list and will be back sometime next year to fix. ;-)  ... I've edited this topic to something a little more understandable. ---Roger (talk) 04:30, 19 October 2013 (UTC)


 * I've transformed most of them to Template:FileBox. --SwifT (talk) 19:10, 1 January 2015 (UTC)

grub-mkconfig after configuration
executing grub2-mkconfig should be done after the system is configured. It would make more sense if the section that executes the command is below all of the configuration descriptions for the command.--Moaxcp (talk) 23:10, 29 May 2015 (UTC)
 * is now just, but the previous comment is still relevant, I think. - dcljr (talk) 07:54, 4 March 2017 (UTC)


 * Then add it yourself. There's nothing to discuss here. It's a publicly modifiable wiki! --Maffblaster (talk) 00:35, 21 April 2017 (UTC)

openrc efivars
As per gentoo-dev mailing list,

The documentation should be updated to say that with OpenRC 0.28 that you'll have to remount efivars as RW before you can install the bootloader (e.g., grub-install)

The command I use locally to remount rw (since I have configured efivars to be mounted read-only in fstab) is

mount -o remount,rw /sys/firmware/efi/efivars

from mattst88@gentoo.org

--Rage (talk) 01:16, 13 July 2017 (UTC)


 * Sounds good to me. Go for it! --Maffblaster (talk) 16:43, 9 October 2017 (UTC)

 The keyword "GRUB" should now redirect to GRUB2; GRUB 1 article should be moved to 'GRUB Legacy'.
This change has been pending ever since GRUB 2 took the primary slot change. When people 'search' for GRUB, they are generally looking for GRUB 2, not GRUB Legacy. GRUB Legacy is only used in certain (special) cases; the Handbook no longer references GRUB Legacy. I think for these reasons some work should be done to make the GRUB article redirect to GRUB2; GRUB 1 article should be moved to 'GRUB Legacy'. Thoughts and or ideas? Anyone willing to help me fix the broken links after the move? GRUB front page explains the terminology switch. Kind regards, --Maffblaster (talk) 16:48, 9 October 2017 (UTC)


 * GRUB Legacy already exists. But you could copy the content of GRUB to GRUB Legacy, then replace GRUB with a redirect to GRUB2. What else do you think would be left to be done after this?--Charles17 (talk) 05:39, 10 October 2017 (UTC)

Sounds good. After a long hiatus I have starting to make the required changes to move things from GRUB2 -> GRUB. This will require some planning, but I think it will work out. --Maffblaster (talk) 22:44, 12 August 2020 (UTC)

Update of the grub program (not config)
What is the correct way to update GRUB2 after an emerge --update? Is it simply grub-install /dev/sda, or is there a better and more correct way? For example, a user may need help locating where grub was installed during the initial Gentoo installation. This should be mentioned in the Wiki. Gatak (talk) 13:17, 31 March 2019 (UTC)


 * If a version update appears and the user wishes to update the booting grub, then yes, should be rerun as it was done initially.  There is no single command format as not all use the same invocation.  For example, the default UEFI command from the handbook is .  If someone can figure out a good way to explain this, feel free to add it. --Grknight (talk) 13:47, 2 April 2019 (UTC)

MBR: dual-boot with Windows?
What does the note in section BIOS with MBR mean?

I don't get it. When Windows was installed in "legacy BIOS" mode, i.e. EFI-CSM (compatibility support module, the BIOS emulation module from EFI/UEFI), then Windows will only boot from MBR and with either a real BIOS or an EFI-CSM. But so will Linux. So what does making sure that my computer does not have a UEFI firmware change in this situation?

Also, with e.g. rEFInd it is possible to select between booting an EFI operating system (using the appropriate .EFI bootloader) and a legacy CSM/BIOS bootsector. At least on an Intel-Mac (x86-Mac) this is done every day when running macOS and Windows using either BootCamp or rEFInd. So one could e.g. install Windows in CSM mode (as done by BootCamp on a Mac) and install macOS and Linux in EFI mode. The only complication is that BIOS/CSM requires an MBR partition table, while EFI requires a GUID partition table (GPT) – so either the system uses two separate drives, or manual hybrid partitioning, where the Windows partition is in both the GUID and the MBR partition.

But this is now getting quite complicated and I degress... The point is, I still don't get the note. What does it mean? Luttztfz (talk) 19:38, 19 September 2020 (UTC)

Installing the boot loader

 * For Installing the boot loader I propose the following change:

Installing GRUB as the system's boot loader depends on how the system is able to boot. Each firmware has different abilities and requires a specific partition layout with a specific type of on-disk boot loader.


 * BIOS → requires a bootsector; the de facto standard is the Master Boot Record (MBR)
 * UEFI (previously EFI) → uses an EFI System Partition (ESP) and loads an executable bootloader from its FAT filesystem
 * the EFI/UEFI compatibilty support module (CSM) emulates a BIOS on a EFI/UEFI system
 * Open Firmware → loads a bootscript or an executable bootloader; partition layout and filesystem support varies with implementation and platform


 * I want to discuss it first, but it should be made clearer that BIOS doesn't really favour any partition table at all, only that MBR has become the de facto standard for it. But with the possibility to use BIOS + GPT it should become quite clear that the MBR is not a requirement of the BIOS at all.
 * Secondly, UEFI-CSM is equal to a BIOS in every sense, but it should be made clear that this option must stick, i.e. once a bootloader is installed that way, switching to native EFI does require installing a new bootloader and possibly repartitioning the HDD.
 * And thirdly, there are more systems out there than x86. (And, yes, Open Firmware might just be one of the possible other firmwares...)


 * The question is if it would make sense to have sections for each partition table, or for each firmware. If the later, the problem is that there is more than one partition table possible... So I would prefer to have sections for each partition table/bootloader option and point out on which firmware, in which mode, this will work.


 * And, quite important too: what is a "partition layout"? Shouldn't this be either a "partitioning scheme" or a "partition table"? (In my proposed change I use "partition layout" only because it is the currently used term.)
 * Suggestions?
 * Luttztfz (talk) 20:35, 19 September 2020 (UTC)