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. 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. 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. > > 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. -- Chris Murphy