Results 1 to 10 of 16

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

Hybrid View

  1. #1
    Join Date
    Dec 2007
    Location
    South Florida
    Beans
    22

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

    I've been trying to study various other threads, such as

    and http://ubuntuforums.org/showthread.php?t=1838078 in an attempt to set up a newly-purchased Seagate 3TB external USB drive with GPT partitioning and use it to boot Ubuntu Oneiric and, in the future, additional Linux distributions, without perturbing my day-to-day laptop configuration.

    My laptop is a 3.5 year old HP dv9000z with 4GB of memory, AMD Turion64 dual core CPU, NVIDIA GeForce 6150 graphics and a relatively vanilla Phoenix BIOS with, apparently, no (U)EFI capabilities. There are TWO 80GB SATA disk drives installed, the primary has Windows XP Media Edition (and its maintenance/re-installation partition), and the other drive has openSUSE 11.4.
    GRUB 0.97 was installed by openSUSE, and I can either let it
    boot openSUSE 11.4 automatically, or select Windows XP if I
    really want to boot that. I have a Western Digital 250GB external
    USB drive with standard old-fashioned MBR partitions and GRUB 0.97 (+/-, i.e. NOT GRUB2), and when it's plugged in prior to power-up, I can then boot various other distributions (Fedora, Natty, Mageia, ...) as desired. Yes, the BIOS boot device ordering is set correctly: DVD/CD, USB disk, internal hard disk, USB Floppy, ...

    I'm trying to do something like that with the new 3TB. After
    some fits and starts, I installed 'gdisk' on my openSUSE 11.4
    system and used it to repartition using GPT. This drive has
    4096 byte sectors. I've even been able to install Oneiric into a partition, and Fedora 16 to two others (/, /boot) as the latter is rumored to finally being able to cope with GPT and GRUB2.

    However, I've not been able to boot either system and, in fact, can't even get a "GRUB>" prompt - the BIOS acts like the drive isn't there and starts the GRUB 0.97 on the first hard drive.
    (As an aside, I have an Acer Aspire netbook with an Insyde H2O
    EFI BIOS that boots an external 1TB with GPT and Ubuntu/Natty's
    GRUB2 beautifully). openSUSE 11.4 comes up smiling, although the drive ordering is different (the 3TB shows up as /dev/sdb, the
    Windows disk is /dev/sda, the openSUSE 11.4 disk is /dev/sdc).

    My suspicion is that I've messed up the (boot block) and/or other
    important partition tables by using gparted, fdisk, and other tools (even if just to look at something). I'm prepared to wipe the drive (dd if=/dev/zero... comes to mind!) as necessary.

    Output from gdisk on openSUSE 11.4 as invoked as root, having plugged the 3TB drive in long after booting the system:

    Code:
    linux-9mjd:/home/obfuscated # gdisk /dev/sdc
    GPT fdisk (gdisk) version 0.7.2
    
    Partition table scan:
      MBR: protective
      BSD: not present
      APM: not present
      GPT: present
    
    Found valid GPT with protective MBR; using GPT.
    
    Command (? for help): print
    Disk /dev/sdc: 732566645 sectors, 2.7 TiB
    Logical sector size: 4096 bytes
    Disk identifier (GUID): D8FDAD5C-8335-46A3-BA1C-D44CF7D2C31E
    Partition table holds up to 128 entries
    First usable sector is 6, last usable sector is 732566639
    Partitions will be aligned on 256-sector boundaries
    Total free space is 626529130 sectors (2.3 TiB)
                                                                                                                    
    Number  Start (sector)    End (sector)  Size       Code  Name                                                   
       1             256             511   1024.0 KiB  EF02  BIOS boot partition                                    
       2             512          131583   512.0 MiB   EF00  ext4                                                   
       3          131584         1180159   4.0 GiB     8200  Linux swap                                             
       4         1180160        27394559   100.0 GiB   0700  Linux filesystem
       5        27394560        53608959   100.0 GiB   8300  Linux filesystem
       6        53608960        79823359   100.0 GiB   8300  Linux filesystem
       7        79823360       106037759   100.0 GiB   EF00  Ubuntu
    I tried to create 1MiB BIOS boot partition (worked nicely on my netbook's 1TB), a 512MB /boot partition for F16 on the second partition, a 4GB swap partition, and then four 100GB partitions, one for each distro of interest. Oneiric is installed on partition 7, Fedora 16 root is on partition 4.

    I've tried reinstalling ("grub-install") GRUB2 several times, even after booting the Oneiric Live CD and chrooting to the on-disk installation and using apt-get to update it to ensure that I had the latest-n-greatest bits. I'm assuming that I either don't understand GPT and GRUB2 well enough, or I've made a rash assumption about what can be legally/safely done. Any help would, of course, be greatly appreciated!

    Thanks in Advance!

  2. #2
    Join Date
    Mar 2010
    Location
    Woonsocket, RI USA
    Beans
    3,195

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

    Quote Originally Posted by brc816 View Post
    My laptop is a 3.5 year old HP dv9000z with 4GB of memory, AMD Turion64 dual core CPU, NVIDIA GeForce 6150 graphics and a relatively vanilla Phoenix BIOS with, apparently, no (U)EFI capabilities.
    ...
    After some fits and starts, I installed 'gdisk' on my openSUSE 11.4
    system and used it to repartition using GPT. This drive has
    4096 byte sectors.
    A disk with 4096-byte sectors has an MBR size limit of 2^32 * 4096 bytes, or 16 TiB. Thus, you can safely use MBR on this disk, at least from a disk and partition size perspective. That said, I personally prefer and recommend GPT for Linux-only installations even when it's not required from a size perspective. Also, the fact that you've already done several installations may make it easier to proceed by using what you've got than by repartitioning.

    However, I've not been able to boot either system and, in fact, can't even get a "GRUB>" prompt - the BIOS acts like the drive isn't there and starts the GRUB 0.97 on the first hard drive.
    Two possible causes occur to me:


    • Your BIOS may have a bug that's preventing it from booting from a GPT disk. I describe some such problems here. The most common cause of this problem is a bug that's most common on Intel-branded motherboards, although I've heard of cases of it on others, that prevents the board from booting if the MBR doesn't have any partition that's marked with a "boot" (aka "active") flag. The solution is to use Linux's fdisk (not parted or any other libparted-based tool!) to set the "boot" flag on the single 0xEE protective partition on the disk. You do this with the "a" option in fdisk, followed by "w" to save your changes.
    • Your BIOS may have limitations that prevent it from booting from a disk with 4096-byte sectors. If this is the case, the only solution I can think of is to place your Linux boot loader on one of your internal disks and use that to control the boot process, possibly even including loading the Linux kernel and initial RAM disk from the internal disk. Since you've got OpenSUSE on the second internal disk, you might be able to piggyback your other OSes' boot processes off of it by writing appropriate boot loader rules in OpenSUSE. Post back with your current OpenSUSE /boot/grub/menu.lst or /boot/grub/grub.conf file and information on where your Ubuntu and Fedora kernels and initial RAM disks are if you need help making these changes.



    It's possible that neither of these is the true cause of the problem, though; I could be missing something or be ignorant of some important fact. Nonetheless, both possibilities are worth investigating. If I had to place a bet, I'd say the 4096-byte issue is the more probable cause; however, setting the boot flag on the protective 0xEE partition is the easier cure, so it's probably best to start by doing that. (If it doesn't help, you can always undo the change.)

    My suspicion is that I've messed up the (boot block) and/or other
    important partition tables by using gparted, fdisk, and other tools (even if just to look at something). I'm prepared to wipe the drive (dd if=/dev/zero... comes to mind!) as necessary.
    I doubt if you've done any damage that necessitates such radical action. At worst, you could wipe the partition table by using parted or GParted to create a fresh partition table (MBR or GPT) or by using the 'z' option on gdisk's experts' menu. Either option will be much quicker than wiping the whole disk!

    Below are comments that aren't related to your main problem....

    Output from gdisk on openSUSE 11.4 as invoked as root, having plugged the 3TB drive in long after booting the system:

    Code:
    linux-9mjd:/home/obfuscated # gdisk /dev/sdc
    GPT fdisk (gdisk) version 0.7.2
    
    Partition table scan:
      MBR: protective
      BSD: not present
      APM: not present
      GPT: present
    
    Found valid GPT with protective MBR; using GPT.
    
    Command (? for help): print
    Disk /dev/sdc: 732566645 sectors, 2.7 TiB
    Logical sector size: 4096 bytes
    Disk identifier (GUID): D8FDAD5C-8335-46A3-BA1C-D44CF7D2C31E
    Partition table holds up to 128 entries
    First usable sector is 6, last usable sector is 732566639
    Partitions will be aligned on 256-sector boundaries
    Total free space is 626529130 sectors (2.3 TiB)
                                                                                                                    
    Number  Start (sector)    End (sector)  Size       Code  Name                                                   
       1             256             511   1024.0 KiB  EF02  BIOS boot partition                                    
       2             512          131583   512.0 MiB   EF00  ext4                                                   
       3          131584         1180159   4.0 GiB     8200  Linux swap                                             
       4         1180160        27394559   100.0 GiB   0700  Linux filesystem
       5        27394560        53608959   100.0 GiB   8300  Linux filesystem
       6        53608960        79823359   100.0 GiB   8300  Linux filesystem
       7        79823360       106037759   100.0 GiB   EF00  Ubuntu
    Assuming those partition names are accurate, the /dev/sda2 and /dev/sda7 partitions both have improper type codes -- EF00 is gdisk's code for an EFI System Partition (ESP), which is almost certainly useless on your computer, and which should normally have a FAT filesystem. The ESP holds EFI boot loaders and other files that are used by the firmware. Unfortunately, libparted identifies these partitions by giving them a "boot flag" -- a flag of the same name that's used to identify bootable partitions under MBR. This causes confusion at best. You should probably set these two have type codes of 0700 or 8300. An improper type code is unlikely to be causing your boot problems, but it could cause confusion down the line. In a worst-case scenario, some utility could get confused and try creating a fresh FAT filesystem on one or both of these partitions. That's unlikely, but changing the type code is easy protection.

    The 0700 type code (used on your /dev/sda4) is the type code for Microsoft filesystems. Linux has generally used the same type code itself, so you'll often see it on Linux filesystems. Recently, the libparted developers and I (I'm the author of gdisk) agreed on a new type code for Linux filesystems, which gdisk reports as 8300. The main advantage of using 8300 rather than 0700 is that 8300 partitions won't show up under Windows Vista/7 as "unformatted;" Windows will ignore them. Since you've only got Windows XP on this computer, and XP doesn't understand GPT disks, there's little to recommend one over the other, unless you think you might want to upgrade Windows or move the disk to another computer in the future, in which case 8300 makes more sense.

    For the most part, Linux ignores partition type codes, so these issues (including the improper ESP type codes on two partitions) are mostly of concern for non-Linux OSes. Setting them appropriately can minimize the risk of future confusion, though.
    If I've suggested a solution to a problem and you're not the original poster, do not try my solution! Problems can seem similar but be different, and a good solution to one problem can make another worse. Post a new thread with your problem details.

  3. #3
    Join Date
    Dec 2007
    Location
    South Florida
    Beans
    22

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

    srs5694 and I have been exchanging some private e-mails on this issue. I have a number of ways I can attempt to solve this issue, which I'm still mulling over.

    First, I might be successful if I re-partition the disk using MBR and a number of logical partitions, because the disk uses 4096 byte sectoring, yet is still small enough for MBR to still work. I would probably create 3 primary partitions, and then keep the rest of the drive in an extended partition and create logical partitions within it and see if that suffices.

    Second, although I'd like to use GPT so as to be able to arbitrarily add additional partitions, it appears that I could do the same thing using MBR and LVM. I'm not that familiar with LVM (although I worked with a couple of similar products a few years ago under a commercial UNIX product, so I'm familiar with the concepts) - a moderate learning curve is looming!

    Third, I did attempt, using fdisk, to make the GPT "partition" bootable, but I was still unable to write a GRUB2 boot block to it (or if I did succeed, it wasn't evident as I still couldn't boot it, nor even get a GRUB> prompt!).

    Fourth, I'm not inclined to try a virtual machine for now, but will if nothing else seems to work. I just increased my memory from 2 to 4GB, and that's as far as I can take it with this laptop. The BIOS is reasonably current - it's one rev behind, for a battery power reporting problem under Windows - and this box will never be able (according to HP) to run Windows 7. It wasn't clear as to exactly why, but I suspect the lack of EFI support may be a factor.

    Fifth, I could also try to set up a boot stanza under my current openSUSE 11.4 set-up (and, perhaps, set up a directory under its root partition to hold the files needed to boot the 3TB drive). However, I'm concerned that the legacy GRUB 0.97 might not react properly - drive ordering has always been, um, interesting when plugging in a bootable USB drive and some distros still don't sort it all out correctly, requiring manual intervention (editing of menu.lst) to correct the drive/partition numbering.

    Since none of the "data" currently sitting on this drive is important - i.e., it's just a scratch/sandbox disk - I'm leaning in favor of starting from scratch and repartitioning with MBR and see if the 4096 byte sectoring is the root cause of my problem. But, if anyone has any further observations, I'd appreciate them. If I get that working, then I'll look again at GPT partitioning and see if there's a bug lurking or if we need to document an installation restriction or something. I'm playing with this in between a number of other projects at home, so there's no particularly critical timeframe, at least from my perspective. My thanks to Rod and others for their patient help!

  4. #4
    Join Date
    Mar 2010
    Location
    Woonsocket, RI USA
    Beans
    3,195

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

    Quote Originally Posted by brc816 View Post
    Fifth, I could also try to set up a boot stanza under my current openSUSE 11.4 set-up (and, perhaps, set up a directory under its root partition to hold the files needed to boot the 3TB drive). However, I'm concerned that the legacy GRUB 0.97 might not react properly - drive ordering has always been, um, interesting when plugging in a bootable USB drive and some distros still don't sort it all out correctly, requiring manual intervention (editing of menu.lst) to correct the drive/partition numbering.
    If you can put the Ubuntu kernel and initial RAM disk on your laptop's internal disk, then GRUB's quirks with respect to drive ordering evaporate. This is because GRUB's job is to load the kernel, load the initial RAM disk, and execute the kernel. Once the kernel is running, it's the kernel that's in charge of the rest, including locating its root (/) partition. Thus, if the root (/) partition is on the USB drive but the kernel and initial RAM disk are on an internal disk, GRUB doesn't need to know a thing about the USB drive.

    One caveat: If the BIOS becomes confused about drive ordering when you plug in the USB drive, then all bets are off. This is because the BIOS does its thing before GRUB, and GRUB actually relies on BIOS calls to load the kernel and the initial RAM disk. You might be able to work around such a problem by fiddling with BIOS settings, though. In fact, configuring the BIOS so that USB devices are not bootable might fix the problem!
    If I've suggested a solution to a problem and you're not the original poster, do not try my solution! Problems can seem similar but be different, and a good solution to one problem can make another worse. Post a new thread with your problem details.

  5. #5
    Join Date
    Dec 2007
    Location
    South Florida
    Beans
    22

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

    Hmmm... that IS a very interesting idea.

    I'm assuming, however, that I'll have to use stitch in the correct parameters to the kernel and initrd lines, which I'll cut-n-paste from Oneiric's grub.cfg.

    Here's my current, working, unadulterated /boot/grub/menu.lst on my openSUSE 11.4 installation that uses two internal 80GB Toshiba SATA hard drives:
    Code:
    # more /boot/grub/menu.lst
    # Modified by YaST2. Last modification on Thu Aug 25 16:49:28 EDT 2011
    # THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
    # Configure custom boot parameters for updated kernels in /etc/sysconfig/bootloader
    
    default 0
    timeout 8
    gfxmenu (hd1,1)/boot/message
    
    ###Don't change this comment - YaST2 identifier: Original name: linux###
    title Desktop -- openSUSE 11.4 - 2.6.37.6-0.7
        root (hd1,1)
        kernel /boot/vmlinuz-2.6.37.6-0.7-desktop root=/dev/disk/by-id/ata-TOSHIBA_MK8034GSX_Y6SIT3WMT-part2 resume=
    /dev/disk/by-id/ata-TOSHIBA_MK8034GSX_Y6SIT3WMT-part1 splash=silent quiet showopts nomodeset vga=0x348
        initrd /boot/initrd-2.6.37.6-0.7-desktop
    
    ###Don't change this comment - YaST2 identifier: Original name: failsafe###
    title Failsafe -- openSUSE 11.4 - 2.6.37.6-0.7
        root (hd1,1)
        kernel /boot/vmlinuz-2.6.37.6-0.7-desktop root=/dev/disk/by-id/ata-TOSHIBA_MK8034GSX_Y6SIT3WMT-part2 showopt
    s apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe vga=
    0x348
        initrd /boot/initrd-2.6.37.6-0.7-desktop
    
    ###Don't change this comment - YaST2 identifier: Original name: windows 1###
    title windows 1
        rootnoverify (hd0,0)
        chainloader +1
    
    ###Don't change this comment - YaST2 identifier: Original name: windows 2###
    title windows 2
        rootnoverify (hd0,1)
        chainloader +1
    So, I think I'll plan on creating a "/boot/Seagate" on my openSUSE 11.4 disk to house the kernels and initrd's for Oneiric (and, perhaps, others distros later) and then add something like this to my existing /boot/grub/menu.lst:
    Code:
    title OneiricTest -- Ubuntu, with Linux 3.0.0-11-generic on 3TB
        root (hd1,1)
        kernel /boot/Seagate/vmlinuz-3.0.0-11-generic root=/dev/disk/by-id/81c7c0e8-4e69-4d8b-ab19-d9cf3a97c065 ro nomodeset noresume
        initrd /boot/Seagate/initrd.img-3.0.0-11-generic
    But, I am having problems with the exact semantics since I'd be using Legacy Grub (0.97), but grabbing a kernel that might or might not identify its disks as "/dev/disk/by-id/". Clearly, I'll be augmenting the exact kernel arguments (although, for now, 'nomodeset' is an absolute requirement!), and will want to specify the swap partition on the 3TB spindle for the 'resume' clause. (Chainloading directly to the GRUB2 stuff on the 3TB would be wonderful, but I don't think legacy GRUB will let me).

  6. #6
    Join Date
    Dec 2007
    Location
    South Florida
    Beans
    22

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

    SUCCESS ! (BUT, I'm not going to mark it as 'SOLVED' quite yet, but it's looking good).

    My initial attempt to boot using the semantics in my previous reply failed, with initramfs "giving up - unable to find root" and dropping to its (quite limited) shell. When poking around, I discovered that initram saw various "devs", including "sdc7", "sdc3", etc. This solved my semantics problem - I re-edited my menu.lst:

    Code:
    ##Added manually 16 Sep 2011 1005EDT
    title OneiricTest -- Ubuntu, with Linux 3.0.0-11-generic on 3TB
        root (hd1,1)
        kernel /boot/Seagate/vmlinuz-3.0.0-11-generic root=/dev/sdc7 ro nomodeset resume=/dev/sdc3
        initrd /boot/Seagate/initrd.img-3.0.0-11-generic
    Note that I had already created the ad-hoc "/boot/Seagate" directory on my openSUSE platter, and copied the contents of the Oneiric /boot (but NOT /boot/grub) directory to it:

    Code:
    -rw-r--r-- 1 root root   730507 Sep  2 15:29 abi-3.0.0-10-generic
    -rw-r--r-- 1 root root   730434 Sep 14 00:53 abi-3.0.0-11-generic
    -rw-r--r-- 1 root root   730234 Aug 30 11:52 abi-3.0.0-9-generic
    -rw-r--r-- 1 root root   134703 Sep  2 15:29 config-3.0.0-10-generic
    -rw-r--r-- 1 root root   134703 Sep 14 00:53 config-3.0.0-11-generic
    -rw-r--r-- 1 root root   134769 Aug 30 11:52 config-3.0.0-9-generic
    -rw-r--r-- 1 root root 13736410 Sep 13 20:28 initrd.img-3.0.0-10-generic
    -rw-r--r-- 1 root root 13736703 Sep 14 22:56 initrd.img-3.0.0-11-generic
    -rw-r--r-- 1 root root 13736497 Sep  5 16:08 initrd.img-3.0.0-9-generic
    -rw-r--r-- 1 root root   176764 May  2 19:07 memtest86+.bin
    -rw-r--r-- 1 root root   178944 May  2 19:07 memtest86+_multiboot.bin
    -rw------- 1 root root  2694141 Sep  2 15:29 System.map-3.0.0-10-generic
    -rw------- 1 root root  2694177 Sep 14 00:53 System.map-3.0.0-11-generic
    -rw------- 1 root root  2692451 Aug 30 11:52 System.map-3.0.0-9-generic
    -rw------- 1 root root     1367 Sep  2 15:30 vmcoreinfo-3.0.0-10-generic
    -rw------- 1 root root     1367 Sep 14 00:58 vmcoreinfo-3.0.0-11-generic
    -rw------- 1 root root     1366 Aug 30 11:54 vmcoreinfo-3.0.0-9-generic
    -rw------- 1 root root  4657904 Sep  2 15:29 vmlinuz-3.0.0-10-generic
    -rw------- 1 root root  4658672 Sep 14 00:53 vmlinuz-3.0.0-11-generic
    -rw------- 1 root root  4654192 Aug 30 11:52 vmlinuz-3.0.0-9-generic
    By doing all this, I was able to boot Oneiric just fine.

    It's a hack - an ugly hack - but it appears to be working for now. It's ugly because every time Oneiric upgrades its kernel giblets, I'll have to manually recopy them over to my openSUSE /boot/Seagate directory and re-edit menu.lst. It also means that I really should move them down to a new /boot/Seagate/Oneiric directory (and amend menu.lst appropriately) so that if I chose to plop Fedora 16, Mageia 2.0, and/or openSUSE 11.4 onto my 3TB for testing, I can.

    It doesn't test GRUB2 (be it Oneiric's sub-version or Fedora 16's, for example), but that'll give me something to tinker with later on. But, for now, I can boot Oneiric off of the 3TB drive,
    and was able to log in.

    Thank you, Rod !!

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •