Bug 810391

Summary: During preupgrade, anaconda tries to mount target system's /boot partition after dracut has already done so
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 17CC: anaconda-maint-list, bloch, g.kaviyarasu, jonathan, robatino, satellitgo, tflink, vanmeeuwen+fedora, wwoods
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: AcceptedBlocker
Fixed In Version: anaconda-17.20-1.fc17 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-11 17:21:58 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 752649    
Attachments:
Description Flags
Screenshot showing error during attempted workaround
none
init.log from the failed preupgrade with 17.19 none

Description Adam Williamson 2012-04-05 20:13:52 UTC
Trying to preupgrade from F16 to F17, after working around https://bugzilla.redhat.com/show_bug.cgi?id=810005 , we hit a second bug: anaconda tries to mount the target system's /boot partition at /mnt/sysimage/boot , but dracut has already mounted it at /run/initramfs/live .

In the past, apparently - F14 era - we copied the needed stuff to /tmp and then unmounted it:

 logMessage(INFO, "Path to stage2 image is %s", path);
 rc = copyFile(path, "/tmp/install.img");
 rc = mountStage2("/tmp/install.img");

anyhow, we need to work around this somehow to allow preupgrade to work. This was accepted as a Beta blocker at the 2012-04-05 go/no-go meeting.

Comment 1 Will Woods 2012-04-05 23:06:23 UTC
Commit 9985468 (on f17-branch) should fix this. Or at least hack around it.

In the meantime you might also be able to work around the problem by replacing the "stage2=..." item with:

  root=live:UUID=xxx rd.live.dir=upgrade rd.live.ram

(where "upgrade" should match the path to squashfs.img)

Comment 2 Fedora Update System 2012-04-06 13:58:13 UTC
anaconda-17.19-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/anaconda-17.19-1.fc17

Comment 3 Tim Flink 2012-04-06 20:46:26 UTC
I just tried a preupgrade using a local repo and a custom test iso built with anaconda-17.19-1.fc17 but it's still failing with the default options.

I see the following when I attempt preupgrade:

dracut: anaconda: found /run/install/repo//upgrade/squashfs.img
Copying installer image to RAM...
(this may take a few minutes)

dracut Warning: Unable to process initqueue

Dropping to debug shell

dracut:/#

Comment 4 Tim Flink 2012-04-06 20:51:35 UTC
the workaround from c#1 still works for me using the same setup described in c#3

Comment 5 Tim Flink 2012-04-06 20:57:47 UTC
Created attachment 575828 [details]
Screenshot showing error during attempted workaround

(In reply to comment #4)
> the workaround from c#1 still works for me using the same setup described in
> c#3

Apologies for the noise, but I spoke too soon. Using the workaround in c#1 gets me to the point where anaconda starts but while it's scanning storage. I attached a screenshot of the error message I see if I get that far

Comment 6 Fedora Update System 2012-04-06 23:22:29 UTC
Package anaconda-17.19-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-17.19-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-5447/anaconda-17.19-1.fc17
then log in and leave karma (feedback).

Comment 7 Adam Williamson 2012-04-07 01:52:13 UTC
tfli: that's precisely *this* bug. Are you _sure_ you tested with 17.19?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 8 Adam Williamson 2012-04-07 06:16:21 UTC
I can confirm the first part of tflink's report, using his test repo: just as he says, I see "Copying installer image to RAM...(this may take a few minutes)" (indicating we've definitely got the new 17.19 code), then it says 'unable to process initqueue' and drops to dracut shell. So doesn't look like this is out of the woods yet :(



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 9 Adam Williamson 2012-04-07 06:21:19 UTC
so this time the script that's failing in initqueue/finished is kickstart.sh, it contains [ -e /tmp/ks.cfg.done ] , and indeed there is no such file in /tmp - nothing to do with any kickstart in fact. /tmp contains only export.orig , no other file.

Comment 10 Adam Williamson 2012-04-07 06:34:35 UTC
Created attachment 575873 [details]
init.log from the failed preupgrade with 17.19

Comment 11 Adam Williamson 2012-04-07 06:35:49 UTC
A thought occurs: don't we need to pull the kickstart from the /run/initramfs/live mount which we're now removing right after copying squashfs off it? Is it disappearing before we can get the kickstart off of it?

Comment 12 Fedora Update System 2012-04-10 04:14:01 UTC
anaconda-17.20-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/anaconda-17.20-1.fc17

Comment 13 Fedora Update System 2012-04-11 17:21:58 UTC
anaconda-17.20-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.