Description of problem: This happend on F20 Alpha RC2 DVD during Anaconda was installing the bootloader. Version-Release number of selected component: anaconda-20.15-1 The following was filed automatically by anaconda: anaconda 20.15-1 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1534, in install raise BootLoaderError("bootloader install failed") File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1548, in write self.install() File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2304, in writeBootLoader storage.bootloader.write() File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 173, in doInstall writeBootLoader(storage, payload, instClass, ksdata) 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) BootLoaderError: bootloader install failed Additional info: cmdline: /usr/bin/python /sbin/anaconda cmdline_file: initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2020-Alpha\x20x86_64 quiet BOOT_IMAGE=vmlinuz executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.11.0-300.fc20.x86_64 product: Fedora release: Cannot get release name. type: anaconda version: 20-Alpha Potential duplicate: bug 924902
Created attachment 797777 [details] File: anaconda.log
Created attachment 797778 [details] File: environ
Created attachment 797779 [details] File: lsblk_output
Created attachment 797780 [details] File: nmcli_dev_list
Created attachment 797781 [details] File: os_info
Created attachment 797782 [details] File: program.log
Created attachment 797783 [details] File: storage.log
Created attachment 797784 [details] File: syslog
Created attachment 797785 [details] File: ifcfg.log
Created attachment 797786 [details] File: packaging.log
Created attachment 797787 [details] File: anaconda-tb
During Anaconda installation after about 50% of files were copied from sha256sum and self test of flashdrive had been taken. cmdline: /usr/bin/python /sbin/anaconda cmdline_file: initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2020-TC2\x20x86_64 quiet BOOT_IMAGE=vmlinuz hashmarkername: anaconda kernel: 3.11.8-300.fc20.x86_64 package: anaconda-20.25.8-1 product: Fedora reason: BootLoaderError: bootloader install failed release: Cannot get release name. version: 20-TC2
Installed F20 Final TC3 on an LV without separate boot partition. Failed at bootloader installation. cmdline: /usr/bin/python /sbin/anaconda cmdline_file: initrd=initrd.img inst.stage2=hd:UUID=6cdb3bdc-1802-4c98-b650-7440cd7cab7d selinux=0 BOOT_IMAGE=vmlinuz hashmarkername: anaconda kernel: 3.11.9-300.fc20.x86_64 package: anaconda-20.25.11-1 product: Fedora reason: BootLoaderError: bootloader install failed release: Cannot get release name. version: 20-TC3
Suggesting that this should be a blocker.
The original reporter has this in his log: 06:13:35,358 INFO program: Running... grub2-install --no-floppy /dev/sdb 06:13:35,390 INFO program: /usr/lib/grub/i386-pc doesn't exist. Please specify --target or --directory 06:13:35,391 DEBUG program: Return code: 1 Also, according to the log, it seems he has a /dev/sdb1 as a standard ext4 partition. Therefore comment 13 might be a different bug - Clyde tries to install grub without a standard partition (using LVM only), which is not the case for comment 0. I tried to do the following with TC3: a) create a single standard ext4 partition covering the whole disk (no /boot, no swap, no /home, only /) and run anaconda on it - installation went OK and system booted b) create a single LV ext4 partition covering the whole disk (no /boot, no swap, no /home, only /) and run anaconda on it - installation went OK and system booted So, I can't really reproduce, or those are just red herrings and the real problem lies elsewhere. Guys, can any of you reproduce the problem? If you do, please describe the exact steps to achieve that. Also, please attach /tmp/anaconda-tb-* file (anyone except Björn). Don't forget to also try with a clean disk drive - to find out whether your previous disk contents cause this error. Thanks!
I will attach the requested files. They are on another machine. I did retry the installation and it failed in the same way. The install was to an LV on a raid 10 PV without a separate ext4 /boot. The install method worked fine with Fedora 18. Happy to start a new bz if you think appropriate. Wish there was a way to force the error reporting software to allow forcing a new bz in these circumstances.
Created new bz 1036705 and marked it as a blocker.
I tried to reproduce bug 1036705. What I did: 1. Added 4 disks to a VM 2. Went to manual partitioning, deleted all previous content 3. Left only a single partition (/). Edited LVM properties and set it to RAID10. 4. Installed 5. Crashed when "installing bootloader" cmdline: /usr/bin/python /sbin/anaconda cmdline_file: initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2020-TC3\x20x86_64 quiet BOOT_IMAGE=vmlinuz hashmarkername: anaconda kernel: 3.11.9-300.fc20.x86_64 package: anaconda-20.25.11-1 product: Fedora reason: BootLoaderError: bootloader install failed release: Cannot get release name. version: 20-TC3
Discussed at 2013-12-02 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-12-02/f20-blocker-review-%234.2013-12-02-17.02.log.txt . For now, this bug - Bjorn's bug - is rejected as a blocker, because it doesn't seem to be reproducible and Bjorn has not provided any details that would allow us to debug it. As kparal noted, the error is somewhat weird: 06:13:35,358 INFO program: Running... grub2-install --no-floppy /dev/sdb 06:13:35,390 INFO program: /usr/lib/grub/i386-pc doesn't exist. Please specify --target or --directory and may point to broken install media or a bad disk or something. But if Bjorn can provide us with more details that allow us to reproduce and investigate the bug, it could be considered for blocker status again: please drop the 'RejectedBlocker' from Whiteboard: field and re-set 'FinalBlocker' in Blocks: field to re-propose if so. Clyde's bug was incorrectly considered a duplicate by libreport, and has correctly been split out into a separate bug - https://bugzilla.redhat.com/show_bug.cgi?id=1036705 . We will consider its blocker status separately.
Installing Fedora 20 on a SATA software RAID.. Installer sees my previous partitions.... I formated all partitions, except /home.. and then at the time instlaling bootloader ths error occured.. cmdline: /usr/bin/python /sbin/anaconda cmdline_file: initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2020\x20x86_64 rd.live.check quiet BOOT_IMAGE=vmlinuz hashmarkername: anaconda kernel: 3.11.10-301.fc20.x86_64 package: anaconda-20.25.15-1 product: Fedora reason: BootLoaderError: bootloader install failed release: Cannot get release name. version: 20
installation cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base cmdline_file: initrd=/ubninit root=UUID=40FE-C84D rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 BOOT_IMAGE=/ubnkern hashmarkername: anaconda kernel: 3.11.10-301.fc20.x86_64 other involved packages: python-libs-2.7.5-9.fc20.x86_64 package: anaconda-20.25.15-1.fc20.x86_64 product: Fedora reason: BootLoaderError: bootloader install failed release: Fedora release 20 (Heisenbug) version: 20
Only using btrfs cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base cmdline_file: initrd=/ubninit root=UUID=40FE-C84D rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 BOOT_IMAGE=/ubnkern hashmarkername: anaconda kernel: 3.11.10-301.fc20.x86_64 other involved packages: python-libs-2.7.5-9.fc20.x86_64 package: anaconda-20.25.15-1.fc20.x86_64 product: Fedora reason: BootLoaderError: bootloader install failed release: Fedora release 20 (Heisenbug) version: 20
I do a amanual format of my SSD hrad disk. /dev/sda1 = 512 Mo is dedicated to EFI boot partition. I launch the anaconda installer. Then I select the sdd disk and I choose manual partitionning. If i didn't select the 512 Mo sda1 as a Bios boot partition( for instance set as vfat), anaconda complains so anaconda knows that it si working with a UEFI systems. So set /dev/sda1 as 512 Mo BIOS boot partition. Continue the installation, that will faisl at the bootloader installation. It looks like the 1006404 bug, but it is not exactly at the same position. It ssems that I am not able to access the /dev/sda1 mount: /dev/sda1 is write-protected, mounting read-only mount: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. That is strange, because If I had right understood the EFi boot mechanism, the EFI boot parition must be a FAT partition. During the installation I saw the formating of /dev/sda3 and /dev/sda4, so I imagine that /dev/sda1 is formated (or must be formatedat this point). Notice. I would like to have /boot -> /dev/sda1 /home -> /dev/sda4 Instead of that boot /boot and /home are in the sda3 / partition 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-libs-2.7.5-9.fc20.x86_64 package: anaconda-20.25.15-1.fc20.x86_64 product: Fedora reason: BootLoaderError: bootloader install failed release: Fedora release 20 (Heisenbug) version: 20
andre: 'BIOS boot partition' is required if you do a BIOS install to a gpt-labelled disk. It is different from 'EFI system partition', which is required when doing a UEFI install. It sounds like you are booting the installer in BIOS mode, not UEFI mode, but you want to be booting it in UEFI mode. This is the source of your problem.
Crashed during installing bootloader cmdline: /usr/bin/python /sbin/anaconda cmdline_file: initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2020\x20x86_64 rd.live.check quiet BOOT_IMAGE=vmlinuz hashmarkername: anaconda kernel: 3.11.10-301.fc20.x86_64 package: anaconda-20.25.15-1 product: Fedora reason: BootLoaderError: bootloader install failed release: Cannot get release name. version: 20
Installer crashed when installing boot loader. Installing over an old system with custom partitioning using RAID1 and LVM. cmdline: /usr/bin/python /sbin/anaconda cmdline_file: initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2020\x20x86_64 quiet BOOT_IMAGE=vmlinuz hashmarkername: anaconda kernel: 3.11.10-301.fc20.x86_64 package: anaconda-20.25.15-1 product: Fedora reason: BootLoaderError: bootloader install failed release: Cannot get release name. version: 20
installing Fedora20 using bfo onto a thinkpad t520 with an encripted disk everything went fine till it tried to install the boot loader. cmdline: /usr/bin/python /sbin/anaconda cmdline_file: repo=http://download.fedoraproject.org/pub/fedora/linux/releases/20/Fedora/x86_64/os/ initrd=http://download.fedoraproject.org/pub/fedora/linux/releases/20/Fedora/x86_64/os/images/pxeboot/initrd.img BOOT_IMAGE=http://download.fedoraproject.org/pub/fedora/linux/releases/20/Fedora/x86_64/os/images/pxeboot/vmlinuz hashmarkername: anaconda kernel: 3.11.10-301.fc20.x86_64 package: anaconda-20.25.15-1 product: Fedora reason: BootLoaderError: bootloader install failed release: Cannot get release name. version: 20
I also get INFO program: /usr/lib/grub/i386-pc doesn't exist. Please specify --target or --directory in my log with Fedora 20 Final. Cannot install it... No chance. But it is perfectly reproducable: The only drawback is that for reproducing the problem you need VMWARE vSphere Hypervisor 5.5. In order to reprocude the problem, create a virtual machine with VMWARE vSphere Hypervisor 5.5. Choose "Linux 2.6 kernel" when asked what OS you'll use. Choose 40 GB as you virtual hard disk size. All other settings may be the default ones. Install Fedora 20 with default settings in all dialogs. You'll get the error.
I can reproduce this on multiple failed installs on a Secure boot dual boot with Win 8.1. Unfortunately I could not save thhe error messages and did not have a working network. I was replacing a prior Ubuntu install 14.04 beta in the same partition which was to be replaced by the Fedora 20 (final) install.
I can also reproduce this at will on a single disk, single OS desktop system when installing from Cobbler using this partitioning scheme in its kickstart: #platform=x86, AMD64, or Intel EM64T # System authorization information auth --useshadow --enablemd5 # System bootloader configuration bootloader --location=mbr # Partition clearing information zerombr clearpart --all --initlabel autopart # Use text mode install text Each time, the install hangs when it gets to "Installing bootloader".
There are so many different storage configurations at play here, it's unlikely bootloader installation is failing for the exact same reason for everyone who has chimed in. Additionally, there is only one set of logs, and they are old.
Samantha: the dupes are showing up via libreport, it's not the reporters' fault. Only reports that are filed by libreport have that block that starts 'cmdline: (some cmdline)'. It's really a tooling problem, which could be be considered to be in anaconda or libreport or grub2 or...choose your poison, but *somewhere* on the dev side, you kinda ought to make failures of UEFI bootloader installation more fine grained just so we *don't* get these kind of duplicated reports.
I also got the problem My partitioning scheme was: standard partitions 64MB /boot 2G LUKS swap 158GB LUKS on / libreport told it was already reported, so I cant report my own files.
/boot was ext4 formatted. Formatting /boot as ext2 does not change anything now retrying with an ext2 /boot but no LUKS partitions.
OK, found the problem. It is reported on the storage log: no space left on device. 100MB is not enough for /boot, half of that is eaten by the recovery initramfs. Anaconda shall identify this error and report it, instead of "unknown error". Now trying to confirm this by setting up a system with a 256 MB /boot. There is a document here that says that 250 MB are OK, but nothing tells what happens if I select less than that. http://docs.fedoraproject.org/en-US/Fedora/19/html/Installation_Guide/s2-diskpartrecommend-x86.html Better, a warning could be added at the partitioning step if the partition that contains /boot is less than 250 MB.
I reproduced this bug by creating /boot with only 80 MiB. At the end of installation it says: "The following error occurred while installing the bootloader. The system will not be bootable. Would you like to ignore this and continue with installation? failed to write bootloader configuration" I think that anaconda should warn user that /boot is too small before installation starts. Is there any way how to compute the minimal size? Or maybe it would be better to set some safe minimum. The size of /boot of default installation is about 100 MB so maybe something like 200 MB would be enough. I'm reopening bug and proposing for alpha blocker as it violates the criteria: " A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility." and "A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles." It also somehow violates the beta criterion "When using the custom partitioning flow, the installer must be able to: - Reject or disallow invalid disk and volume configurations without crashing." only it doesn't crash but such setting should be rejected.
The F20 install guide recommends at least 500 MB for /boot http://docs.fedoraproject.org/en-US/Fedora/20/html/Installation_Guide/s2-diskpartrecommend-x86.html The biggest file installed in this partition is the recovery initramfs
Peter, could we close this bug for clarity's sake and create a fresh new one for the particular bug found in comment 35? Let's reference this one in See Also. It will be much easier to read for everyone involved. Thanks.