Description of problem: Instead of the upgrade process starting, I´m getting a normal login on tty1, and I´m logged in as root on tty2. On tty2, the following message is shown: system-upgrade:/# mktemp: failed to create file via template '/tmp/.colorlsXXX': Read-only file system bash: $TMP: ambiguous redirect /tmp is on a seperate partition. I have commented out the entry for /tmp in /etc/fstab and rebooted into the upgrade entry. That gives me a normal login on tty1, and I´m logged in as root on tty2 without the error message. However, the upgrade process still does not start. Version-Release number of selected component (if applicable): fedup 0.8, trying to upgrade from F19 to F20 How reproducible: Steps to Reproduce: 1. yum update 2. reboot (latest kernel) 3. fedup --network 20 4. reboot (upgrade entry) Actual results: see above Expected results: I expected the upgrade process to start. Additional info: /var/log/fedup.log doesn´t seem to show anything relevant. /tmp is writeable for everyone. root does have write access to /tmp from the login on tty2 after booting the upgrade entry. Booting into a GUI is disabled because I don´t want that.
see also Bug 1045133 Apparently others encounter the same problem. Is there a way to start the upgrading process manually after booting into the upgrade entry?
Looking at Bug 1045847: Perhaps I need to add some boot parameters as hinted in https://bugzilla.redhat.com/show_bug.cgi?id=1045847#c3 . There is no entry for an upgrade target in grubs configuration. After adding upgrade systemd.unit=system-upgrade.target enforcing=0 to the upgrade entry in grubs configuration, the update has gone through. There were some selinux related warnings, appartenly about denying access to some files, which scrolled out too fast to read them. Hopefully, this won´t cause problems. Suggestion: Please add a note about adding the upgrade target to grubs configuration to the release notes and to the documentation about upgrading with fedup (until this problem is fixed). This bug report can then be closed.
(In reply to lee from comment #1) > see also Bug 1045133 > > Apparently others encounter the same problem. Is there a way to start the > upgrading process manually after booting into the upgrade entry? In the fedup rpm are some systemd service files and a script that is called. Maybe we can try that script to see how fare it works? (first go to runlevel one, etc, etc)
The problem may be related to the modification of the defaults for the kernel boot parameters. For example, I have changed the default for my kernel command line to remove the "rhgb quiet" options because I hate not seeing what is going on. So the file /etc/default/grub seems to be applied AFTER the fedup script makes its changes to the /boot/grub2/grub.cfg file and reverts the configuration.
*** Bug 1045133 has been marked as a duplicate of this bug. ***
Upgrades to F20 using fedup-0.8.x do not require the "upgrade systemd.unit=..." boot arguments. Your system detects that you've booted the upgrade.img and switches the default target automatically.
*** Bug 1045847 has been marked as a duplicate of this bug. ***
*** Bug 1046040 has been marked as a duplicate of this bug. ***
*** Bug 1045721 has been marked as a duplicate of this bug. ***
I think multiple bugs have been mixed together here. Two questions for everyone: 1) Does your system *hang* trying to start the upgrade, or does it boot *normally* (without starting the upgrade)? 2) If hang: are you using either LUKS (encrypted disks) or software RAID? If normal boot: do you have a separate /var partition?
(In reply to Will Woods from comment #10) > 1) Does your system *hang* trying to start the upgrade, or > does it boot *normally* (without starting the upgrade)? It boots mostly normally to a mostly functional system. The most noticeable difference during boot is the systemd logs (instead of the default loading screen) and stuff like network don't work (see bug 1046040).
(In reply to Will Woods from comment #10) > 1) Does your system *hang* trying to start the upgrade, or > does it boot *normally* (without starting the upgrade)? Cfr. https://bugzilla.redhat.com/show_bug.cgi?id=1045847#c0 : "... fedup 0.8.0-3 creates a grub2 entry, but does not append the upgrade arguments, resulting in a standard F-19 boot ..."
Can someone please document the steps to manually edit the grub.cfg file if the new-kernel-pkg command fails?
(In reply to Will Woods from comment #10) > I think multiple bugs have been mixed together here. > > Two questions for everyone: > > 1) Does your system *hang* trying to start the upgrade, or > does it boot *normally* (without starting the upgrade)? > > 2) If hang: are you using either LUKS (encrypted disks) or software RAID? > If normal boot: do you have a separate /var partition? My system boots normally (without starting the upgrade) with the error 'Failed to Start RPCbind Service'. The F-20 kernel is running but everything else appears to be F-19. /var is a separate filesystem using lvm.
(In reply to Jim Sarset from comment #14) > (In reply to Will Woods from comment #10) > > I think multiple bugs have been mixed together here. > > > > Two questions for everyone: > > > > 1) Does your system *hang* trying to start the upgrade, or > > does it boot *normally* (without starting the upgrade)? > > > > 2) If hang: are you using either LUKS (encrypted disks) or software RAID? > > If normal boot: do you have a separate /var partition? > > My system boots normally (without starting the upgrade) with the error > 'Failed to Start RPCbind Service'. The F-20 kernel is running but everything > else appears to be F-19. /var is a separate filesystem using lvm. I have a similar issue: no error in the preparation neither in the boot. But, instead of the upgrade screen, I get a normal prompt with kernel fc20 and everything else fc19. I do not have lvm and /home is the only separate filesystem
I experienced this bug as follows: * `fedup --network 20` runs without errors (and /var/log/fedup.log finished "... exited cleanly" * boot into "System upgrade" proceeds without errors but hangs after "Mounted /home" * can then switch to TTY1 and see that mountpoints exist etc. (but nothing new in /var/log at all) * nothing further happens... Rebooting with "enforcing=0" allows the upgrade to proceed as expected. fedup-0.8.0-4 (and selinux-policy-targeted seems to be installed correctly) If nothing else it would be great if someone could comment on how to get further diagnostic info when stuck in an inactive "System upgrade" boot.
(In reply to Carl van Tonder from comment #16) > Rebooting with "enforcing=0" allows the upgrade to proceed as expected. If you have multiple LUKS partitions and "enforcing=0" fixes your problem, that's bug 1045864. If you have a separate /var partition, that's bug 1045168 (and probably "enforcing=0" didn't do anything). > If nothing else it would be great if someone could comment on how to get > further diagnostic info when stuck in an inactive "System upgrade" boot. There's a shell on tty2 you can use for diagnostics. You might look at the `systemctl` output to see what job(s) have failed or are trying to start. You should also examine `journalctl -b` to see if there are any obvious errors near the end (esp. messages from upgrade-prep.sh). Without knowing more about your system I can't really tell you what to look for, but you could save the output of both commands to a log file, and then attach it here. Something like: ( systemctl; journalctl -b ) > /root/upgrade-hang.log should do. (substitute `dmesg` for `journalctl -b` if journalctl says the journal is missing/empty)
Will, thanks for the advice. From your description I expect it's bug 1045865. Unfortunately, I had needed to get my PC back in action (with the enforcing=0 workaround) by the time you replied, but it's very useful to have that info for next time.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. 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 20 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.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. 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 21 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.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 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.