On Thu, 2006-04-06 at 09:21 -0400, Debbie Deutsch wrote: > Terry Kemp wrote: > > On Wed, 2006-04-05 at 20:15 -0400, Debbie Deutsch wrote: > > [SNIP] > > >> In any case, here is what my /etc/fstab file says. (Note that I have > >> adjusted the white spaces to help with readability.) > >> > >> /dev/VolGroup00/LogVol00 / ext3 defaults 1 1 > >> LABEL=/boot /boot ext3 defaults 1 2 > >> devpts /dev/pts devpts gid=5,mode=620 0 0 > >> tmpfs /dev/shm tmpfs defaults 0 0 > >> /dev/VolGroup00/LogVol02 /home ext3 defaults 1 2 > >> proc /proc proc defaults 0 0 > >> /dev/VolGroup00/LogVol03 /shared ext3 defaults 1 2 > >> sysfs /sys sysfs defaults 0 0 > >> /dev/VolGroup00/LogVol01 swap swap defaults 0 0 > > [SNIP] > > > > > OK our problems are a bit different (but probably attributed to the same > > kernel issue). > > Is this software Raid0? > > Can you post the results of fdisk -l > > The output of fdisk -l is as follows: > > Disk /dev/sda: 320.0 GB, 320072933376 bytes > 255 heads, 63 sectors/track, 38913 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > > Device Boot Start End Blocks Id System > /dev/sda1 * 1 13 104391 83 Linux > /dev/sda2 14 77826 625032922+ 8e Linux LVM > > Disk /dev/sdb: 320.0 GB, 320072933376 bytes > 255 heads, 63 sectors/track, 38913 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > > After providing the above results, fdisk complains that "Disk /dev/sdb > doesn't contain a valid partition table". That's not surprising. > /dev/sda and /dev/sdb are the two hard drives that together comprise my > system's RAID array. It's RAID 0. Although I have never before delved > into how partition information is written to hard drives in a RAID 0 > array, it seems logical that it would go on the first drive and not be > duplicated on the other(s). > > Just for fun, I also ran fdisk -l on the the RAID device itself > (/dev/mapper/nvidia_ehbjhcdb). Here is its output. This time there was > no error message. > > Disk /dev/mapper/nvidia_ehbjhcdb: 640.1 GB, 640145864704 bytes > 255 heads, 63 sectors/track, 77826 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > > Device Boot Start End Blocks Id System > /dev/mapper/nvidia_ehbjhcdb1 * 1 13 104391 83 Linux > /dev/mapper/nvidia_ehbjhcdb2 14 77826 625032922+ 8e Linux LVM > > This looks fine to me, but as I have mentioned before, I am not an > expert when it comes to how Linux structures and stores partition > information. > > Once again, thanks for your help. It's very much appreciated. > > Debbie Sorry for the delay is responding... digest mode and crashed Winblows server (raid problem hehe) With LVM on Raid0 you have got a hard one to resolve! I do remember having some problems with the device mapper on 2.6.15-1.2054_FC5. On 2.6.16-1.2080_FC5 there is no /dev/mapper/nvidiaxxxxxx but if I reboot into the install 2054 kernel I see /dev/mapper/nvidia_abaaggda. I am sure this is where the problem is but whether its the kernel or dmraid I never found out. Having raid1 I was able to boot off 1 of the raid disks and ended up backing out of raid all together. I did have a raid0 swap partition and that would definitely not come up with the new kernel (or even a vanilla kernel I built). In my search for answers I stumbled across this... http://www.fedoraforum.org/forum/archive/index.php/t-96108.html maybe it will help. Terry
