Hide Forgot
Description of problem: Using the latest version of fedup via the command line and network mode, I upgraded my Fedora 17 system to Fedora 19. When I came back, it was apparently frozeon on this screen with the last line "reached target shutdown" after many "unmount" statements. Screenshot of update: http://postimg.org/image/6urhku9on/ After rebooting, there was no normal boot option, so I booted into rescue mode and ran grub2. Now when I use the new grub entry, it stops booting with these two lines: [ OK ] Reached target Initrid Default Target dracut-pre-privot[267]: Warning: /sysroot/system-upgrade-root doesn't exist How reproducible: Every time I boot
Created attachment 831338 [details] screenshot of broken boot
Does your grub2.cfg happen to have "systemd.unit=system-upgrade.target" in the boot arguments? If so, can you remove that argument and see if the system boots? (You might also want to remove "upgrade" and "enforcing=0", if present) If not, can you attach your grub2.cfg?
Created attachment 831880 [details] grub2.config Does not have "systemd" or "upgrade"
Thank you for the quick reply. By the way, while not a primary concern, but I am not sure the grub rescue option works either. It stops at "Started IPv6 firewall with ip6tables" and doesn't have a login prompt, but I can easily ALT+RIGHT to get a console.
From the screenshot it looks like you're booting the upgrade image again - normal initrd images don't do anything with /sysroot/system-upgrade-root. What happens if you try booting the "Fedora, with Linux 3.11.9-200.fc19.i686" menu item instead? If that works (or you can get the system to boot otherwise), you can use 'fedup --resetbootloader' to remove the fedup images from grub2.cfg. Why the fedup images would still be in your grub2.cfg is a mystery. Did you maybe upgrade from GRUB to GRUB2 by hand, and leave the old grub.cfg in place? Can you attach /var/log/fedup.log and /var/log/upgrade?
Created attachment 832414 [details] fedup.log
Created attachment 832416 [details] upgrade.log
Created attachment 832417 [details] X server log I ran 'fedup --resetbootloader' and booted using a fc19 kernel. I don't think I upgraded grub manually, but right now I do see both config files: /boot/grub/grub.conf /boot/grub2/grub.cfg It seems the X server is broken, but I can use the console and remote services. The requested logs are attached, and I added the X server log Thank you, Will
(In reply to Andrew Ziem from comment #8) > Created attachment 832417 [details] > X server log > > I ran 'fedup --resetbootloader' and booted using a fc19 kernel. > > I don't think I upgraded grub manually, but right now I do see both config > files: > /boot/grub/grub.conf > /boot/grub2/grub.cfg > > It seems the X server is broken, but I can use the console and remote > services. > > The requested logs are attached, and I added the X server log > > Thank you, Will Broken Xserver also happened to me when upgrading from F17 to F19 some time back. Several components aren't installed because of the differences between X components and filesystem in F17 and F19. Try running from console: sudo yum install xorg-x11-* If that doesnn't work, the next thing to install is all necessary Mesa components similarly. If you are in runlevel 5, X should come up once all dependency requirements are met (or, you might need to restart lightdm.service). Best practice to upgrade F17 is to upgrade F17 -> F18 -> F19. I have found considerably less problems and even flawless upgrades on some machines that way.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I recently had a similar issue where "systemd.unit=system-upgrade.target" and "upgrade" were left in the boot parameters in grub2.cfg. I noticed that mentioned in one of the previous comments but the root cause wasn't really addressed. Having these values left in the configuration lead to an endless reboot cycle that was initially tough to troubleshoot, being that there were no obvious clues in /var/log/messages or dmesg (didn't think to check boot.log, which has since been overwritten from fixing the error). I upgraded from F16 to F17 using the last DVD to have the "upgrade" option, then used fedup to go from 17->18->19->20->21. I don't recall exactly when it started happening, but it was at least at 19 IIRC. Anyway, I see the Fedora EOL message, but I think this applies to fedup (if not the package specifically, something called by it) at least not cleaning those values up even in the most recent release. How do we bump the version this applies to so it doesn't get autoclosed/forgotten?
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.