Bug 140974

Can you get to disk druid in the FC3 installer and then switch to tty2
and grab /tmp/anaconda.log and /tmp/syslog and attach them to this bug?

Created attachment 107558 [details]
anaconda.log after disk druid has run on installation

Created attachment 107559 [details]
syslog after disk druid has run on install

Here are the logs from the install session after disk druid has run.

- Pasi -

It looks like the raids aren't starting up in full form and instead
are only in degraded mode.  Are all of the RAID partitions properly
marked as the raid autostart type (0xfd)?

Yes they are and as said, works perfectly with FC2 install and with
FC2 system.

root@ameeba 7:00 [~] # fdisk -l /dev/sda
 
Disk /dev/sda: 163.9 GB, 163928604672 bytes
255 heads, 63 sectors/track, 19929 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1          16      128488+  fd  Linux raid
autodetect
/dev/sda2   *          17        1321    10482412+   7  HPFS/NTFS
/dev/sda3            1322        1974     5245222+  fd  Linux raid
autodetect
/dev/sda4            1975       19929   144223537+   f  W95 Ext'd (LBA)
/dev/sda5            1975        2039      522081   82  Linux swap
/dev/sda6            2040       19929   143701393+  fd  Linux raid
autodetect
root@ameeba 7:00 [~] # fdisk -l /dev/sdb
 
Disk /dev/sdb: 163.9 GB, 163928604672 bytes
255 heads, 63 sectors/track, 19929 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          16      128488+  fd  Linux raid
autodetect
/dev/sdb2              17        1321    10482412+   c  W95 FAT32 (LBA)
/dev/sdb3            1322        1974     5245222+  fd  Linux raid
autodetect
/dev/sdb4            1975       19929   144223537+   f  W95 Ext'd (LBA)
/dev/sdb5            1975        2039      522081   82  Linux swap
/dev/sdb6            2040       19929   143701393+  fd  Linux raid
autodetect

Can you switch to tty2 in the installer and try to run

raidstart /dev/md0
raidstart /dev/md1
raidstart /dev/md2

and see if there are any errors given?

Nothing prints to tty2.

Syslog shows:
<4>program raidstart is using a deprecated SCSI ioctl, please convert
it to SG_IO
<4>program raidstart is using a deprecated SCSI ioctl, please convert
it to SG_IO
<3>md: could not open unknown-block(33,3).
<3>md: could not open unknown-block(34,3).
<6>md: autorun ...
<6>md: considering sda3 ...
<6>md:  adding sda3 ...
<6>md: created md1
<6>md: bind<sda3>
<6>md: running: <sda3>
<4>md1: setting max_sectors to 512, segment boundary to 131071
<4>raid0: looking at sda3
<4>raid0:   comparing sda3(5244928) with sda3(5244928)
<4>raid0:   END
<4>raid0:   ==> UNIQUE
<4>raid0: 1 zones
<4>raid0: FINAL 1 zones
<4>raid0: too few disks (1 of 2) - aborting!
<3>md: pers->run() failed ...
<4>md :do_md_run() returned -22
<6>md: md1 stopped.
<6>md: unbind<sda3>
<6>md: export_rdev(sda3)
<6>md: ... autorun DONE.


I dropped FC3 kernel into FC2 (2.6.9-1.667) and everything works fine.

Running raidstart /dev/md2 on running FC2 system gives:
Dec  1 21:46:53 ameeba kernel: md: raidstart(pid 4854) used deprecated
START_ARRAY ioctl. This will not be supported beyond 2.6
Dec  1 21:46:53 ameeba kernel: md: could not open unknown-block(33,6).
Dec  1 21:46:53 ameeba kernel: md: autostart failed!

Major (33) minor (6) is 
brw-rw----   1 root disk    33,   6 Feb 23  2004 /dev/hde6
This is a disk on IDE ATA interface and not part of any RAID sets???

The disks on RAID are
brw-rw----  1 root disk 8,  0 Feb 23  2004 /dev/sda
brw-rw----  1 root disk 8, 16 Feb 23  2004 /dev/sdb

What is the current status of this bug? Are all RAID-1 partitions created in FC2 going
to be unrecognized by anaconda in FC3? I have a machine which I was going to upgrade
from FC2 to FC3 and this would be a show stopper. If so hopefully it could be addressed
in FC4.

I have not heard a work since Dec 1st.

Tossed the whole FC2 and made clean install for FC3...

- Pasi -

I have the same problem.         
I have old raid0 partitions created by fc2 and new ones          
created by disk druid from a previously failed install  
of fc3. In both cases they are on hda and hdc.   
After restarting an install I see in tty2 that /dev/hdc         
(and partitions) have major 22, when mdadm -E /dev/hdc8          
(my old raid) reports            
      Number   Major   Minor   RaidDevice State  
this     1      33        8        1      active sync    
   0     0       3        8        0      active sync   /dev/hda8    
   1     1      33        8        1      active sync    
For hdc7 (the new raid) I get the same with 22 instead   
of 33.   
  
This mix match of major numbers may explain the funky   
stuff in dmesg when trying to assemble the array:  
md: anaconda(pid 371) used deprecated START_ARRAY ioctl. This will not be  
supported beyond 2.6  
md: could not open unknown-block(33,8).  
  
It doesn't find the disk because it's looking for   
major 33 instead of 22 and so fails to assemble the  
array. I think it should ignore all the major/minor  
stuff and try to match the uuid of software raid  
partitions.  
I'm still looking for a workaround, but haven't had  
any luck so far. I can't loose the data on that old   
raid and should have listened when they said to make  
backups :(  
Tobias.  
 

Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

Closing per lack of response to previous request for information.
This bug was originally filed against a much earlier version of Fedora
Core, and significant changes have taken place since the last version
for which this bug is confirmed.

Note that FC3 and FC4 are supported by Fedora Legacy for security
fixes only.  Please install a still supported version and retest.  If
it still occurs on FC5 or FC6, please reopen and assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.