Red Hat Bugzilla – Bug 134571
anaconda can't see fs on software raid partitions created by FC2
Last modified: 2015-01-04 17:10:19 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10.1 Description of problem: I have several software raid partitions on my system (raid 0), which were created when I installed fedora core 2. When I try to install fedora core3 test 2, firstly it cannot find my existing core 2 install, on the software raid, and when I use disk driud, the arrays are listed, but their filesystems are listed as foreign, rather than ext3. The install cannot proceed past this point. The core3 test 2 disk cannot mount the partitions in rescue mode, whereas the core 2 disk can, and when I try to install fedora core 2 it can see and correctly identifies the software raid partitions. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.run fedora core 3 test2 installation 2.use disk driud 3.partitions not recognised Actual Results: the partition filesystems were listed as foreign rather than ext3 Expected Results: To have the software raid listed as ext3 and being able to install/upgrade to them Additional info: I reinstalled fedora core two recreating the / partition, and them immediatley ran the fedora core3 test2 install, but the same results were encountered. I also tried running a full fsck on all the partitions, but that had no effect. One of the partitions is raid 1, and it does see that correctly, but if I try and reformat the / partition, it says it cannot mount the /home partition.
What sort of error messages do you get in rescue mode if you try mounting them by hand?
trying to mount any one of the raid 0 arrays gives this error: #mount /dev/md1 /mnt/mountpoint EXT2-fs: unable to read superblock isofs_fill_super: bread failed, dev=md1, iso_blknum=16, block=32 cramfs: wrong magic FAT: unable to read boot sector FAT: unable to read boot sector EXT3-fs: unable to read superblock ReiserFS: md1: warning: sh-2006: read_super_block: bread failed (dev md1, block 16, size 2096) ReiserFS: md1: warning: sh-2006: read_super_block: bread failed (dev md1, block 16, size 2096) ReiserFS: md1: warning: sh-2021: reiser_fill_super: can not find reiserfs on md1 XFS: SB read failed mount: mounting /dev/md1 on /mnt/mountpoint failed: Input/output error
When the mount is tried, if you switch to tty4, are there read errors?
in tty4 when trying to mount the raid 0 partitions, they give out only the error in comment #2. when trying to mount the raid 1 partition it gives out a large error message (which >& doesn't capture) and it then segfaults.
You should be able to grab /tmp/syslog to get anything output to tty4.
Created attachment 104805 [details] syslog from tty4 from mounting two devices
Created attachment 104807 [details] full syslog from tty4 full and unabridged original
Bug still occurs in Fedora Core 3 test 3. Also occurs in another machine, with two raid 0 partitions created by fedora core 2. Exact same error message as in comment #2.
This bug still occurs in core 3 preview realease 1, with exactly the same error messages. Is there any further information that I could provide that would help with solving this bug? I know it occurs on two machines, a pentium 4 and an AMD XP, both where the software raid was set up manually.
Bug also occurs in Fedora Core 3 release.
errata was released for these 2004-383 etc
um, sorry, closed wrong bug due to typo in bug id :(
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
This bug has been automatically closed as part of a mass update. It had been in NEEDINFO state since July 2005. If this bug still exists in current errata kernels, please reopen this bug. There are a large number of inactive bugs in the database, and this is the only way to purge them. Thank you.