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