Red Hat Bugzilla – Bug 980267
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)
Last modified: 2016-07-19 14:58:15 EDT
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: anaconda-19.30.13-1.fc19.x86_64 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 options=options) 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 storage.reset() 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
Created attachment 767552 [details] File: anaconda.log
Created attachment 767553 [details] File: environ
Created attachment 767554 [details] File: lsblk_output
Created attachment 767555 [details] File: messages
Created attachment 767556 [details] File: nmcli_dev_list
Created attachment 767557 [details] File: os_info
Created attachment 767558 [details] File: program.log
Created attachment 767559 [details] File: storage.log
Created attachment 767560 [details] File: ifcfg.log
Created attachment 767561 [details] File: anaconda-tb
I am having the same problem. Is there perhaps a way to have anaconda ignore my md arrays altogether? I do not want to install onto them anyway.
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
Sorry, my logs didn't seem to get attached. Perhaps because it's a dupe? FWIW I've successfully installed to several other servers -- that don't have any md arrays in them -- from the very same USB key.
I'm seeing this as well. Search also turned up Bug 965299, and possibly also Bug 972546 and Bug 886314.
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?
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
(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. This is the setup: SDB1 F17 /boot SDB2 SDA2 /dev/md127 F17 /home SDB3 SDA5 /dev/md1 F18 /home SDB5 F18 /boot SDB6 F18 / SDB7 F17 / I hope to install F19 over F17 Jim
(In reply to Jim Bean from comment #17) > (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. > This is the setup: > SDB1 F17 /boot > SDB2 SDA2 /dev/md127 F17 /home > SDB3 SDA5 /dev/md1 F18 /home > SDB5 F18 /boot > SDB6 F18 / > SDB7 F17 / > > I hope to install F19 over F17 > Jim I was able to update F18 to F19 using fedup and the disk setup above. So fedup does not choke on the raid partitions. This isn't what I wanted to do but is a temporary solution.
running installer from livecd for Fedora Core 19 Click install, Welcome To Fedora 19 screen comes up, wait about 20 seconds. Error message occurs. And looking at the traceback I see now it's blowing up on mdraid, I do have a software raid array that is managed by mdadm. cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8 cmdline_file: initrd=initrd0.img root=live:CDLABEL=LIVE rootfstype=vfat rw rd.live.image rd.live.overlay=LABEL=LIVE quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 BOOT_IMAGE=vmlinuz0 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 package: anaconda-19.30.13-1.fc19.x86_64 packaging.log: product: Fedora reason: OSError: [Errno 2] No such file or directory: '/dev/md' release: Fedora release 19 (Schrödinger’s Cat) version: 19
Going to try disabling the array in the BIOS then install. hopefully shouldn't choke will add manually later.
Didn't work, I ended up nuking the contents of the drive prior to reinstall. After reinstall array is picked up just fine.
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.
(In reply to Chris Hubick from comment #22) > 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. This is good info and useful if the install is to the raid array. In my case, and Matt above, the raid arrays are merely lurking and not meant to take part in the install. The installer should not choke on this. It appears the designers strategy is to check all devices and choke if any of them are unsuitable. It should mark unsuitable media and then decide if the install can proceed on what remains.
For anyone still trying to get past this to install F19, you can apply a possible fix by putting this on the boot/kernel command line: inst.updates=http://dlehman.fedorapeople.org/updates/updates-980267.0.img Please let me know your results if you try it. Thanks in advance.
The crash here does seem like a big problem, especially if you weren't intending to involve the problematic array in the Fedora install at all - it really shouldn't be such a roadblock. Setting severity high. Be great if we could fix this for F21, but it'd help the devs if someone could test the updates image dlehman posted for F19. dlehman, any chance of an updates.img against F20 too?
*** Bug 975811 has been marked as a duplicate of this bug. ***
*** Bug 1045686 has been marked as a duplicate of this bug. ***
This is already fixed for F21 by commit 944ed1ee on blivet's master branch.
(In reply to David Lehman from comment #24) > inst.updates=http://dlehman.fedorapeople.org/updates/updates-980267.0.img > Please let me know your results if you try it. Thanks in advance. Hi David, even though F20 has been out a while, I just tried F19 again using your fix, and it succeeded. I did see some of the same error messages regarding /dev/md not existing, but the installer did not barf, and I was able to perform an installation. Thanks. I will try F20 now, but i guess it will have the same problem as F19 originally did?
Followup to my previous comment: F20 installed fine for me, and I'm guessing it's because doing F19 first blew away my old /etc/fstab which (I now see) was probably the trigger for the whole problem in the first place, as Chris mentioned above is apparently covered by bug 975811. (I had indeed had my arrays listed as /dev/md0 and /dev/md1 in my old fstab, which triggered the bug.) Thanks all!
Automatic disk probing by anaconda after language selection caused the crash cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base cmdline_file: initrd=initrd0.img root=live:CDLABEL=Fedora-Live-Desktop-x86_64-20-1 rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 BOOT_IMAGE=vmlinuz0 hashmarkername: anaconda kernel: 3.11.10-301.fc20.x86_64 other involved packages: python-blivet-0.23.9-1.fc20.noarch, python-libs-2.7.5-9.fc20.x86_64 package: anaconda-20.25.15-1.fc20.x86_64 packaging.log: product: Fedora reason: OSError: [Errno 2] No such file or directory: '/dev/md' release: Fedora release 20 (Heisenbug) version: 20
Failed on a Gigabyte Haswell Motherboard cmdline: /usr/bin/python /sbin/anaconda cmdline_file: initrd=initrd.img inst.stage2=hd:UUID=000ed670-5c30-459e-bb07-594f805f3746 rd.live.check quiet BOOT_IMAGE=vmlinuz hashmarkername: anaconda kernel: 3.11.10-301.fc20.x86_64 package: anaconda-20.25.15-1 packaging.log: product: Fedora reason: OSError: [Errno 2] No such file or directory: '/dev/md' release: Cannot get release name. version: 20
i just start installation / this problem occurs since Fedora 14 (15,16,17,18,19,20). I can install Fedora via disconnecting my raid1 devices from system phisicaly cmdline: /usr/bin/python /sbin/anaconda cmdline_file: initrd=initrd.img inst.stage2=hd:LABEL=RFRemix\x2020\x20x86_64 quiet BOOT_IMAGE=vmlinuz hashmarkername: anaconda kernel: 3.11.10-301.fc20.x86_64 package: anaconda-20.25.15-1 packaging.log: product: Fedora reason: OSError: [Errno 2] Нет такого файла или каталога: '/dev/md' release: Fedora release 20 (Heisenbug) version: 20
(In reply to Anton from comment #33) > i just start installation / > this problem occurs since Fedora 14 (15,16,17,18,19,20). > I can install Fedora via disconnecting my raid1 devices from system phisicaly > > cmdline: /usr/bin/python /sbin/anaconda > cmdline_file: initrd=initrd.img > inst.stage2=hd:LABEL=RFRemix\x2020\x20x86_64 quiet BOOT_IMAGE=vmlinuz > hashmarkername: anaconda > kernel: 3.11.10-301.fc20.x86_64 > package: anaconda-20.25.15-1 Please retry with F21. See comment 28
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.