[lug] more RAID0 on /
D. Stimits
stimits at comcast.net
Sat Nov 20 14:07:53 MST 2004
Lee Woodworth wrote:
> D. Stimits wrote:
>
>> Lee Woodworth wrote:
>
>
> .....
>
>>> You didn't say whether you are unplugging the IDE drives when you are
>>> switching from IDE to SCSI mode. If the IDEs are still present, they
>>> could affect what is considered /dev/md0.
>>
>> The motherboard has integrated U160 SCSI and integrated IDE. All I do
>> is change the bios boot setting and it does the right thing. The first
>> stage of booting works fine, it reads /boot/ and the error message
>> properly names not being able to mount /dev/md0 via major 9, minor 0.
>
> This is the error from /boot/vmlinuz... which is using an initrd? I
Vmlinuz has already loaded at this stage and a number of things have
already succeeded, including proof that /boot/ has been read fine and
that vmlinuz has in fact loaded. Yes, it uses an initrd, but all MD
functionality is hard coded into the kernel...those modules do not even
exist in the IDE install either, it works fine, plus the kernel was
compiled with newer features to build in the config settings...I can
absolutely guarantee that this kernel has device mapper and IDE hard
coded. I have decompressed and mounted the initrd on loopback and can
guarantee scsi is available that way, plus the /boot/ *is* on SCSI and
it would have never read grub or loaded vmlinuz if it had not. I
guarantee absolutely that it has device mapper, IDE, SCSI, and MD
available as it boots. Not possible with how far it has succeeded to not be.
> suspect that the md driver isn't in your kernel or hasn't been loaded
> from an initrd. I have a 2.6.8 kernel with the device-mapper compiled-in
> (CONFIG_BLK_DEV_MD=y, same flag for RAID Support) and the device
Same here. Also the device mapper config is "y" not "m".
> /dev/md0 (aka /dev/md/0) exists even with no raid partitions. When I
> mount /dev/md0 when there is no actual device, I get 'can't read
> superblock'.
Here is the thing...these md partitions *have* the persistent
superblock, and are marked properly for autodetect in fdisk. When
booting on the IDE it does in fact autodetect but on IDE md0 is not the
root. When I boot with the KRUD rescue CD, it won't let me mount md0
until I first run raidstart /dev/md0, and then I can mount it just fine.
It appears autodetect is more of a pseudo-detect in user space and that
the kernel itself is not able to do this without user space utilities
that include some scripting which the kernel itself is unable to trigger.
>
>> Anyway, when the BIOS is set to IDE the drive reported as boot by BIOS
>> is the IDE, and when it is set to SCSI, it is the SCSI...this system
>> was on SCSI for a long time till I ran out of drive and did the FC2
>> install to IDE so I wouldn't lose what I had...then I copied over what
>> needed to be backed up to the IDE, and wiped the SCSI clean and have
>> been experimenting with RAID0 since then. Back when I did this with
>> XFS filesystem before the stock kernel supported it, I did this same
>> thing and I had kept the IDE install for a long time as a rescue disk
>
> I have seen motherboard features that were turned off by the BIOS still
> being seen by later boot stages of the final OS (for example W2K/W2K3
> sees disabled scsi controllers). Are the IDE disks being detected before
> the kernel panic?
>
Nope, I'm saying I have done this with other installs for several years
on this machine and that from trial and error I can guarantee this is
not the case. It definitely gets the device numbers correct and orders
them properly. I've done similar upgrades for every system upgrade
(since before RH 7.0, and multiboot with NT4 and win2k) this machine has
had, and the BIOS setting does properly order things. It gets to the
point of needing to mount /dev/md0 on root and complains it md0 can't be
mounted because md0 is not valid root device.
I've been experimenting today with kernel parameters but so far no luck
on that either (I have more experiments left to do on this though).
D. Stimits, stimits AT comcast DOT net
More information about the LUG
mailing list