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
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.