GRUB 2: A Guide for Users

[Qqmike]

Re: GRUB 2: A Guide for Users

btw, re the grub>ls (hdx,y), to test that without having to reboot to get the GRUB prompt:
at Konsole
sudo grub-emu
grub>
then do it

(emulation)

[Qqmike]

Re: GRUB 2: GPT: Testing

GPT: GUID Partition Table

=> Testing GRUB 2 on your GPT-partitioned flash drive

See Reply #1 to the GRUB 2 how-to:
http://kubuntuforums.net/forums/inde...5829#msg195829



GPT: GUID Partition Table
... for Kubuntu 9.10 and GRUB 2

=> Overcoming the 2 TB limit on disk size associated with the conventional MBR
=> Get rid of the Extended partition with its linked list of Logical partitions
(Have as many partitions as you want)


CONTENTS

The PC: BIOS, booting, the MBR, the bootloader
MBR: Limitations, problems, the "2 TB limit" issue
GPT -- GUID Partition Table -- and EFI
GPT layout, features, and the Protective MBR for your bootloader
Maximum disk size in GPT systems: 9.44 billion terabytes (9.44 zettabytes (ZB)
Requirements for using a GPT (kernel, bootloader, utilities, BIOS Boot Partition)
=> Testing GRUB 2 on your GPT-partitioned flash drive
Troubleshooting

[Qqmike]

Re: GRUB 2: drivemap; XP on non-1st HD

Drivemap command in GRUB 2

Booting XP on a non-first hard drive
Dual booting with XP (7? Vista?)
Booting FreeDOS on a non-first hard drive

Important: Please note
In-progress (since GRUB 2 is not yet finalized).
I got this by studying the programmers' posts in mail-archive.com/grub-devel.
This may not be the final word (although it looks like it is--"committed").

Also, my take on it and my experiments suggest a correction or an exception to one of the dev's postings.

In any case, YOU will be safe to follow what I say here--
I will present you with safe options that will not harm your GRUB 2 or dual-booting setup.


Contents
The Quick-and-Dirty Solution
Method 1
Method 2

Technical notes:
The drivemap command in GRUB 2 replaces the map command in GRUB Legacy
Use an up-to-date version of GRUB 2 (1.97xx) from 9.10 Karmic
The switch -s should also work
At the GRUB CLI (grub>), issue the boot command as your last command after the chainloader command

More Technical Notes:
The command drivemap
BIOS drives, DL register, chainloader, drivemap, the boot sequence
Comment on Method 1: the set root=(hd0) statement
Logic for Method 2: Why Windows works but FreeDOS will not


- - - - - - - - - -
The Quick-and-Dirty Solution

Method 1
To boot Windows XP installed to (hd1,1), use the following menuentry (in a script you write as a text file in the folder /etc/grub.d):

# Method 1 -- a safe, sure way to do it
# This method applies to Windows and to FreeDOS
# Windows XP on sdb1 (= (hd1,1)
menuentry “Windows XP on sdb1, by chainloader” {
drivemap (hd0) (hd1)
drivemap (hd1) (hd0)
set root=(hd0)
chainloader (hd1,1)+1
}

=> The drivemap command in GRUB 2 replaces the map command in GRUB Legacy.
=> That's all you need to know to make your grub.cfg work.
You can stop reading now, if you wish.

- - - - -
Method 2 applies to booting Windows on a non-first hard drive; it does not apply to FreeDOS:

# Method 2
# This method applies to Windows
# This method does NOT apply to FreeDOS
# Windows XP on sdb1 (= (hd1,1)
menuentry “Windows XP on sdb1, by chainloader” {
drivemap (hd1) (hd0)
set root=(hd1,1)
chainloader +1
}

IMPORTANT:
The line
drivemap (hd1) (hd0)
is my idea; in the grub-devel correspondence, it was the opposite:
drivemap (hd0) (hd1)

What this means for you
> You can stick with the safe method, Method 1.
> If you choose to use the more compact Method 2, doing it my way or their way, and if your PC hangs up, not able to boot into Windows, press the re-set button on your PC to re-boot, then boot into your Kubuntu 9.10 and fix your grub.cfg so it tries another way (e.g., switch from drivemap (hd1) (hd0) to drivemap (hd0) (hd1) or vice versa). Or, re-boot using re-set button, then experiment at the GRUB CLI by pressing the "c" key and manually trying another way to see what will work (at the grub>, don't forget to use the boot command as your last command: grub>boot).


Technical notes

-- The drivemap command in GRUB 2 replaces the map command in GRUB Legacy.

-- You should use an up-to-date version of GRUB 2 (1.97xx). You can get it from 9.10 Karmic.

-- The switch -s should also work:

# Method 1 -- a safe, sure way to do it
# This method applies to Windows and to FreeDOS
menuentry “Windows XP on sdb1, by chainloader” {
drivemap -s (hd0) (hd1)
set root=(hd0)
chainloader (hd1,1)+1
}

where the line
drivemap -s (hd0) (hd1)
means:
drivemap (hd0) (hd1)
drivemap (hd1) (hd0)

-- If doing this at the GRUB CLI (grub>), you must (always) issue the boot command as your last command, in this case after the chainloader command:
drivemap -s (hd0) (hd1)
set root=(hd0)
chainloader (hd1,1)+1
grub>boot

- - - - - - - - - - - - - - - - - - - -

More Technical Notes

--- The command drivemap (hdn) (hdm)
The command maps the BIOS drive hdm to the OS drive hdn.
(The BIOS drive will be the same as the GRUB drive.)

Very important: The drivemap command doesn't act until the boot command is issued. (In a grub.cfg boot menu, the boot command is implied at the end of a menuentry; at the GRUB CLI, the boot command is issued manually as grub>boot.)

This sometimes gets confusing (from a user's view). I have found the following point of view to be helpful (a tentative opinion, pending more guidance from the devs in an official Manual).

The command
drivemap (hdn) (hdm)
associates the BIOS drive hdm with the OS drive hdn.
That is, when the OS tried to use drive hdn, the device request to BIOS (Int13) will be interrupted by drivemap, drivemap will perform the switch (replacing hdn with hdm), drivemap will return control to the BIOS controller (Int13), and the OS will actually get the switched result hdm.

--- BIOS drives, DL register, chainloader, drivemap, the boot sequence

BIOS maintains a list of hard drives, starting at 0x80 for the first BIOS drive, then 0x81 for the second BIOS drive, etc.
When BIOS loads a boot sector (from a MBR or from a OS partition boot sector), the number of the boot disk (where the boot sector is located) is stored in the DL register (an so can be used by the boot loader or the OS being loaded by the bootloader).
The chainloader command
set root=(hdn,p)
chainloader +1
causes the boot sector (sector 1) of partition (hdn,p) to be loaded into memory, and then chainloader transfers control to the bootloader in that boot sector. The drive hdn is then set as the BIOS boot drive in the DL register. The boot sector bootloader then loads the OS into memory and transfers control to the OS.
Then when the boot command is issued (after the chainloader command is executed):
The drivemap command kicks in, it takes over the Int13 role, performing the drive mapping and switching, returns control to the BIOS Int13 handler, and then the OS sees the drives as they have been mapped/switched by drivemap.
Important: drivemap does not change the real (live) drive mapping as seen by GRUB 2; the changes performed by drivemap only affect the booted OS.

--- Comment on Method 1: the set root=(hd0) statement
This has been described as a faux GRUB root statement. You can use what has been said here to reason why it is needed in the menuentry of Method 1:
The chainloader command will load (hd1,1) into memory, transfer control to the Windows boot sector in (hd1,1), the Windows boot sector will access the DL register containing hd0 (because set root=(hd0) was issued prior to chainloader), (and remember, Windows likes to boot from the first BIOS boot drive hd0), then the boot statement is issued and so drivemap is effective and hd0 corresponds to BIOS drive hd1 (since hd0 and hd1 were switched in the BIOS drive list), and Windows will boot itself from hd1 (although it thinks it is booting from hd0). If we omit the statement set root=(hd0) in Method 1, then Windows bootloader will get hd1 in the DL register, the boot command causes drivemap to switch that to hd0, and Windows will not boot.

-- Logic for using the more compact Method 2: Why Windows works but FreeDOS will not
# Method 2
# Windows XP on sdb1 (= (hd1,1)
menuentry “Windows XP on sdb1, by chainloader” {
drivemap (hd1) (hd0)
set root=(hd1,1)
chainloader +1

The boot sector of (hd1,1) is loaded into memory by BIOS, control is transfered to the Windows bootloader in that boot sector, it may try to load/boot Windows from hd0, but because drivemap is executed after chainloader, hd0 will result in hd1 being switched in, and Windows loads and runs. Windows MAY then have a drive list that is switched around (because of drivemap and DL possibly containing hd1). But since Windows uses its own drivers for disk control and management, it will use those to fix everything correctly back to normal. This same reasoning applies to any OS that uses its own disk drivers. However, since FreeDOS does not use its own disk drivers, you must use Method 1 for chainloading FreeDOS when it is on a non-first hard drive; otherwise, if you use Method 2, FreeDOS may boot but then will have lost hard drive hd0.

[Qqmike]

Re: GRUB 2: A Guide for Users

New stuff


It appears that update-grub has been replaced by grub-mkconfig.
I have made the switch throughout the how-to (in the first post of this thread).


Notes about some of the new GRUB 2 commands
Included: chainloader, ls, grub-emu, grub-mkconfig (many tips!), root, rootnoverify (is gone), grub-setup
=> => See Reply #1 above.
I ran out of room in the original GUIDE (exceeded the 100,000 character limit) and so for now I put the new material in Reply #1.
There's some good stuff to look at, esp on grub-mkconfig, but also some other technical details.


General:
Still working on this, getting new info on GRUB 2. I intend to clean up the how-to, make it tighter, better, and do something about organizing it better.

[Qqmike]

Re: GRUB 2: A Guide for Users

This is important enough to make note of a correction here.
I went through the how-to changing update-grub to grub-mkconfig. However, when actually used as a command, update-grub does not require an argument, whereas grub-mkconfig does (to change grub.cfg). I think I caught all the corrections, but will be working on this some more, and for now note this post and specifically:


Note: update-grub
The command update-grub generates a new grub.cfg file and replaces the existing grub.cfg with the newly generated grub.cfg (by default).
But, as explained next, you must specify the output file when using grub-mkconfig.

Using grub-mkconfig correctly: -o option, or --output=FILE
grub-mkconfig --help
tells you.

Note that
sudo grub-mkconfig
prints its output to the screen (default = stdout).
To print to the grub.cfg, use
sudo grub-mkconfig -o /boot/grub/grub.cfg
or
sudo grub-mkconfig --output=/boot/grub/grub.cfg

[russlar]

Re: GRUB 2: A Guide for Users

I'm gonna need to sit down and read this... is there a single, current version, or are all the edits in the thread?

Have you though about submitting it to http://tldp.org"]the linux documentation project[/url]?

[Qqmike]

Re: GRUB 2: A Guide for Users

The edits are all incorporated into either the original post or Reply #1.

However, I'm still working on it. I made some changes/corrections, but this is still in-progress. I have tested everything on my PCs (and sometimes failed, like with the chrooting method for Live CD GRUB re-install--but my other "Method 1" works OK). I've spent hours studying the grub-devel posts to get new/more info. We have not yet seen any official Manual. But I think my how-to is in pretty good shape, EXCEPT it needs some editing, re-organizing, tightening, and more additional/new topics as they arise.

[lmilano]

Re: GRUB 2: A Guide for Users

Thanks a lot Qqmike!

WHat a shame the inconsistency in numbering: hd"0" for the first disk, and "1" for the first partition.

Let's hope we get a KDE4 GUI to edit it in "normal situations" (i.e., when we don't screw up our systems )

[Qqmike]

Re: GRUB 2: A Guide for Users

Yeah, the device naming.
Most every other field of application starts hard drives at zero, so that's kinda fixed. But those partitions should start at 1. Except, now, you're right, since we're used to GRUB Legacy, it's going to take some getting used to partly because of this now-obvious mismatching of hd's and partition numbering.

As for a GOOD GUI (one that works in all or most cases), I agree. It is needed. Editing scripts or making them in the first place, is a bit too much to ask most users to mess with.

[josefko]

Re: GRUB 2: A Guide for Users

When I read this manual I was scarred more and more that I would learn the stuff about grub and dual booting again when now I am satisfied to know how to do everything I need and even I can use GUI for editing grub. Than I read this

I think maybe when 9.10 gets released, I'll give a shot at setting up Grub 2 as my boot menu.

and now I think that I can live with the old grub longer, maybe for ever. Am I right?

[Qqmike]

Re: GRUB 2: A Guide for Users

Yeah, you can use GRUB Legacy. No problems there. You can use it exclusively, or you can chainload Legacy from GRUB 2 and vice versa. No real hurry to change into GRUB 2 if you don't want to. It is installed with 9.10, but it is also replaceable with GRUB Legacy.

[lmilano]

Re: GRUB 2: A Guide for Users

In fact, upgrades will keep grub legacy. Only fresh installs will use the new grub by default.

[josefko]

Re: GRUB 2: A Guide for Users

upgrades will keep grub legacy

That's a weight off my mind

[lmilano]

Re: GRUB 2: A Guide for Users

upgrades will keep grub legacy

That's a weight off my mind

Yep. I expect some issues with grub2 initially, like everything else. I am testing kubuntu-netbook Karmic on my Dell Mini, installed on a USB stick for now. I had a weird situation where grub2 would not boot, and a quick google took me to a workaround from a bug report in launchpad. Also, even after the workaround, there is a 10 second delay between the time I choose a kernel and the time it starts to load. Of course we are still at the beta stage, so you expect things to break a bit here and there. But I think I'll wait a few weeks after Karmic release to have a real install of kubuntu on the Mini (still running Ubuntu 8.04.2, Dell version).

[Qqmike]

Re: GRUB 2: A Guide for Users

For those tracking this, I completed rather extensive copyediting today, caught several typos/errors, included a few changes, tightened up text and Table of Contents. While it is evolving, and it is still a few weeks away from official 9.10 release, the how-to is now in pretty decent shape, including Reply #1 which contains some commands and GPT.