LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Debian (https://www.linuxquestions.org/questions/debian-26/)
-   -   installing X causes RAID to fail (https://www.linuxquestions.org/questions/debian-26/installing-x-causes-raid-to-fail-319703/)

mrog 05-03-2005 09:22 AM

installing X causes RAID to fail
 
Hello:

I'm wondering if anyone else has come across this problem...

I've been trying to get RAID up and going (consistently) for a few days now. After attempting many things such as installing with/without a desktop, changing partition sizes and changing the number of partitions, I've narrowed down that installing X and a desktop environment is causing RAID to fail at boot. (i.e. If I just do a base install and configure RAID through the installer, it will work.)

However, if I install X and a desktop environment either through the installer or afterwards, the RAID arrays - except md1 (/boot) - will not mount. This result is mimiced in /proc/mdstat which only shows the one array.

The loadmodules file in the initrd.img image show the following modules being loaded at boot and looks identical to this before installing x/desktop.

modprobe -k vesafb > /dev/null 2>&1
modprobe -k fbcon 2> /dev/null
modprobe -k unix 2> /dev/null
modprobe -k raid1
modprobe -k ata_piix
modprobe -k aacraid
modprobe -k sc_mod

The /etc/default/mdadm file looks like this and again is the same as before installing x/desktop.

START_DAEMON=true
MAIL_TO="root"
AUTOSTART=true

The /etc/mdadm/mdadm.conf file - which again looks identical - is like this:

DEVICE partitions
ARRAY /dev/md7 level-raid1 num-devices=2 UUID=[a bunch of hex stuff]
devices=/dev/sda12,/dev/sdb12

[and then continues with the "ARRAY" and "devices" lines as you would expect for each array matching it with the two corresponding partitions.]

As a note on this file, I've tried regenerating it (mdadm --detail --scan >> /etc/mdadm/mdadm.conf) and having the first line read "DEVICE /dev/sda* /dev/sdb*" which doesn't help.

I've tried rebuilding the initrd.img image - still no improvement.

The Grub device.map and menu.lst files look identical to what they looked like before the x/desktop installation.

The error that occurs at boot for each of the unmounted arrays is like:

fsck.ext3: No such file or directory while trying to open /dev/md1
/dev/md1:
The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains and ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

Any help would on why this happens after installing x/desktop would be greatly appreciated.

Thank you..

corfe 05-04-2005 11:08 PM

This is a silly thought, but could some part of the desktop (gnome, perhaps) be installing udev, and udev be screwing you up?

I'm just noticing how the error is it can't find that /dev/md1 file, and udev completely changes the way the kernel handles creating files under /dev.

Any idea if udev is installed on your system?

mrog 05-06-2005 07:32 AM

Thanks Corfe:

I simulated an install of gnome and udev was one of the packages that would be installed. And, the issues concerning udev and my issues match so it's likely the one piece of the puzzle that was missing. It also explains why md* devices were not in the /dev folder even though the needed kernel modules were included in the boot image.

Thanks again. I now have something to work with.


All times are GMT -5. The time now is 02:03 PM.