[nSLUG] kernel setup stack overlaps lilo

bdavidso at supercity.ns.ca bdavidso at supercity.ns.ca
Sat Mar 13 02:07:35 AST 2004


Hi again:

Just to follow up my own post:

On Sat, 13 Mar 2004 bdavidso at supercity.ns.ca wrote:
[snip]
>
> As to RAID: I sympathize, having coerced a couple of Debian Woody systems
> to boot from RAID1 partitions.  To get that working I found the use of a
> boot floppy to be invaluable, but a boot CDROM would also have worked.

But what I meant to say was that use of a boot flopy was, in that case,
simpler, especially with rdev to tell the same kernel to use a different
(/dev/mdx) root device.

> With newer kernels and raidtools, I don't think you actually need
> /etc/raidtab, the kernel groks the RAID configuration from the persistent
> superblock, and you can build the array using raidtools without
> referencing the raidtab file.  A while ago a machine using a RAID1 mirror
> had a problem on boot, and wouldn't recognize one of the drives.  I wasn't
> sure whether the problem was the drive or the controller, so I removed the
> drive, stuck it in another machine (it was hdc in both machines), booted
> the new machine from a knoppix CD, and used the raidtools to examine the
> drive.  The raid tools correctly told me everything I needed to know about
> the partitions, the drive seemed OK, so I put it back after using
> mdadm to mark it bad, the add it back to the array (details are fuzzy, but
> see mdadm(8)).  Check it out, and free yourself from raidtab!

Just to be clear, I concluded that the drive was fine and installed BOTH
drives in a new box because the secondary IDE controller must be hosed on
the old box.  Of course, on testing the old box has behaved just fine, and
the old hdc is starting to show bad clusters...  But when I did the
initial tests the old drive seemd fine so I concluded that the controller
was bad.  The good news is, it's RAID so I haven't actually lost any data
even with one bad physical partition.

-- 
Bill Davidson
bdavidso at supercity.ns.ca





More information about the nSLUG mailing list