[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]

Re: redhat kernel compiling with raid root



Kapil Sharma wrote:
> 
> Hi,
>  I have compiled the kernel 2.2.16 kernel using kgcc successfully. I am
> using
>  software raid1 with scsi disks. I also compiled raid1 and scsi support and
>  aic7XXX driver for adaptec scsi card in a kernel (not as a module). Then I
>  made a initrd image and change the configuration in lilo.conf specifying
>  boot image and initrd image. Now I am unable to boot from this new kernel.
>  It is unable to mount the root partition. The problem comes after scsi
> disks
>  detection. The problem is as follows:
> 
>  kernel panic: VFS: unable to mount root from 09:01
> oops! md1 not running, giving up!
>  Bad md_map in ll_rw_block
>  EXT2-fs unable to read super block.
>  Invalid session number or type of track
> 
> Today I solved this problem with compiling redhat kernel source code
> (2.2.16-22 kernel) with raid, aic7xxx drivers as modules and making initrd.
> As redhat kernel source code supports autodetecting raid, I can boot my
> system. I also tried 2.2.18 kernel but it also doesn't support the
> autodetecting the raid devices. Can any body explain about any patches by
> which I can et support for autodetecting the raid on boot using md driver.
> 
>

  Red Hat like most linux distros patches software raid.  If you want to
use a kernel from Linus, or not from a major Linux vendor grab mingo's
raid patch.  Linus doesn't like this patch as it isn't backwards
compatible with really old raid configurations.  If Red Hat's 2.2.16
works for then mingo's patch will work.

ftp://ftp.us.kernel.org/pub/linux/kernel/people/mingo/raid-patches/

PS-  Software raid support is broken on P-III's in 2.4.0.  I'd guess
it's an issue with MMX optimizations.  It seems to work on PII, and
various amd chipsets.  I've not tried the 2.4 sw-raid suppotyin a
meaningful way yet,

-- 
Solving people's computer problems always
requires more hardware be given to you.
(The Second Rule of Hardware Acquisition)
Samuel J. Flory  <sam@xxxxxxxxxxx>