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.
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)
anaconda-17.19-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/anaconda-17.19-1.fc17
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:/#
the workaround from c#1 still works for me using the same setup described in c#3
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
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).
tfli: that's precisely *this* bug. Are you _sure_ you tested with 17.19? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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
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.
Created attachment 575873 [details] init.log from the failed preupgrade with 17.19
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?
anaconda-17.20-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/anaconda-17.20-1.fc17
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.