# Proliant boots with MBR, but not GPT [SOLVED]

## Fog_Watch

Hello

I have a PATA drive attached to a Proliant DL380 G5 via a JMicron

chipset.  If I partition the drive with a MBR the machine boots.  With

the same installation files and same disk, only this time partitioned

with a GPT, the boot process detects the attached drive and then hangs

with a depressing "unable to mount root fs on unknown block(8,3)".

In a simlar thread:

 *NeddySeagoon wrote:*   

> 
> 
> You are missing one or more of  
> 
> Partition Table Driver
> ...

 

I can't see how any of these is missing.  Could it be that my Proliant just cannot handle GPTs?

Regards

Fog_Watch.

kernel-3.3.8-gentoo

root@grml /mnt # gdisk -l /dev/sda

GPT fdisk (gdisk) version 0.8.1

Partition table scan:

  MBR: protective

  BSD: not present

  APM: not present

  GPT: present

Found valid GPT with protective MBR; using GPT.

Disk /dev/sda: 390721968 sectors, 186.3 GiB

Logical sector size: 512 bytes

Disk identifier (GUID): E9C3E020-D7A3-4F58-9D5A-0CB44FF97A09

Partition table holds up to 128 entries

First usable sector is 34, last usable sector is 390721934

Partitions will be aligned on 2048-sector boundaries

Total free space is 369643885 sectors (176.3 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name

   1            2048            6143   2.0 MiB     EF02  

   2            6144          108543   50.0 MiB    8300  Boot

   3          108544        21080063   10.0 GiB    8300  Root

# grep sda fstab

/dev/sda2		/boot		ext2

	noauto,noatime	1 2 

/dev/sda3		/

	reiserfs		noatime		0 1

# grub2-install -v

grub2-install (GRUB) 2.00

# grep CONFIG_EFI_PARTITION .config

CONFIG_EFI_PARTITION=y

#More from the kernel.

# 

# SCSI device support

#

CONFIG_SCSI_MOD=y

# CONFIG_RAID_ATTRS is not set

CONFIG_SCSI=y

CONFIG_SCSI_DMA=y

# CONFIG_SCSI_TGT is not set

CONFIG_SCSI_NETLINK=y

# CONFIG_SCSI_PROC_FS is not set

#

# SCSI support type (disk, tape, CD-ROM)

#

CONFIG_BLK_DEV_SD=y

# CONFIG_CHR_DEV_ST is not set

# CONFIG_CHR_DEV_OSST is not set

CONFIG_BLK_DEV_SR=y

# CONFIG_BLK_DEV_SR_VENDOR is not set

CONFIG_CHR_DEV_SG=y

# CONFIG_CHR_DEV_SCH is not set

# CONFIG_SCSI_MULTI_LUN is not set

# CONFIG_SCSI_CONSTANTS is not set

# CONFIG_SCSI_LOGGING is not set

# CONFIG_SCSI_SCAN_ASYNC is not set

CONFIG_SCSI_WAIT_SCAN=mLast edited by Fog_Watch on Wed Oct 03, 2012 6:40 am; edited 1 time in total

----------

## VoidMage

Well, as the kernel is 3.3.8, did you try booting by PARTUUID ?

----------

## darkphader

Did you create a bios boot partition, a type ef02 raw (no file system) partition, on the GPT disk?

EDIT: sorry, I see that you did.

Might also need to use fdisk to mark the bootable partition (even though your symptoms are different) as in:

http://blog.realcomputerguy.com/2012/03/no-bootable-device-gpt.html

EDIT 2:

Is this set (don't know if it's necessary but I use it)?

CONFIG_BLK_DEV_BSG=y

EDIT 3:

Assuming SATA drive is this set and the BIOS set for AHCI as well?

CONFIG_SATA_AHCI=y

----------

## NeddySeagoon

Fog_Watch,

I use grub1 and GPT.  There is a minor trap for the unwary, not during the install but during updates.

With grub1 and GPT, there is no place to install the stage1.5 loader, so stage1 loads stage2 directly from a block list.

If stage2 moves around on the filesystem, e.g. grub is updated, you MUST install grub to the MBR again or horrible things may happen, since the stage1 needs a new blocklist to find the new stage2 file.   It will quite happily use the stage2 in the free space until a kernel update overwrites it.  Ask any lilo user.

The BIOS can't read GPT ... but it doesn't need to, it only reads the MBR.

IF your BIOS is brain dead an needs the bootable flag set, set it on the protective MSDOS Partition, ont on any of the GPT partitions.

----------

## Fog_Watch

When I was experiencing this problem I was booting with grml32_2011.12.iso.  When I switched to systemrescuecd-x86-3.0.0.iso the machine then booted.  I'm not saying that GRML was the problem and SystemRescueCD was the solution, its just that at around about this time I was able to boot.  Sorry I can't be more definitive.  Anyway, this is enough to mark this solved.

Thanks again for your contributions.

----------

