Hide Forgot
Description of problem: fedup 0.8.0-3 creates a grub2 entry, but does not append the upgrade arguments, resulting in a standard F-19 boot instead of the F19->F20 upgrade process. Version-Release number of selected component (if applicable): fedup-0.8.0-3.fc19.noarch How reproducible: On 2 different F-19 workstations Steps to Reproduce: 1. start fedup 2. reboot system 3. select 'System Upgrade (fedup)' boot entry Actual results: F-19 is started Expected results: F-19 -> F-20 upgrade process is started Additional info: linux /vmlinuz-fedup (with initrd /initramfs-fedup.img) is actually booted, but the boot process continues into the standard F-19 boot process, resulting in a (functional) F-19. From the /boot/.grub2/grub.cfg kernel boot parameters, "upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup" appears to be missing. Adding this manually (as per https://bugzilla.redhat.com/show_bug.cgi?id=902498#c7) to the 'System Upgrade (fedup)' menuentry, allows the F-20 upgrade process to start. This issue has been encountered on 2 different F-19 workstations.
Typo : /boot/.grub2/grub.cfg -> /boot/grub2/grub.cfg
Pretty sure I ran into this same problem yesterday while attempting to upgrade from F18 to F19. First, I updated to the latest "bug fix" versions of fedup & fedora-release: fedup-0.8.0-3.fc18.noarch fedora-release-18-6.noarch Then I ran the following, which worked (or claimed to have worked, after churning through a lot of package downloads): fedup-cli -v --network 19 --nogpgcheck --debuglog /root/fedup.debug.log However, the 'System Upgrade (fedup)' entry in grub2.cfg just mirrored my normal kernel parameters, with nothing associated with the upgrade at all. As a result, when I rebooted, I ended up running the fedup kernel into a normal OS boot experience, which was super confusing to say the least. I'll attempt to try manually adding "upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup" to the fedup kernel boot parameters and attempt the upgrade again. However, that won't happen before the end of this week, as I wasted too much time on this yesterday, and I have real work I need to get done for the next few days.
(In reply to Lonni J Friedman from comment #2) > Pretty sure I ran into this same problem yesterday while attempting to > upgrade from F18 to F19. Same here, except F19 -> F20. I added the 'upgrade systemd.unit=system-upgrade.target' stuff, added 'selinux=0' and more updating stuff appears to be started.
Also: Why do we have to boot into some weird environment just to start upgrade system-upgrade.target via systemd? Why can't we fire this up by hand while in runlevel 1? Why isn't this documented as an option or at least described as a non-option?
Is something missing from the kernel args? I see fedup-stuff install stuff that is normally excluded in my repo configs. How come that these are no longer a valid source of info?
@udo Can you elaborate on your last comment? Its unclear to me what you're referring to.
In my case I am testing the upgrade to F20 on my mythtv box. I build mythtv from source myself every now and then. I do not install from a repo. So I excluded mythtv in the repo configs. But I accidentally saw mythtv rpms being installed while testin the install with info from this bug. Maybe it is not a kernel parameter issue then maybe make a separate bug if needed.
The yum repos that are enabled are controlled either via the yum command line, or via /etc/yum.repo.d . Its definitely not a boot time kernel parameter. Now I suppose its possible that the OS upgrade tool might have a bug which ignores the enabled parameter, or explicitly sets it to enabled for every defined repo. But that's still not a kernel issue.
(In reply to Lonni J Friedman from comment #8) > The yum repos that are enabled are controlled either via the yum command > line, or via /etc/yum.repo.d . Its definitely not a boot time kernel > parameter. Now I suppose its possible that the OS upgrade tool might have a > bug which ignores the enabled parameter, Thanks. So I'll make another bug...!
On a positive note: After doing the stuff from comment 3 the upgrade appears to have worked.
Unfortunately, it didn't work for me. The best that I got was the OS updater seemingly running for about a minute, then aborting due to an error that flashed across the screen, followed by a reboot (plus it purged the Fedup entry from grub), at which point I was booted back into F18. After wasting another hour trying to debug this mess, I gave up, did the "unsupported" yum upgrade route, which worked perfectly, and I'm running F19 now. Its sad that the unsupported upgrade mechanism works, while the officially supported upgrade mechanism fails, repeatedly.
(In reply to udo from comment #10) > On a positive note: > After doing the stuff from comment 3 the upgrade appears to have worked. new-kernel-pkg --initrdfile /boot/initramfs-fedup.img --banner 'System Upgrade' --kernel-args 'upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup selinux=0' --make-default --install fedup also here, all kernel-args was missing in grub entry ... , still can't get upgrade 19 -> 20 , now fails on upgrade-switch-root.service can't find or no such file or directory /system-upgrade-root/tmp
fedup-0.8.0 doesn't add those boot arguments. They were removed because they caused a lot of other problems, like infinite reboot loops. (see bug 964303 and its many duplicates.) So they aren't required when upgrading to F20. Unfortunately, since the Fedora 19 images use fedup-dracut-0.7.x, you can't get an upgrade to F19 to start without adding the boot arguments. You could upgrade straight from F18 to F20, though. The simplest workaround for the moment (as you've discovered - thanks for testing, y'all) is to add: upgrade systemd.unit=system-upgrade.target But see below if you have SELinux disabled: (In reply to udo from comment #3) > I added the 'upgrade systemd.unit=system-upgrade.target' stuff, added > 'selinux=0' and more updating stuff appears to be started. Yes, if you have SELinux disabled/removed, you'll also need to add "selinux=0". That's bug 1044484.
If you're having this problem with a F18→F19 upgrade, see bug 1054988. Otherwise this is actually the same problem as bug 1046347. *** This bug has been marked as a duplicate of bug 1046347 ***