This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 810391 - During preupgrade, anaconda tries to mount target system's /boot partition after dracut has already done so
During preupgrade, anaconda tries to mount target system's /boot partition af...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
17
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
AcceptedBlocker
:
Depends On:
Blocks: F17Beta/F17BetaBlocker
  Show dependency treegraph
 
Reported: 2012-04-05 16:13 EDT by Adam Williamson
Modified: 2012-06-20 17:42 EDT (History)
9 users (show)

See Also:
Fixed In Version: anaconda-17.20-1.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-11 13:21:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Screenshot showing error during attempted workaround (29.85 KB, image/png)
2012-04-06 16:57 EDT, Tim Flink
no flags Details
init.log from the failed preupgrade with 17.19 (245.08 KB, text/plain)
2012-04-07 02:34 EDT, Adam Williamson
no flags Details

  None (edit)
Description Adam Williamson 2012-04-05 16:13:52 EDT
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 19:06:23 EDT
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 09:58:13 EDT
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 16:46:26 EDT
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 16:51:35 EDT
the workaround from c#1 still works for me using the same setup described in c#3
Comment 5 Tim Flink 2012-04-06 16:57:47 EDT
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 19:22:29 EDT
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-06 21:52:13 EDT
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 02:16:21 EDT
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 02:21:19 EDT
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 02:34:35 EDT
Created attachment 575873 [details]
init.log from the failed preupgrade with 17.19
Comment 11 Adam Williamson 2012-04-07 02:35:49 EDT
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 00:14:01 EDT
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 13:21:58 EDT
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.

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