Installing GRUB on logical partition
 

Hi all,

I have a desktop - Dell Inspiron I530 - with Vista 64. I don't want to touch the Vista disk at all.

I have a 1.5TB external USB hard drive, that is almost full, with about 5 partitions (3 primary + 1 extended + 2 logical) on it that I also don't want to touch. I have about 25GB of unallocated space at the end of the drive that I would like to use for Linux.

So I would like to install GRUB to something like sdb7, and make it bootable. Linux would be on sdb8, sdb9, sdb10.

I would select if I want to boot GRUB or Vista from the BIOS boot menu.

So the questions I have:
- Is it possible to install GRUB to a logical partition? Would the BIOS be able to see it?
- Would my GRUB/Linux be affected by the 137GB limit?
- How would Windows react to this drive being bootable, when I want to use it for storage from inside Windows? Would Windows complain about it?

I hope I don't have to move any partitions around, to make room at the beginning of the disk. This could take a while.

Thanks.

Answers I have:
- yes. Only brain-dead boot-loaders care. They all come from Redmont.
- nope. But your BIOS might. Anything produced in the last 5, maybe 10, years should be o.k.
- doesn't know, doesn't care.

There are some BIOS authors that are as lame as M$oft, and insist you have a boot flag set on the drive you boot. So on your second drive you may need to set a boot/active flag on a primary partition. Pick one - any one. The BIOS is happy, and grub ignores it.
We all have to accommodate stupidity.

Yes, but I'm pretty sure that is not what you want. See (***) below.

Yes, it is possible to install the part of grub that normally goes in the MBR into a partition boot sector instead and that is equally OK whether that boot sector is primary or logical.

When an installer seems to ask where to install "grub" it really means where to install that tiny part of grub that often goes in an MBR. Most of grub is in files typically in the /boot directory or partition.

No. The BIOS only sees boot code in MBRs. It never sees boot code in partition boot sectors.

If that first part of grub were in a partition boot sector, and something chain loaded to it, I'm not sure what limits would affect it.

Windows doesn't care.

(***)
If no partitions are bootable on that USB drive now then nothing is using the part of that drive's MBR that grub would need. So you should be able to install grub to that MBR without disturbing any data partitions on that drive.

If your BIOS can boot to the USB drive at all, I would expect (the beginning of) grub installed in that mbr would work correctly despite the rest of grub being on a distant logical partition.

There may be some complication over the fact that the BIOS when booting a different drive tells the boot code and OS to rearrange the identities of the drives. So far as I understand, grub obeys the BIOS request to rearrange the identities and Linux does not. So when you are running Linux (I assume from a CD) to install grub in the MBR of the USB drive, that drive will have a different identity than it has later when you boot from that copy of grub. I think that requires a manual tweak to grub's config file in the /boot directory (after you install grub and before you use it).

Alternately, I have seen instructions for Windows XP and I'm sure some exist for newer versions of Windows to configure the Windows loader to offer you a menu choice to chainload a different loader (such as the first part of grub). So you could select booting Linux from a Windows boot time menu rather than the BIOS menu, so the drive identities would never change. To do that in XP, the first part of grub is installed anywhere you like then manually copied to a 512 byte file which you put in the root directory of C: (then a text file in the root of C: is edited to set up a menu choice for chainload through that 512 byte file).

Unfortunately we have a terminology issue here.
Grub (the product/package) can be installed to any usable partition - primary or logical.
The stage0 code can then be installed to the MBR (of the second drive in this case).

This dual use of "installed" is unfortunate - people who use pre-packaged distros are usually unaware from the nuance in daily usage.

I'm glad I resisted the urge to quote and contradict your earlier post. I'm so used to installers that ask where to put stage0 in a way that looks like they mean all of grub, that I assumed that confusion was embedded in the whole topic.

stage0 can be put other than in an MBR, in which case it can't be used directly by the BIOS but could be chain loaded in a variety of ways.

But I expect the OP will be included in those seeing the grub installation through the lens of a distro installer, rather than typing the detailed commands. So most of grub going into a /boot directory is automatic hidden behavior, while one tiny part of grub going to user controllable location is visible.

I think you are assuming and I am suggesting that location should be the MBR (beginning) of the whole USB drive and doing that does not disturb the first partition of that drive (the first partition starts a little after the actual beginning of the drive).

So we seem to agree on the answer despite differing on how to describe the answer.

Indeed.
I was attempting to make it clear to the OP that we were all heading down the same path. Sorta ... :p

That is good to know.
Does the 137GB limit apply to USB disks same as internal disks? Or is it a limitation of a disk SATA/PATA controller? Which, the USB disk enclosure would have its own (probably newer) controller. Or is it something more software related, then hardware related? After all, after the OS is launched it is using the same controller as the BIOS did, but is able to see the entire disk, which the BIOS couldn't.
But then again, this whole question may be irrelevant, as the old BIOS with the 137GB limit are probably not capable to boot from USB anyway. What do you think?

Do you mean the menu entries in the 'menu.lst' file?
So, Linux Live CD might create the entries as sdb*, and later GRUB will identify them as sda*, as instructed by BIOS? Do I understand this correctly?

I have actually tried, on another system, copying the boot sector of a GRUB partition (GRUB was installed to a partition as per installer directions) to a file, and then making that file an item in Windows XP boot menu. That worked fine. I think I can do the same for Vista.
But will it work, given the fact that the GRUB files are on another physical disk? As I understand it, the boot sector (Stage 0), that we copied to a file, contains the absolute disk address of the GRUB files location. Windows would have to be smart enough to redirect it to another disk.
Anyway, I will only attempt it if I have problems with BIOS booting a USB disk. My preference is to use the BIOS boot menu on this one.

Close. In menu.lst drives are identified by number, not by letter. The grub installer on the liveCD might see the drive as sdb and drive number 1. When booting that drive, the BIOS will tell grub to see it as drive 0 (which grub will do) and tell Linux to see it as sda (which Linux ignores and sees it as sdb anyway). So during install sdb is drive 1 but on boot sdb is drive 0.

I'm not sure how that works. When one version of grub chain loads another version of grub (or Windows), part of the chain load mechanism uses the same mechanism the BIOS uses to tell the chain load target to use different drive numbering. So you can chain load to a different drive by telling the boot code chain loaded to that the other drive is drive 0. Windows chain load may have that same ability.

I think the chain load mechanism also can tell the target what drive to use (which would be subtly different from telling it to change which drive is drive 0 before using "drive 0").

Just trying to pinpoint what exactly I will need to change.
The Live CD might create an entry in 'Menu.lst' like:
root (hd1,8)
and I will need to change it manually to
root (hd0,8)
so GRUB can launch the right disk.
Is it about right?

Do all BIOS do this?
If not, it could mean that the GRUB setup might not work on all systems.