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