Bug 964303 - reboot loop after fedup upgrade due to "systemd.unit=system-upgrade.target" in boot args
reboot loop after fedup upgrade due to "systemd.unit=system-upgrade.target" i...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: fedup (Show other bugs)
18
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Will Woods
Fedora Extras Quality Assurance
:
: 902555 912320 918894 994775 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-17 15:12 EDT by rvalkass
Modified: 2014-04-07 14:43 EDT (History)
8 users (show)

See Also:
Fixed In Version: fedup-0.8.0-3.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-19 02:21:53 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description rvalkass 2013-05-17 15:12:33 EDT
Description of problem:

I recently used fedup to upgrade from F17 to F18. This had problems of its own (see bug 958586 for details). Fedup eventually ran, but now it's impossible to boot my system. Selecting any option in GRUB results in a few seconds of the boot screen, followed by a power cycle. This repeats ad infinitum.


Version-Release number of selected component (if applicable):

fedup-0.7.3-5.fc17

How reproducible:

Every time I boot my PC, and every time it boots itself after that until I force it to stop.


Steps to Reproduce:
1. Install Fedora 17
2. Use for a while
3. Install fedup
4. Run fedup-cli
5. Reboot
6. Wait for fedup to do its thing
7. Watch as your PC now endlessly power cycles
  
Actual results:

PC endlessly reboots itself. It never manages to reach the login screen. This happens with both F18 and F17 entries on the GRUB screen. I stress that all entries worked fine before the use of fedup!

Expected results:

I was optimistic and actually expected a successful upgrade and bootable F18 system.

Additional info:

The last messages I see flash on screen before the PC reboots (if I press ESC at the boot screen) concern the following:

         Starting Trigger Flushing of Journal to Persistent Storage...
[  OK  ] Started Tell Plymouth To Write Out Runtime Data.
[  OK  ] Started Trigger Flushing of Journal to Persistent Storage.
[  OK  ] Started Recreate Volatile Files and Directories.
[  OK  ] Reached target System Initialization.
         Starting Prepare Upgrade Image...
[  OK  ] Reached target System Upgrade.
upgrade-prep.sh[493]: /usr/lib/systemd/upgrade-prep.sh: line 23: /run/initramfs/upgrade.conf:
upgrade-prep.sh[493]: can't find /run/initramfs/upgrade.conf

Lots of things get unmounted and stopped. Then...

[  OK  ] Started Save Random Seed.
[FAILED] Failed to start Restore /run/initramfs.

A few more messages appear, then the last words are "giving up"

As the system can't be booted, I've no way to actually copy and paste the boot messages from anywhere; apologies for any inconsistencies or errors. You'll have to wait for me to download a live DVD image onto another machine if you need anything more detailed.
Comment 1 Will Woods 2013-05-17 16:03:28 EDT
Is there a "systemd.unit=system-upgrade.target" item in the boot arguments?
If so, edit the boot arguments and remove that.

Otherwise, boot one of the non-fedup boot entries, but edit the commandline to add 'rescue' (or, failing that, 'emergency'). This should let you log in to your system and figure out what's going on.

Let me know what you find out!
Comment 2 rvalkass 2013-05-17 16:23:51 EDT
Had to remove "upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup" from the boot arguments. Surely fedup shouldn't be putting/leaving those arguments in there once it's done?
Comment 3 James Le Cuirot 2013-07-16 05:26:51 EDT
This stung me after upgrading from 18 to 19. This was my boot line after the upgrade.

linux	/vmlinuz-3.9.9-302.fc19.x86_64 root=/dev/mapper/vg_red-lv_root ro quiet rhgb LANG=en_GB.UTF-8 upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup enforcing=0 rd.luks.uuid=a700e683-f1f3-4a8d-ac3e-80c21f62ff8e rd.md.uuid=0ef30b66:a897a114:9b1ad4dd:ce040e22
Comment 4 Will Woods 2013-07-16 12:44:46 EDT
(In reply to rvalkass from comment #2)
> Had to remove "upgrade systemd.unit=system-upgrade.target
> plymouth.splash=fedup" from the boot arguments. Surely fedup shouldn't be
> putting/leaving those arguments in there once it's done?

Under normal circumstances they get removed. Usually it works like this:

1) You run fedup. It adds a boot entry and tells you to reboot.
2) You reboot. fedup removes its boot entry immediately at startup.
3) The upgrade proceeds, and when a new kernel is installed it copies the arguments from the newest F18 kernel entry.

This bug happens if you install a new kernel package between 1) and 2) - that kernel package will copy *fedup's* boot arguments, so even after fedup removes its boot entry, the newest F18 entry has a copy of fedup's boot arguments.

There's a couple of possible solutions to this problem:

1) Don't touch the bootloader at the end of fedup. 
   The user has to run something like "fedup --start" to begin the upgrade. 

2) Don't rely on boot arguments to start the upgrade.
   Use some other method (e.g. systemd generator) to change the default target.

Until then: if you just ran fedup but you're not ready to upgrade just yet, 'fedup --resetbootloader' will remove the fedup boot entry but keep all the downloaded packages/images; re-running the previous 'fedup' command will check for new updates and reuse already downloaded packages/images for anything that hasn't changed.
Comment 5 Will Woods 2013-10-09 15:42:01 EDT
*** Bug 912320 has been marked as a duplicate of this bug. ***
Comment 6 Will Woods 2013-10-09 15:43:23 EDT
*** Bug 918894 has been marked as a duplicate of this bug. ***
Comment 7 Will Woods 2013-10-09 15:47:01 EDT
*** Bug 994775 has been marked as a duplicate of this bug. ***
Comment 8 Will Woods 2013-10-23 18:01:04 EDT
This should be fixed in fedup git by:

  https://github.com/wgwoods/fedup/commit/72d947a
  https://github.com/wgwoods/fedup/commit/b443c0d

which will go into the next fedup release.
Comment 9 Fedora Update System 2013-12-11 17:11:59 EST
fedup-0.8.0-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/fedup-0.8.0-3.fc19
Comment 10 Fedora Update System 2013-12-11 17:20:15 EST
fedup-0.8.0-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/fedup-0.8.0-3.fc20
Comment 11 Fedora Update System 2013-12-11 17:22:08 EST
fedup-0.8.0-3.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/fedup-0.8.0-3.fc18
Comment 12 Fedora Update System 2013-12-13 00:09:24 EST
Package fedup-0.8.0-3.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing fedup-0.8.0-3.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-23316/fedup-0.8.0-3.fc19
then log in and leave karma (feedback).
Comment 13 Fedora Update System 2013-12-19 02:21:53 EST
fedup-0.8.0-3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 14 Fedora Update System 2013-12-19 20:44:20 EST
fedup-0.8.0-3.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 15 Fedora Update System 2013-12-22 00:34:28 EST
fedup-0.8.0-3.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 16 Will Woods 2014-01-13 13:09:12 EST
*** Bug 902555 has been marked as a duplicate of this bug. ***

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