| Summary: | Fakeraid issue | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Alexander Rozenson <ticahek> |
| Component: | dmraid | Assignee: | Heinz Mauelshagen <heinzm> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | agk, bmr, dwysocha, heinzm, lvm-team, prockai, ticahek, zkabelac |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-02-13 14:31:42 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Sorry, I mean I'm not professional enough to configure it from scratch, I'm afraid it can take weeks to me. I can confirm the same behavior with a fresh installation of Fedora 16 on a Supermicro X7DWN+-O motherboard (http://www.supermicro.com/products/motherboard/Xeon1333/5400/X7DWN_.cfm) with Adaptec HostRAID ESB2. I configured two disks as RAID-1 in the Adaptec BIOS and installed Fedora 16 on it (turning off LVM). With a "web server" installation, I had a similar output of "df". No mount points were duplicated but some were on /dev/sda and others on /dev/sdb. I also tried an installation that included the updates repo. The newer package versions did not make a difference. As Alexander wrote, everything looked correct after a minimal installation. All partitions were on /dev/mapper. "dmraid -d -ay" indicated that the RAID set was already activated. I listed all the package names on another system and installed them via "yum install" on the new system. Everything still looked good after rebooting the system with a normal set of packages. However, I gave up on this configuration because it turned out to be insufficiently fail-safe against the removal of one of the disks. After I removed the disk, there was a message on the console indicating that the mirror would be tried. The system worked for a few more minutes before hanging completely. It rebooted without problems with just the remaining disk, though. I won't be able to conduct any additional tests because I need to set up the system and I can't rely on its fake RAID. I'll probably use a hardware RAID card. Exactly the same story with Fedora 17 :-( This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |
Description of problem: Hello Fedora gurus, After upgrade(fresh installation) from Fedora 14 to 16, my FakeRaid(Adaptec 1430) is not used anymore. Of course I used the "special storage=>BIOS Raid" option during the installation. ================================================= Version-Release number of selected component (if applicable): dmraid-1.0.0.rc16-15.fc15.x86_64 device-mapper-1.02.65-5.fc16.x86_64 kernel-3.1.0-7.fc16.x86_64 ================================================= Debug: After booting the system I notice the following: $ df | grep -E 'dev/sd' <<< Funny >>> /dev/sda3 20642428 3317640 16276212 17% / /dev/sdb1 495844 35192 435052 8% /boot /dev/sda1 495844 35192 435052 8% /boot In normal case it should be /dev/mapper/... ================================================= grub.cfg: menuentry 'Fedora Linux, with Linux 3.1.0-7.fc16.x86_64' --class fedora --class gnu-linux --class gnu --class os { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='(hd0,msdos1)' search --no-floppy --fs-uuid --set=root 7e28cf7d-4da3-4e1a-80ef-47385730647e echo 'Loading Linux 3.1.0-7.fc16.x86_64 ...' linux /vmlinuz-3.1.0-7.fc16.x86_64 root=UUID=3c160a11-9612-41fd-8492-5dac7a4c7b34 ro rd.dm.uuid=ddf1_MASTERLI rd.md=0 rd.lvm=0 LANG=en_US.UTF-8 KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 echo 'Loading initial ramdisk ...' initrd /initramfs-3.1.0-7.fc16.x86_64.img } ================================================= $ dmesg | grep dm Nothing interesting... ================================================= $ dmesg | grep ddf [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.1.0-7.fc16.x86_64 root=UUID=3c160a11-9612-41fd-8492-5dac7a4c7b34 ro rd.dm.uuid=ddf1_MASTERLI rd.md=0 rd.lvm=0 LANG=en_US.UTF-8 KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.1.0-7.fc16.x86_64 root=UUID=3c160a11-9612-41fd-8492-5dac7a4c7b34 ro rd.dm.uuid=ddf1_MASTERLI rd.md=0 rd.lvm=0 LANG=en_US.UTF-8 KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 [ 13.196392] fedora-storage-init[880]: failed to stat() /dev/mapper/ddf1_MASTERLI [ 13.431666] fedora-storage-init[901]: failed to stat() /dev/mapper/ddf1_MASTERLI ================================================= Checking dmraid for ddf1 support # dmraid -l | grep ddf1 ddf1 : SNIA DDF1 (0,1,4,5,linear) ================================================= # dmraid -s *** Group superset .ddf1_disks --> Subset name : ddf1_MASTERLI size : 1953253376 stride : 128 type : mirror status : ok subsets: 0 devs : 2 spares : 0 ================================================= # dmraid -r /dev/sdb: ddf1, ".ddf1_disks", GROUP, ok, 1953253376 sectors, data@ 0 /dev/sda: ddf1, ".ddf1_disks", GROUP, ok, 1953253376 sectors, data@ 0 ================================================= Trying to activate and reensure dm-mirror is on # modprobe -v dm-mirror ; dmraid -d -ay DEBUG: _find_set: searching .ddf1_disks DEBUG: _find_set: not found .ddf1_disks DEBUG: _find_set: searching ddf1_MASTERLI DEBUG: _find_set: searching ddf1_MASTERLI DEBUG: _find_set: not found ddf1_MASTERLI DEBUG: _find_set: not found ddf1_MASTERLI DEBUG: _find_set: searching .ddf1_disks DEBUG: _find_set: found .ddf1_disks DEBUG: _find_set: searching ddf1_MASTERLI DEBUG: _find_set: searching ddf1_MASTERLI DEBUG: _find_set: found ddf1_MASTERLI DEBUG: _find_set: found ddf1_MASTERLI DEBUG: checking ddf1 device "/dev/sda" DEBUG: checking ddf1 device "/dev/sdb" DEBUG: set status of set "ddf1_MASTERLI" to 16 DEBUG: set status of set ".ddf1_disks" to 16 RAID set "ddf1_MASTERLI" was not activated RAID set "ddf1_MASTERLI" was not activated DEBUG: freeing devices of RAID set "ddf1_MASTERLI" DEBUG: freeing device "ddf1_MASTERLI", path "/dev/sda" DEBUG: freeing device "ddf1_MASTERLI", path "/dev/sdb" DEBUG: freeing devices of RAID set ".ddf1_disks" DEBUG: freeing device ".ddf1_disks", path "/dev/sdb" DEBUG: freeing device ".ddf1_disks", path "/dev/sda" ================================================= # tail -5 /var/log/messages Dec 18 01:31:42 localhost kernel: [ 1992.716342] device-mapper: table: 253:0: mirror: Device lookup failure Dec 18 01:31:42 localhost kernel: [ 1992.716347] device-mapper: ioctl: error adding target to table Dec 18 01:31:42 localhost kernel: [ 1992.720038] device-mapper: table: 253:0: mirror: Device lookup failure Dec 18 01:31:42 localhost kernel: [ 1992.720044] device-mapper: ioctl: error adding target to table Dec 18 01:31:42 localhost udevd[1724]: setfilecon /dev/dm-0 failed: No such file or directory ================================================= BTW this problem disappears when I choose "minimal" Installation but I dont really have the time to configure everything almost from scratch so it isnt good solution for me. Will appreciate your help here. Thanks ahead