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

Grub2 Breakage

 * 1) grub_platforms_emu is broken. It would appear if a user is on a 32bit pc, they would only need the grub_platforms_efi-32 and grub_platforms_pc USE flags set, not all of these!
 * 2) What is needed, and what isn't needed, should be specified. ie. Users wanting to just get up and running aren't going to be worried about fonts... although I'm being a little conclusional on this one.
 * 3) The grub-2 ebuild doesn't create /boot/grub, and users shouldn't have to being going into the system folders and using chmod (ie. chmod +x /etc/grub/*). This stuff should be completed by the ebuild script.

Again, forgive me for being a little ahead as I have yet to successfully get grub2 installed. Should happen shortly though.

Yes. Users (using the handbook install) are likely starting to likely starting to need grub-2 for GPT partitioning of 2+ TiB hard drives as MBR is limited to <=2TiB!

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:

Number Start (sector)    End (sector)  Size       Code  Name 1           2048          206847   100.0 MiB   EF00  EFI system partition 2         206848          468991   128.0 MiB   0C01  Microsoft reserved part 3         468992      5846093823   2.7 TiB     0700  Basic data partition
 * 1) gdisk /dev/sdb

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:

insmod part_gpt insmod fat insmod search_fs_uuid insmod chain

set root=(hd1,gpt1) chainloader /efi/Microsoft/Boot/bootmgfw.efi

search --fs-uuid --no-floppy --set=root $YOUR_UUID # ie. blkid /dev/sdb1 chainloader ($root)/efi/Microsoft/Boot/bootmgfw.efi
 * Or, use the search method which helps when moving partitions around -- but UUID will change on resize?

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)

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

Booting from RAID Array
This section is all wrong. There is no (more) device.map in /boot/grub2 directory, nor 'grub2-mkdevicemap' command in grub2. The article confuses the MD raid UUID with the filesystem UUID.As far as I know (and I just finished installing 2 such systems) grub2 "just worksTM" with MD raid on linux. Can I go on and delete the section and restart it from scratch?


 * I have to disagree, loading a root partition from an mdadm device did not "Just Work". For one, the mentioned module ("insmod raid") seems to be missing;

$ find /boot/grub | grep raid /boot/grub/i386-pc/mdraid09_be.mod /boot/grub/i386-pc/mdraid09.mod /boot/grub/i386-pc/mdraid1x.mod /boot/grub/i386-pc/raid5rec.mod /boot/grub/i386-pc/raid6rec.mod


 * I could not boot without an initramfs even though both device-mapper (with correct raid levels) and lvm are compiled-in. --Tox2ik (talk) 22:28, 31 January 2014 (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)

More info needed around dual-booting Windows
In order for grub2-mkconfig to find Windows partitions through the 30_os-prober script, the sys-boot/os-prober package needs to be installed. grub2-mkconfig would not find my Windows partition until that was installed. I'm not sure if this is a missing dependency in the ebuild, or something that should be mentioned in this doc somewhere. DarkMoon (talk) 00:58, 20 October 2013 (UTC) =sys-boot/grub-2.00_p5107-r1 Seems this ebuild version of grub mentions within it's elog statements to manually install os-prober if this feature is desired. I'll make a note.---Roger (talk) 02:51, 20 October 2013 (UTC)


 * I've moved the chainloading information to GRUB2/Chainloading to make the GRUB2 article less verbose and easier to read. --SwifT (talk) 17:33, 1 January 2015 (UTC)