Bug 1052454 - OSError: [Errno 2] No such file or directory: '/dev/md' (anaconda crashes if an existing Linux install lists an mdraid array by /dev node in fstab)
OSError: [Errno 2] No such file or directory: '/dev/md' (anaconda crashes if ...
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: python-blivet (Show other bugs)
x86_64 Linux
unspecified Severity high
: rc
: ---
Assigned To: David Lehman
Release Test Team
Depends On: 980267
  Show dependency treegraph
Reported: 2014-01-13 15:51 EST by David Lehman
Modified: 2014-06-18 00:46 EDT (History)
7 users (show)

See Also:
Fixed In Version: python-blivet-0.18.19-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 980267
Last Closed: 2014-06-13 09:27:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Lehman 2014-01-13 15:51:18 EST
+++ This bug was initially created as a clone of Bug #980267 +++

Description of problem:
Trying to install live DVD or trying to install from installer DVD 19-RC3 (and older)

Version-Release number of selected component:

The following was filed automatically by anaconda:
anaconda 19.30.13-1 exception report
Traceback (most recent call first):
  File "/usr/lib/python2.7/site-packages/blivet/devicelibs/mdraid.py", line 269, in name_from_md_node
    for link in os.listdir(md_dir):
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 2196, in resolveDevice
    md_name = devicelibs.mdraid.name_from_md_node(devspec[5:])
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 2985, in parseFSTab
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 2908, in findExistingInstallations
    (mounts, swaps) = parseFSTab(devicetree, chroot=ROOT_PATH)
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 424, in reset
    self.roots = findExistingInstallations(self.devicetree)
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 144, in storageInitialize
  File "/usr/lib64/python2.7/threading.py", line 764, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 168, in run
    threading.Thread.run(self, *args, **kwargs)
OSError: [Errno 2] No such file or directory: '/dev/md'

Additional info:
cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8
cmdline_file:   BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-Jam-KDE-x86_64-19-1 ro rd.live.image quiet threadirqs rhgb
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.x86_64
other involved packages: python-blivet-0.17-1.fc19.noarch, python-libs-2.7.5-1.fc19.x86_64
product:        Fedora
release:        Fedora release 19 (Schrödinger’s Cat)
type:           anaconda
version:        19

--- Additional comment from matt on 2013-07-09 10:04:01 EDT ---

1) Boot Fedora 19 x86_64 DVD ISO image from USB flash drive.
2) Select "Install Fedora 19" from grub menu
3) At anaconda language selection screen, wait for error to pop up.  Might have to hit tab after a while

Notes: I have 2 md raid arrays that have been in this system for years through various fedora installs and never had a problem.  They seem to get assembled OK, but then anaconda chokes on them for some reason.

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora\x2019\x20x86_64 quiet
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.x86_64
package:        anaconda-19.30.13-1
product:        Fedora
reason:         OSError: [Errno 2] No such file or directory: '/dev/md'
release:        Cannot get release name.
version:        19

--- Additional comment from matt on 2013-07-18 00:44:38 EDT ---

I think my situation is different than the bugs in comment 14.  Note that I'm not trying to do anything fancy here.  Just booting anaconda in a machine that happens to have some existing md arrays in it.  I can't even get to the point where I choose an installation target device; anaconda gives the error before I can even get past the initial language selection screen.

I tried booting with raid=noautodetect added to the kernel command line, but anaconda still assembled the arrays and then got confused.

I do not even want to install to an md array. I just want to install to sda like I've done with the past 10+ Fedora releases.  Is there some way to get anaconda to ignore the arrays?  I really don't want some installer messing with my arrays unless I tell it to, anyway. Is there perhaps a new anaconda img without this bug?

--- Additional comment from Jim Bean on 2013-07-29 19:19:56 EDT ---

(In reply to Jim Bean from comment #16)
> Boot from DVD containing F19 distribution
> cmdline:        /usr/bin/python  /sbin/anaconda
> cmdline_file:   initrd=initrd.img
> inst.stage2=hd:LABEL=Fedora\x2019\x20x86_64 quiet BOOT_IMAGE=vmlinuz 
> hashmarkername: anaconda
> kernel:         3.9.5-301.fc19.x86_64
> package:        anaconda-19.30.13-1
> product:        Fedora
> reason:         OSError: [Errno 2] No such file or directory: '/dev/md'
> release:        Cannot get release name.
> version:        19

My situation is similar to Matt, not installing to a raid array.
I have 2 raid1 arrays with /home of F17 and F18 mounted on them.
--- Additional comment from Chris Hubick on 2013-11-13 17:49:58 EST ---

I was able to work around this by following the advice at https://bugzilla.redhat.com/show_bug.cgi?id=975811#c12 and adding a UUID label instead of /dev/md0 in the /etc/fstab of my existing install.

This is likely a dup of that bug 975811.

--- Additional comment from David Lehman on 2014-01-07 12:41:01 EST ---

This is already fixed for F21 by commit 944ed1ee on blivet's master branch.
Comment 2 Ľuboš Kardoš 2014-02-20 06:31:31 EST
Verified python-blivet-0.18.24-1 (RHEL-7.0-20140214.0).
Comment 3 Ludek Smid 2014-06-13 09:27:18 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

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