Trying to setup 3TB ext. USB drive as bootable with GPT

[oldfred]

I find it interesting that openSUSE uses the disk by ID style. I think that then avoids the issues I have with chain loading.

I have one small 160GB drive I converted to gpt to learn about it, and I have 3 drives and several flash drives that I can boot from.

I found with Ubuntu's grub2 that whatever drive I boot from it is hd0, and if booting into the gpt drive I need the (hd1,gpt2) style for gpt partitions or from the gpt into the MBR (hd3,msdos12). So when I chainload to another hard drive's MBR my standard 40_custom is really only correct when booted from one drive as the drive numbers change if I use the smae 40_custom on installs in another drive. Or when I boot sdc it is hd0, sda is hd1 etc.

The newest grub 1.99 now uses /dev/sda as an alternate to hd0, but we have seen users where the BIOS does not always bring drives up in the same order.

[brc816]

Hi, Fred !

Well, what was interesting was that openSUSE's /dev/disk/by-id changed (is changing?) between 11.4 and 12.1, in that 11.4 called everything /dev/disk/by-id/ata-mumble, even my USB drives. In 12.1Mx, the USB drive is /dev/disk/by-id/USB-mumble. So, that was confusing enough...

But, since I last posted a few hours ago, I tried my Natty 16GB thumbdrive, and managed to boot the 3TB's distros, but only through the /boot copies I plopped on my hard drive. And, in trying to chase that down a bit further, I'm discovering that the "UUIDs" aren't as Universal as I'd hoped. And since GRUB2 looks at all of the menu.lst's and grub.cfg's it can, it's starting to get a bit confusing.

FYI, my current Natty 16GB thumbdrive is partitioned using MBR/MSDOS partitioning, and basically a 700MB swap partition and the rest as the root partition, and the latter is only about 25% used. I'm going to set up another 16GB Natty thumbdrive, but will use Rod's suggestion and add a bunch of small (~100MB) partitions to use as /boot for the various distros on the 3TB.
(I plan to use MBR and MSDOS partitions on the 'new' thumbdrive).

That still won't clarify why I can't seem to scribble a cogent boot block on the 3TB drive - it may yet be a 4096 byte sector issue as Fedora 16 pre-Beta's 'grub2-mkconfig' complained - but at least I will be able to dd the first 512 bytes or whatever to a regular file and compare/examine it.

[oldfred]

I have not had to deal with very large drives and 4096 sectors. But Rod sold me on gpt so I converted one older drive. I also just as a test used gpt on my 16GB install. I still created a bios-grub, 8GB for the install and the rest is just for data, but not really used. I have no swap but with 4GB of RAM it works ok. I changed a lot of settings to reduce writes.

I have so many copies of Ubuntu installed I have to turn off os-prober and use my 40_custom to minimize entries and add spacers.

[brc816]

My apologies to Rod and Fred for being blatantly absent for the last week after they took the time to respond to me.

I was off trying to see if the Fedora 16 pre-Beta kits would fare any better and the answer appears to be they aren't.

I've pretty much come to the conclusion that the real issue is that Legacy Grub (0.97) and GRUB2 (1.99) both are designed/built with just 512 byte sectors in mind. I haven't studied the code of either of them yet, and my speculation could be way off base, but it appears that they each provide JUST a 512 byte boot block that's scribbled into the very first sector (call it "MBR" for now) of either the spindle (e.g., /dev/sdc) or the user-requested boot partition (e.g., /dev/sdc2). OK, fine, but I don't know what happens when it hits byte #513 assuming we actually DID write something into the first 512 bytes of the 4096 available.

In other words, until GRUB2 is re-designed/re-written to provide a 4096-byte boot block (and, obviously, other related files that would be affected by whatever design changes to the boot block are made), it's unlikely (IMNSHO, anyway) that we'll ever be able to boot off of the hardware that I specified in my OP. I'm well aware that that would not be a trivial task by any standard.

In the meanwhile, I do applaud Rod for his suggestion that I copy over the /boot directory to my primary system and boot through it. It's been working fairly well for me so far. I'm looking into simplifying it (i.e., just pointing the menu.lst stanza to execute core.img), but that's a work-in-progress.
With 2 new Betas coming out this week (openSUSE 12.1 and Fedora 16), plus the Oneiric Beta to re-install and try again, I'm going to be fairly busy!

Obviously, if my assumptions/speculations are erroneous, I'd appreciate the feedback - it's been a steep learning curve for me.

Thank you!!

[oldfred]

Thanks for the update.

I did find that a user with efi boot and 4k did work, see this bug report from Jan, 2011 that was fixed.
His fdisk showed this:

Sector size (logical/physical): 512 bytes / 4096 bytes

https://bugs.launchpad.net/ubuntu/+s...b2/+bug/702707

[brc816]

Hmmm - interesting. I need to study that and see *why*, but my suspicion is that it worked because he had an EFI-capable BIOS, which my HP dv9000z does not. (My 32-bit Acer Aspire netbook does, and boots a 1TB/512byte-sector WD Book drive very nicely - it's the behaviour that I was hoping for with the 3TB/4096-byte sector drive.)

The comments in that bug about missing device.map file(s) is also interesting - I've seen that kind of behaviour lately, too. I think it was on Oneiric, and I'm pretty sure I saw it on Fedora16 Alpha as well. I'll see if I can reproduce it later this week.

Thank you for the link to that bug, though - TBH, I haven't made an exhaustive search of Ubuntu's GRUB bugs yet.