Bug 1101341 - Rescue a Fedora system from grub menu doesn't launch anaconda rescue mode
Summary: Rescue a Fedora system from grub menu doesn't launch anaconda rescue mode
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: mulhern
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F21BetaBlocker F21PPCBeta
TreeView+ depends on / blocked
 
Reported: 2014-05-27 02:14 UTC by Chris Murphy
Modified: 2014-10-15 21:07 UTC (History)
15 users (show)

Fixed In Version: anaconda-21.48.7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-15 21:07:56 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1090009 1 medium CLOSED Anaconda fails to scan for Linux partitions in rescue mode with degraded RAID1 array 2024-06-18 07:26:26 UTC

Internal Links: 1090009

Description Chris Murphy 2014-05-27 02:14:09 UTC
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

Comment 1 Vratislav Podzimek 2014-05-27 07:43:01 UTC
Martin, I believe this is the same issue as the non-working text mode with the 'text' boot option after your optparse -> argparse changes.

Comment 2 Gene Czarcinski 2014-05-29 16:36:36 UTC
verified as now working

Comment 3 Chris Murphy 2014-07-18 03:51:10 UTC
Reopening. This is not working in the 20140717 x86_64 boot.iso with anaconda-21.48-1.

Comment 4 Adam Williamson 2014-09-17 19:51:19 UTC
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 .

Comment 5 Adam Williamson 2014-09-17 19:55:22 UTC
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.

Comment 6 Mike Ruckman 2014-09-17 20:12:23 UTC
Adam's patch worked fine for me in a VM.

Comment 7 mulhern 2014-09-17 20:41:53 UTC
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.

Comment 8 Adam Williamson 2014-09-17 20:57:16 UTC
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.

Comment 9 Chris Murphy 2014-09-17 21:57:59 UTC
+1 change this criterion from alpha to beta: this functionality isn't critical to alpha testing at all.

Comment 10 Kalev Lember 2014-09-17 22:50:33 UTC
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.

Comment 11 Adam Williamson 2014-09-17 23:01:55 UTC
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.

Comment 12 Dennis Gilmore 2014-09-17 23:15:27 UTC
+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.

Comment 13 Fedora Update System 2014-09-17 23:47:24 UTC
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

Comment 14 Jaroslav Reznik 2014-09-18 10:49:33 UTC
(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.

Comment 15 Matthew Miller 2014-09-18 14:11:58 UTC
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.)

Comment 16 Mike Ruckman 2014-09-18 19:48:51 UTC
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.

Comment 17 Fedora Update System 2014-09-19 17:46:35 UTC
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).

Comment 18 Fedora Update System 2014-10-01 15:26:07 UTC
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

Comment 19 Adam Williamson 2014-10-08 16:29:03 UTC
This fix should be included in 21 Beta TC2, we can verify it there.

Comment 20 Mike Ruckman 2014-10-09 18:28:10 UTC
Rescue mode worked for me on bare metal with a server-netinst i386 USB drive with TC2.

Comment 21 Adam Williamson 2014-10-15 21:07:56 UTC
Yep, I confirmed rescue mode in TC2 and the update went stable. Closing.


Note You need to log in before you can comment on or make changes to this bug.