Bug 697238

Summary: Exception: device-mapper: reload ioctl failed: No such device or address
Product: [Fedora] Fedora Reporter: Dmitry S. Makovey <dmitry>
Component: python-pyblockAssignee: Peter Jones <pjones>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 15CC: anaconda-maint-list, dlehman, hdegoede, joel.granados, jonathan, pjones, vanmeeuwen+fedora, wayne
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: anaconda_trace_hash:f5007fdfe582c07c0cb63ab97606b39b8d2fed617cc4993eba5b3c3195170f5c
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-07 18:03:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Attached traceback automatically from anaconda.
none
udevdb dump
none
dmtree dump
none
/var/log/messages
none
dmraid dump
none
dmraid dump from F15
none
Attached traceback automatically from anaconda. none

Description Dmitry S. Makovey 2011-04-17 04:45:53 UTC
The following was filed automatically by anaconda:
anaconda 15.20.1 exception report
Traceback (most recent call first):
  File "/usr/lib64/python2.7/site-packages/block/__init__.py", line 33, in dm_log
    raise Exception, message
  File "/usr/lib64/python2.7/site-packages/block/device.py", line 710, in get_map
    self._RaidSet__map = _dm.map(name=self.name, table=self.rs.dmTable)
  File "/usr/lib64/python2.7/site-packages/block/device.py", line 828, in activate
    self.map.dev.mknod(self.prefix+self.name)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 1406, in handleUdevDMRaidMemberFormat
    rs.activate(mknod=True)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 1534, in handleUdevDeviceFormat
    self.handleUdevDMRaidMemberFormat(info, device)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 997, in addUdevDevice
    self.handleUdevDeviceFormat(info, device)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 1750, in _populate
    self.addUdevDevice(dev)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 1708, in populate
    self._populate()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 434, in reset
    self.devicetree.populate()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 103, in storageInitialize
    storage.reset()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 211, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 130, in gotoNext
    self.moveStep()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1346, in setScreen
    self.anaconda.dispatch.gotoNext()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1258, in nextClicked
    self.setScreen ()
Exception: device-mapper: reload ioctl failed: No such device or address

Comment 1 Dmitry S. Makovey 2011-04-17 04:45:58 UTC
Created attachment 492660 [details]
Attached traceback automatically from anaconda.

Comment 2 Dmitry S. Makovey 2011-04-17 04:53:39 UTC
this is the result of trying to install via LiveCD (actually USB) KDE spin of F15 alpha.

Machine has 4 disks, two of which are partitioned and combined into RAID1 groups with LVM partitioning on top of it. 

something like:

sda1+sdc1 = md1
sda2+sdc2 = md2
sda3+sdc3 = md3
sda6+sdc6 = md4

pvcreate /dev/md4
vgcreate rgv /dev/md4

etc.

/boot = md1

all above was done long time ago using Gentoo linux so can't even say which versions were used at the time.

here's the version as media reports it:

$ rpm -q fedora-release
fedora-release-15-0.7.noarch

Comment 3 Brian Lane 2011-04-21 21:44:51 UTC
Is there a /tmp/syslog and or /var/log/syslog file? It seems to be missing from the traceback.

Comment 4 David Lehman 2011-04-25 14:59:15 UTC
Please run the following commands:

  udevadm info --export-db > /tmp/udevdb

  dmsetup ls --tree > /tmp/dmtree

and attach the files /tmp/udevdb and /tmp/dmtree to this report, along with /var/log/messages. Thanks.

Comment 5 Dmitry S. Makovey 2011-04-26 22:57:46 UTC
Created attachment 495062 [details]
udevdb dump

Comment 6 Dmitry S. Makovey 2011-04-26 22:58:21 UTC
Created attachment 495063 [details]
dmtree dump

Comment 7 Dmitry S. Makovey 2011-04-26 23:01:08 UTC
Created attachment 495064 [details]
/var/log/messages

Comment 8 Dmitry S. Makovey 2011-04-26 23:03:46 UTC
udevdb and dmtree dumps generated from LiveCD (USB stick) prior to launching installer while /var/log/messages is a copy from a system just after installer failed.

Let me know if there's anything else I can help with.

Comment 9 David Lehman 2011-04-27 15:39:10 UTC
Thanks for the information. I'll need some more if you can get it. Please run these commands and then attach /tmp/dmraid to this bug report:

  dmraid -s > /tmp/dmraid
  echo >> /tmp/dmraid
  dmraid -r >> /tmp/dmraid
  echo >> /tmp/dmraid
  dmraid -b >> /tmp/dmraid

Comment 10 Dmitry S. Makovey 2011-04-28 04:10:59 UTC
Created attachment 495388 [details]
dmraid dump

done from under Gentoo rather than live F15 media. 

Last attempt at using F15 media resulted in renumbered MD-RAID devices and unbootable system.

Comment 11 David Lehman 2011-05-03 15:03:52 UTC
When pyblock is trying to activate the nvidia raid set this traceback happens.

Seeing what gentoo's dmraid thinks is there is only slightly useful. What I want to see is if your biosraid is usable by the dmraid in F15.

Comment 12 David Lehman 2011-05-03 15:11:53 UTC
I think something is wrong with your raid set (nvidia_fcbfdhgc). The livecd will activate any biosraid sets it finds during bootup. The fact that your set is not activated indicates it is not usable by F15 dmraid.

Comment 13 Dmitry S. Makovey 2011-05-05 05:00:03 UTC
Created attachment 496971 [details]
dmraid dump from F15

as per request - dmraid output from F15 liveCD

Comment 14 Dmitry S. Makovey 2011-05-05 05:06:06 UTC
(In reply to comment #12)
> I think something is wrong with your raid set (nvidia_fcbfdhgc). The livecd
> will activate any biosraid sets it finds during bootup. The fact that your set
> is not activated indicates it is not usable by F15 dmraid.

NVidia RAID is disabled in BIOS - there is NO hardware (or "emulation") RAID sets set up - the only ones are MD (software raid) sets.

Comment 15 David Lehman 2011-05-05 16:53:24 UTC
Here is the output from dmraid:

*** Set
name   : nvidia_fcbfdhgc
size   : 625142400
stride : 128
type   : mirror
status : ok
subsets: 0
devs   : 2
spares : 0

/dev/sdc: nvidia, "nvidia_fcbfdhgc", mirror, ok, 625142446 sectors, data@ 0
/dev/sdd: nvidia, "nvidia_fcbfdhgc", mirror, ok, 625142446 sectors, data@ 0


So your firmware RAID is still a RAID array, whether or not you've told the firmware to enable it.

You have two options:

  1. pass the option "nodmraid" when booting the installer/livecd
  2. use wipefs to remove the old RAID signatures from the disks

2 is the better option since as of now your disks have spurious metadata on them, but 1 should get you an OS installed if 2 makes you uncomfortable.

Comment 16 Dmitry S. Makovey 2011-05-09 04:33:08 UTC
thanks, nodmraid did help in the end. Not very eager to try #2 just yet - first I'd rather have my backups done. 

However why is it that in BIOS RAID is disabled yet F15 is trying to pick it up (while Gentoo doesn't)? Doesn't it mean that there needs to be an extra check before making assumptions about BIOS RAID settings?

Comment 17 Wayne Boyd 2011-05-28 14:45:00 UTC
Created attachment 501482 [details]
Attached traceback automatically from anaconda.

Comment 18 Wayne Boyd 2011-05-28 14:52:02 UTC
Comment on attachment 501482 [details]
Attached traceback automatically from anaconda.

I have a firmware RAID using two 1 terabyte drives, and a third 400gig drive where I will install the MBR and boot from. This bug comes up every time and will not allow me to install Fedora 15 because of it, although I could install Fedora 14. When the installer asks "What type of devices will your installation involve?" it makes no difference whether I select "Basic Storage Devices" or "Specialized Storage Devices". In both cases I am brought eventually to the "Examining Storage Devices" dialogue, which results in this crash, halting the install.

Comment 19 Wayne Boyd 2011-05-28 14:54:09 UTC
"An unhandled exception has occurred. This is most likely a bug. Please save a copy of the detailed exception and file a bug report."

Comment 20 David Lehman 2011-05-31 14:45:22 UTC
(In reply to comment #18)
> Comment on attachment 501482 [details]
> Attached traceback automatically from anaconda.
> 
> I have a firmware RAID using two 1 terabyte drives, and a third 400gig drive
> where I will install the MBR and boot from. This bug comes up every time and
> will not allow me to install Fedora 15 because of it, although I could install
> Fedora 14. When the installer asks "What type of devices will your installation
> involve?" it makes no difference whether I select "Basic Storage Devices" or
> "Specialized Storage Devices". In both cases I am brought eventually to the
> "Examining Storage Devices" dialogue, which results in this crash, halting the
> install.

If you can do the installation using only the non-raid disk you can choose to completely ignore the raid disks, which should work around the problem. If you need to use the raid set for your install, someone other than me will have to figure out what exactly is happening to cause the crash.

Comment 21 Fedora End Of Life 2012-08-07 18:03:22 UTC
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached 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" (top right of this page) 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