Bug 140974 - FC3 install fails to recognize FC2 RAID devices
FC3 install fails to recognize FC2 RAID devices
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
3
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-27 03:32 EST by Pasi Sainio
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-31 15:32:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
anaconda.log after disk druid has run on installation (6.13 KB, text/plain)
2004-11-29 12:58 EST, Pasi Sainio
no flags Details
syslog after disk druid has run on install (24.14 KB, text/plain)
2004-11-29 13:00 EST, Pasi Sainio
no flags Details

  None (edit)
Description Pasi Sainio 2004-11-27 03:32:06 EST
Description of problem: I have an existing working FC2 installation. 
System is installed to two SATA disks as follows

root@ameeba 10:31 [~] # mdadm --detail --query /dev/md0
/dev/md0: 125.25MiB raid1 2 devices, 0 spares. Use mdadm --detail for
more detail.
/dev/md0: No md super block found, not an md component.
root@ameeba 10:31 [~] # mdadm --detail --query /dev/md1
/dev/md1: 10.00GiB raid0 2 devices, 0 spares. Use mdadm --detail for
more detail.
/dev/md1: No md super block found, not an md component.
root@ameeba 10:31 [~] # mdadm --detail --query /dev/md2
/dev/md2: 274.09GiB raid0 2 devices, 0 spares. Use mdadm --detail for
more detail.
/dev/md2: No md super block found, not an md component.
 
root@ameeba 10:31 [~] # df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/md1              10325192   5083656   4717044  52% /
/dev/md0                124195     10408    107375   9% /boot
/dev/md2             282892472 187079428  81442920  70% /data
none                    517552         0    517552   0% /dev/shm

So /boot is mirrored and / is striped.

FC3 installation DVD does not recognize previous installation and md1
and md2 shows as filesystem type foreign in disk druid.  FC2 DVD works
fine


Version-Release number of selected component (if applicable): FC3


How reproducible: Every time


Steps to Reproduce:
1. Just boot from the DVD
Comment 1 Jeremy Katz 2004-11-28 18:44:10 EST
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?
Comment 2 Pasi Sainio 2004-11-29 12:58:49 EST
Created attachment 107558 [details]
anaconda.log after disk druid has run on installation
Comment 3 Pasi Sainio 2004-11-29 13:00:46 EST
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 -
Comment 4 Jeremy Katz 2004-11-30 22:34:46 EST
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)?
Comment 5 Pasi Sainio 2004-12-01 00:01:25 EST
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
Comment 6 Jeremy Katz 2004-12-01 14:19:52 EST
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?
Comment 7 Pasi Sainio 2004-12-01 14:51:06 EST
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
Comment 8 Need Real Name 2005-01-11 22:38:46 EST
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.
Comment 9 Pasi Sainio 2005-01-12 03:06:10 EST
I have not heard a work since Dec 1st.

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

- Pasi -
Comment 10 Tobias Oed 2005-04-19 23:12:19 EDT
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.  
 
Comment 11 Matthew Miller 2006-07-10 17:59:42 EDT
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!
Comment 12 John Thacker 2006-10-31 15:32:56 EST
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.

Note You need to log in before you can comment on or make changes to this bug.