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)

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 and so is GPT and 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)

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?

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.