[CentOS] CentOS 5 grub boot problem

Wed Aug 5 16:52:31 UTC 2015

On 8/5/2015 12:34 PM, Chris Murphy wrote:
> On Wed, Aug 5, 2015 at 9:12 AM, Bowie Bailey <Bowie_Bailey at buc.com> wrote:
>> I am trying to upgrade my system from 500GB drives to 1TB.
> I'm going to guess that there are no IDE drives that have 4096 byte
> physical sectors, but it's worth confirming you don't have such a
> drive because the current partition scheme you've posted would be
> sub-optimal if it does have 4096 byte sectors.

The partition table was originally created by the installer.

>   I was able to
>> partition and sync the raid devices, but I cannot get the new drive to boot.
>>
>> This is an old system with only IDE ports.  There is an added Highpoint raid
>> card which is used only for the two extra IDE ports. I have upgraded it with
>> a 1TB SATA drive and an IDE-SATA adapter.  I did not have any problems with
>> the system recognizing the drive or adding it to the mdraid.  A short SMART
>> test shows no errors.
>>
>> Partitions:
>> Disk /dev/hdg: 1000.2 GB, 1000204886016 bytes
>> 255 heads, 63 sectors/track, 121601 cylinders
>> Units = cylinders of 16065 * 512 = 8225280 bytes
>>
>>     Device Boot      Start         End      Blocks   Id  System
>> /dev/hdg1               1          25      200781   fd  Linux raid
>> autodetect
>> /dev/hdg2              26      121537   976045140   fd  Linux raid
>> autodetect
>> /dev/hdg3          121538      121601      514080   fd  Linux raid
>> autodetect
> In the realm of totally esoteric and not likely the problem, 0xfd is
> for mdadm metadata v0.9 which uses kernel autodetect. If the mdadm
> metadata is 1.x then the type code ought to be 0xda but this is so
> obscure that parted doesn't even support it. fdisk does but I don't
> know when support was added. This uses initrd autodetect rather than
> the deprecated kernel autodetect. It's fine to use 0.9 even though
> it's deprecated.
>
> You can use mdadm -E on each member device (each partition) to find
> out what metadata version is being used.

Version : 0.90.00

> Normally GRUB stage 1.5 is not needed, stage 1 can jump directly to
> stage 2 if it's in the MBR gap. But your partition scheme doesn't have
> an MBR gap, you've started the first partition at LBA 1. So that means
> it'll have to use block lists...
>
>> I installed grub on the new drive:
>> grub> device (hd0) /dev/hdg
>>
>> grub> root (hd0,0)
>>   Filesystem type is ext2fs, partition type 0xfd
>>
>> grub> setup (hd0)
>>   Checking if "/boot/grub/stage1" exists... no
>>   Checking if "/grub/stage1" exists... yes
>>   Checking if "/grub/stage2" exists... yes
>>   Checking if "/grub/e2fs_stage1_5" exists... yes
>>   Running "embed /grub/e2fs_stage1_5 (hd0)"...  15 sectors are embedded.
>> succeeded
>>   Running "install /grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/grub/stage2
>> /grub/grub.conf"... succeeded
>> Done.
> I'm confused. I don't know why this succeeds because the setup was
> pointed to hd0, which means the entire disk, not a partition, and yet
> the disk doesn't have an MBR gap. So there's no room for GRUB stage 2.

I'm not sure.  It's been so long that I don't remember what I did (if 
anything) to get grub working on the second drive of the set. The first 
drive was configured by the installer.

What I'm doing now is what I found to work for my backup system which 
gets a new drive in the raid set every month.

>> But when I attempt to boot from the drive (with or without the other drive
>> connected and in either IDE connector on the Highpoint card), it fails.
>> Grub attempts to boot, but the last thing I see after the bios is the line
>> "GRUB Loading stage 1.5", then the screen goes black, the system speaker
>> beeps, and the machine reboots.  This will continue as long as I let it.  As
>> soon as I switch the boot drive back to the original hard drive, It boots up
>> normally.
> Yeah it says it's succeeding but it really isn't, I think. The problem
> is not the initrd yet, because that could be totally busted or
> missing, and you should still get a GRUB menu. This is all a failure
> of getting to stage 2, which then can read the file system and load
> the rest of its modules.
>
>
>> I also tried installing grub as (hd1) with the same results.
> I'm disinclined to believe that hd0 or hd1 translate into hdg, but I
> forget how to list devices in GRUB legacy. I'm going to bet though
> that device.map is stale and it probably needs to be recreated, and
> then find out what the proper hdX is for hdg. And then I think you're
> going to need to point it at a partition using hdX,Y.

I'm willing to give that a try.  The device.map looks good to me:
(hd0)     /dev/hde
(hd1)     /dev/hdg

It is old, but the drives are still connected to the same connectors, so 
it should still be valid.

How would I go about pointing it at the partition?

What I am currently doing is this:
device (hd0) /dev/hdg
root (hd0,0)
setup (hd0)

Would I just need to change the setup line to "setup (hd0,0)", or is 
there more to it than that?

Also, the partitions are mirrored, so if I install to a partition, I 
will affect the working drive as well.  I'm not sure I want to risk 
breaking the setup that still works.  I can take this machine down for 
testing pretty much whenever I need to, but I can't leave it down for an 
extended period of time.

-- 
Bowie