Description of problem: Booting from boot.iso using the Troublesthooing > Rescue a Fedora system option, (confirming boot parameter rescue is used), results in the anaconda GUI appearing, not the rescue mode UI. Version-Release number of selected component (if applicable): 21.37-1 3.15.0-0.rc6.git0.1.fc21.x86_64 How reproducible: Always Steps to Reproduce: 1. UEFI or BIOS booting, using boot parameter rescue 2. 3. Actual results: Anaconda GUI welcome screen appears with language selection. Expected results: Rescue mode. Additional info: dmesg http://paste.fedoraproject.org/104971/56643140 anaconda.log http://paste.fedoraproject.org/104972/40115667 program.log http://ur1.ca/hdwl9
Martin, I believe this is the same issue as the non-working text mode with the 'text' boot option after your optparse -> argparse changes.
verified as now working
Reopening. This is not working in the 20140717 x86_64 boot.iso with anaconda-21.48-1.
This is an Alpha blocker, unfortunate we didn't spot it as such prior to today :( "The rescue mode of the installer must start successfully and be able to detect and mount an existing default installation." https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria#Rescue_mode I believe I have identified the bug and submitted a patch - https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-September/013376.html .
fwiw this is really two bugs - when you first reported it, it really was caused by what vpodzime thought and fixed. It was broken again (in a different way) by https://git.fedorahosted.org/cgit/anaconda.git/commit/?id=6187aa0d074816b055a0f13d1174662e8c601d76 in June. I think the report's short enough that we can just use it to track the current breakage, though.
Adam's patch worked fine for me in a VM.
Martin, not recognizing rescue mode from boot options was an oversight from my #1090009 patches, and the one line fix needs to just be marshalled and put in on all three branches with all the promptness the acks allow. So, I'm just grabbing bzs for both branches.
So more than one person has suggested the criteria should be revised and rescue mode shouldn't block Alpha (suggested workarounds: use dracut shell, use a live image, use an F20 image's rescue mode). anaconda team can have a build with this fixed in ~1.5hrs from now. We can either do an emergency RC2 spin with that fix and transfer most test results from RC1 to RC2, or we can decide to modify the criteria, reject this as a blocker, and continue on track to release RC1 if no other candidate blockers are found. I'm not hugely attached to the criterion, I can see the case for changing it. The objection would I guess be people who have no network connection and no spare images lying around. Either way, we need to make a choice fast, so please provide comments and blocker votes, folks.
+1 change this criterion from alpha to beta: this functionality isn't critical to alpha testing at all.
I would be +1 to moving this to Beta criterion. Too much slipping already. If we were going to respin the images anyway for another fix, I'd be +1 FE for pulling this in though.
fixing doesn't imply a slip, note, we could possibly spin an RC2 and sign off tomorrow without slipping, if we accept RC1 test results as valid for RC2 with some basic smoke checks. still, the bigger our compose set, the scarier that gets. and I see two changes to spin-kickstarts since RC1.
+1 blocker, its what the criteria says. and while i would hope someone installing alpha has other machines and ways to deal with it its a kinda important feature.
anaconda-21.48.7-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/anaconda-21.48.7-1.fc21
(In reply to Adam Williamson (Red Hat) from comment #11) > fixing doesn't imply a slip, note, we could possibly spin an RC2 and sign > off tomorrow without slipping, if we accept RC1 test results as valid for > RC2 with some basic smoke checks. still, the bigger our compose set, the > scarier that gets. and I see two changes to spin-kickstarts since RC1. Can we limit the compose set by redoing only affected part of the set (that includes rescue mode)? But I really like to avoid further slipage (unless other important blockers are found). As you pointed out, we have several options how to deal with this bug.
I don't think rescue needs to block alpha, when it comes right down to it, even though it's obviously nice to have. (So +1 to move to beta; -1 for blocker.)
Discussed in 2014-09-18 Go/No-Go meeting. Voted as an AcceptedBlocker. This bug is a clear blocker of the written criteria. However, it was decided to move the criteria to the Beta milestone as it better fits our understanding of the typical use case.
Package anaconda-21.48.7-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-21.48.7-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-11161/anaconda-21.48.7-1.fc21 then log in and leave karma (feedback).
anaconda-21.48.8-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/anaconda-21.48.8-1.fc21
This fix should be included in 21 Beta TC2, we can verify it there.
Rescue mode worked for me on bare metal with a server-netinst i386 USB drive with TC2.
Yep, I confirmed rescue mode in TC2 and the update went stable. Closing.