[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