Setting up Software RAID: superblock vs. physical size problem - Hardware

This is a discussion on Setting up Software RAID: superblock vs. physical size problem - Hardware ; I'm running Debian/Etch (2.6.18-6-k7 kernel) as a server, with all the updates. I recently installed a second hard drive (both are Western Digital 80G/IDE) of identical size to the original but with a different geometry. To get things started I ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Setting up Software RAID: superblock vs. physical size problem

  1. Setting up Software RAID: superblock vs. physical size problem

    I'm running Debian/Etch (2.6.18-6-k7 kernel) as a server, with all the
    updates. I recently installed a second hard drive (both are Western
    Digital 80G/IDE) of identical size to the original but with a different
    geometry. To get things started I did a:
    dd if=/dev/hda of=/dev/hdc
    to get the same setup on both. Each is partitioned with:
    - hd?1 ==> / as /dev/md0
    - hd?2 ==> swap
    - hd?3 ==> /home as /dev/md1

    I've been able to get /home working as /dev/md1. I've kept the swap
    partitions out of the RAID-1 array because it may be slower and who
    needs redundant swap partitions anyway. Instead I've got two swap
    partitions on different spindles.

    Unfortunately I can't get /dev/md0 working. Both /dev/hda1 and /dev/hdc1
    check out OK with fsck.ext3 -f and neither will auto-resize with
    resize2fs. They are both perfect as far as I can tell.

    However, when I build the array, with either or both partitions in it,
    the reboot fails. I get an error message telling me the superblock is 16
    blocks larger than the physical device size. The superblock's reported
    size is the same as the size of either partition.

    If I try to resize the partition outside of the array, I get told that
    it's the correct size. If I try to resize the /dev/md0 array, I get a
    read error - something about a short block.

    The reboot will not proceed with the superblock having a different size
    from the physical device. It gets to the point where single-user mode
    ends (and I didn't boot to single-user mode!) and gives me the error
    message followed by the usual Ctrl-D to continue message, except that
    Ctrl-D takes me into a reboot.

    I've built and taken down the array multiple times but I can't get
    beyond this point.

    Any ideas on what is going on and how to fix it?

  2. Re: Setting up Software RAID: superblock vs. physical size problem

    Gary Dale wrote:

    > I'm running Debian/Etch (2.6.18-6-k7 kernel) as a server, with all the
    > updates. I recently installed a second hard drive (both are Western
    > Digital 80G/IDE) of identical size to the original but with a different
    > geometry. To get things started I did a:
    > dd if=/dev/hda of=/dev/hdc


    You shouldn't do that. The "persistent superblocks" need place at the end of
    the disks, which may already be occupied by partitions here.
    First have a good look at "man mdadm", best is to printout or have a 2nd box
    with the manpages handy.
    The correct way would be
    - first setting up a set of partitions wit "fd" raid1 partition signature,
    and "missing" 2nd disk on the new drive, leaving a few MB free at the end.
    Then format the partitions like the couterparts on the other drive,
    copy over the contents (cp -a). Reinstate bootloader for the new drive.
    If you want to switch master - slave or boot order, remember to
    adjust /etc/fstab and grub/lilo.conf as well.
    You need a line like raid-extra-boot=mbr
    for lilo to update both mbrs and make both drives bootable, don't know how
    grub will handle that.
    Now after booting the "degraded" array, and you are sure your partitions are
    working, you can repartition the original drive the same way, and then
    hotadd the partitions to the array. Give enough time (monitor
    with "cat /proc/mdstat") to let them sync, before you may reboot.

    --
    vista policy violation: Microsoft optical mouse found penguin patterns
    on mousepad. Partition scan in progress to remove offending
    incompatible products. Reactivate MS software.
    Linux 2.6.23.9-2mdvtmbcustom. [LinuxCounter#295241,ICQ#4918962]

  3. Re: Setting up Software RAID: superblock vs. physical size problem

    Walter Mautner wrote:
    > Gary Dale wrote:
    >
    >> I'm running Debian/Etch (2.6.18-6-k7 kernel) as a server, with all the
    >> updates. I recently installed a second hard drive (both are Western
    >> Digital 80G/IDE) of identical size to the original but with a different
    >> geometry. To get things started I did a:
    >> dd if=/dev/hda of=/dev/hdc

    >
    > You shouldn't do that. The "persistent superblocks" need place at the end of
    > the disks, which may already be occupied by partitions here.
    > First have a good look at "man mdadm", best is to printout or have a 2nd box
    > with the manpages handy.
    > The correct way would be
    > - first setting up a set of partitions wit "fd" raid1 partition signature,
    > and "missing" 2nd disk on the new drive, leaving a few MB free at the end.
    > Then format the partitions like the couterparts on the other drive,
    > copy over the contents (cp -a). Reinstate bootloader for the new drive.
    > If you want to switch master - slave or boot order, remember to
    > adjust /etc/fstab and grub/lilo.conf as well.
    > You need a line like raid-extra-boot=mbr
    > for lilo to update both mbrs and make both drives bootable, don't know how
    > grub will handle that.
    > Now after booting the "degraded" array, and you are sure your partitions are
    > working, you can repartition the original drive the same way, and then
    > hotadd the partitions to the array. Give enough time (monitor
    > with "cat /proc/mdstat") to let them sync, before you may reboot.
    >


    The howto at
    http://www.howtoforge.org/software-r...ot-debian-etch (nor the
    corrections) doesn't mention having to set the disk size as being
    smaller than the whole disk. And indeed, I do have a running /dev/md1
    array - the last bit of the disk - which seems to counter your idea that
    the superblocks are the problem.

    Indeed, the whole issue isn't that the arrays aren't being recognized,
    which is what the persistent superblocks are there for. It's that the
    superblock size and the physical size seem to be different on the boot
    array (and just on the boot array), which is the first bit on the disk.

    Anyway, the devices seem to have valid superblocks. I can zero the
    superblocks and recreate them without any problems, other than the
    mdadm.conf having to be updated because the UUID changes.

    I'm not trying to be argumentative here, but the server is in another
    part of the city and it takes a while to get there and back. I want to
    know that I've got the correct solution before I go there (I can't do
    this remotely because the server won't reach the stage the network comes
    up if I make a mistake).

+ Reply to Thread