Description of problem: Install of Fedora 27 Rawhide 20170804.n.1 Workstation live image fails with the following error - boot loader install failed Version-Release number of selected component (if applicable): 27 Rawhide 20170804.n.1 How reproducible: Always Steps to Reproduce: 1. Boot up the Fedora 27 Rawhide 20170804.n.1 Workstation live image. 2. After booting into the live environment, select 'Install to hard disk' option 3. Proceed to install Fedora using anaconda installer by making sensible choices Actual results: During the last phase of installation, the installer shows an error dialog saying that the 'boot loader install failed'. If i proceed with the installation anyway, the device fails to boot after a reboot. Expected results: The installation should complete successfully and should boot Fedora successfully. Additional info: Tried to install the image both on bare metal and a Virtual machine and got the same results.
Please attach logs from the installation as separate text-plain attachments so that we can debug the issue. Logs are located in /tmp during the installation or in /var/log/anaconda after the installation. Thanks in advance! :)
Created attachment 1313063 [details] anaconda logs
Created attachment 1313064 [details] ifcg log
Created attachment 1313066 [details] lvm log
Created attachment 1313067 [details] packaging log
Created attachment 1313068 [details] program log
Created attachment 1313070 [details] storage log
Created attachment 1313071 [details] storage state
Hey, I'm sorry for the delay. I've attached the logs from /tmp above :)
openQA started running into this error frequently with the 20170804.n.0 compose. On a preliminary look, I *think* it affects live and OStree installs, but not network or DVD installs. Will confirm for sure tomorrow. Proposing as a Beta blocker, per any of the Alpha "must be able to complete an install" criteria, for the affected release-blocking images (Workstation live, KDE live at least).
correction: 20170804.n.1 , not 20170804.n.0 . That was the compose after the mass rebuild, so of course it's hard to figure out what actually changed. It looks like grub2 went from 2.02-0.38.fc26 to 2.02-3.fc27 in that compose, which may be the issue.
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'. More information and reason for this action is here: https://fedoraproject.org/wiki/Releases/27/HouseKeeping#Rawhide_Rebase
<pjones> adamw: yeah, I've got a patch for it but I have to fix the builders before I can fix it.
pjones says -8 and -9 should fix the initial error. It seems that may be true, but now we're hitting another error, in the same cases (live and ostree installs): https://openqa.fedoraproject.org/tests/131982#step/_do_install_and_reboot/36 https://openqa.fedoraproject.org/tests/131982/file/_do_install_and_reboot-program.log 13:50:16,762 INF program: Running... grub2-install --no-floppy /dev/vda 13:50:17,902 INF program: Installing for i386-pc platform. 13:50:17,909 INF program: grub2-install: error: cannot open `/usr/lib/grub/i386-pc/lzma_decompress.img': No such file or directory. 13:50:17,910 DBG program: Return code: 1
Update: -8 actually worked OK. The Fedora-27-20170817.n.3 compose had -8 in it, and the live install tests passed there: https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=27&build=Fedora-27-20170817.n.3&groupid=1 https://openqa.fedoraproject.org/tests/131571
The issue in -9 should be fixed by -10 (https://koji.fedoraproject.org/koji/buildinfo?buildID=958096 ), but we haven't had a compose since that was built so I'm not sure yet. I'll try to find a minute to test manually today if I can.
Discussed during blocker review [1]: AcceptedBlocker (Beta) - this seems to cause all BIOS live installs to fail, which is a clear violation of several "must be able to complete an installation" Alpha criteria for the Workstation and KDE live images [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-08-21/
OK, I have managed to test manually that grub2 -10 does indeed fix the follow-up bug. F27 composes are currently broken due to the whole rdma-core mess, but whenever the next successful compose actually happens, this bug should go away. If there are any further bootloader issues we'll file them separately.
Do we have a new problem with openQA ppc64le on rawhide-20170822 (1) that is integrating grub2-*-1:2.02-10.fc27 as per log (2) (1) https://openqa.stg.fedoraproject.org/tests/147298#step/_do_install_and_reboot/32 (2) https://openqa.stg.fedoraproject.org/tests/147298/file/_do_install_and_reboot-packaging.log
(In reply to Michel Normand from comment #19) > Do we have a new problem with openQA ppc64le on rawhide-20170822 (1) that is > integrating grub2-*-1:2.02-10.fc27 as per log (2) > > (1) > https://openqa.stg.fedoraproject.org/tests/147298#step/ > _do_install_and_reboot/32 > (2) > https://openqa.stg.fedoraproject.org/tests/147298/file/ > _do_install_and_reboot-packaging.log the signature is not the same as per log extract (3) (3) https://openqa.stg.fedoraproject.org/tests/147298/file/_do_install_and_reboot-anaconda.log === 16:56:08,033 INF bootloader: bootloader.py: mbr will be updated for grub2 16:56:08,397 INF bootloader: bootloader.py: used boot args: rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet 16:56:09,836 ERR bootloader: bootloader.write failed: boot loader install failed ===
Yes, it's a different bug. I noticed it a couple days ago but everything's been on fire and I hadn't got around to filing it yet. You can find the useful output in program.log: 08:52:12,037 INF program: Running... grub2-install --no-nvram --no-floppy /dev/vda1 08:52:12,386 INF program: Installing for powerpc-ieee1275 platform. 08:52:12,387 INF program: grub2-install: error: not a HFS+ filesystem. 08:52:12,388 DBG program: Return code: 1 The netinst test that ran at the time of the compose passed; this probably means they used an earlier grub2 package that worked. Now this compose has been synced to the repo, if I re-ran that test it'd probably fail...unfortunately, none of the logs uploaded by a successful test tell us which version of the grub2 package it used, but the previous successful Rawhide compose was 20170821.n.0 which had grub2-2.02-7.fc27. So looks like this got broken somewhere between -7 and -10, somehow. Still, it's clearly a different bug, and seems to be specific to a non-blocking arch, so can you please file it separately? Thanks.
Filed it myself, https://bugzilla.redhat.com/show_bug.cgi?id=1484474 .