+++ This bug was initially created as a clone of Bug #955202 +++ Description of problem: Installation to an image file fails at the end of the installation with following traceback: Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1544, in install raise BootLoaderError("bootloader install failed") File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1558, in write self.install() File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2249, in writeBootLoader storage.bootloader.write() File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 141, in doInstall writeBootLoader(storage, payload, instClass, ksdata) File "/usr/lib64/python2.7/threading.py", line 763, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 141, in run threading.Thread.run(self, *args, **kwargs) BootLoaderError: bootloader install failed From storage.log: ... 10:21:28,989 INFO program: Running... grub2-install --no-floppy /dev/mapper/file 10:21:30,106 INFO program: device-mapper: table ioctl on failed: No such device or address 10:21:30,107 INFO program: device-mapper: table ioctl on failed: No such device or address ... (repeats 46 times) 10:21:30,120 INFO program: device-mapper: table ioctl on failed: No such device or address 10:21:30,120 INFO program: device-mapper: table ioctl on failed: No such device or address 10:21:30,121 INFO program: /usr/sbin/grub2-probe: error: cannot find a GRUB drive for /dev/mapper/file. Check your device.map. 10:21:30,121 DEBUG program: Return code: 1 Version-Release number of selected component (if applicable): anaconda-19.20-2.el7 How reproducible: always Steps to Reproduce: 1. yum install anaconda 2. dd if=/dev/zero of=/root/file.img bs=1 count=1 seek=10G 3. anaconda --graphical --image=/root/file.img --repo=<REPO_PATH> 4. proceed through the installation, select "Standard Partition" scheme, let anaconda to create partitioning Actual results: traceback at the end of the installation Expected results: successful installation Additional info: --- Additional comment from David Lehman on 2013-09-26 11:48:09 EDT --- I have a fix for this bug, but it only revealed another problem down the line. Dracut resolves device specifications from /etc/fstab at image creation time and creates systemd unit files to wait for the existence of device files used for /, /boot, and swap. The problem is that the disk name at installation time is different from the disk name in the actual system, and the names of the systemd unit files are based on these names. In your reproducer, the image file was named "file". You would end up with a systemd unit file named "devexists-dev-mapper-file1", which would wait until the device node "/dev/mapper/file1" exists. This, of course, will never happen since the disk image is now seen as an actual disk and therefore the /boot partition is more like "/dev/vda1" or "/dev/sda1".
This bug has three pieces: 1. x86 bootloader install to disk image file is broken 2. s390 disk image install is broken because of bootloader-related crash 3. initramfs creation for disk image installs needs special parameters Patches exist (and have passed review) for all three problems. I'd like to get them into f20 so disk image installations are usable there.
Making this bug public so it can be discussed as a blocker for Fedora 20 final. David, I can't see any reason to keep the description private but maybe there's something I'm missing. Can you either make it not private or create a new bug?
I didn't intentionally make any of it private -- it just inherited that and I didn't notice. Fixed now -- thanks.
I don't think installing to an image file directly is in the Fedora criteria, but +1 FE at least.
Discussed at 2013-11-13 blocker review meeting - http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-13/f20-final-blocker-review-1.2013-11-13-17.01.log.txt . So far as we're aware this bug does not violate any release criteria and hence does not need to block release.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora 'version' of '20'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 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 change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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.