rpm-software-management / dnf-plugin-system-upgrade Goto Github PK

A DNF plugin for system upgrades (moved to dnf-plugins-extras!)

License: GNU General Public License v2.0

Makefile 6.74% Python 92.45% Shell 0.81%

dnf-plugin-system-upgrade's Introduction

⚠️ NOTE: this repo is obsolete ⚠️

The system-upgrade plugin was moved to the dnf-plugins-core repo in 2022 (and before that was moved into the dnf-plugins-extras repo in 2017).

Please direct all patches, issues, etc. there instead.

(The original README.md is preserved below because it has some useful tips.)

dnf-plugin-system-upgrade

A plugin for DNF that does fedup-style upgrades using systemd's Offline Updates facility.

Installation

make install

Example Usage

To download everything needed to upgrade to Fedora 23:

# dnf system-upgrade download --releasever=23

Once that finishes, you can begin the upgrade process:

# dnf system-upgrade reboot

There's also a fedup-compatible wrapper script, so this works too:

# fedup --network 23
# fedup reboot

Testing Tips

Finding upgrade logs

Everything printed by dnf during the upgrade is in the system journal. Run dnf system-upgrade log to see a list of boots during which an upgrade was attempted. Use dnf system-upgrade log [NUM], where [NUM] is usually -1, to see the logs for that boot using journalctl.

Enable debug shell on `/dev/tty9`

If you'd like a root shell available during the upgrade, add systemd.debug-shell to your boot arguments.

You can also enable the shell for all system updates/upgrades:

# systemctl add-wants system-update.target debug-shell.service

Switch to the shell with Ctrl-Alt-F9 and back to the upgrade progress with Ctrl-Alt-F1.

In case of boot problems

If the system gets stuck at system-update.target without starting the upgrade, remove /system-update to make the system boot normally.

If you don't have the debug shell available, you can use the dracut emergency shell; add rd.break to the boot args, then:

# mount -o remount,rw /sysroot
# rm /sysroot/system-update

Exit the shell and your system should start normally.

Reporting bugs

Problems can be reported through

github issues — problems with the plugin itself and feature requests: new issue,

or through

the Fedora bug tracker — upgrade problems and integration with the rest of the distribution: new bug.

Please include /var/log/dnf.log and the output of dnf system-upgrade log -1 (if applicable) in your bug reports.

Problems with dependency solving during download are best reported to the maintainers of the package(s) with the dependency problems.

Similarly, problems encountered on your system after the upgrade completes should be reported to the maintainers of the affected components. In other words: if (for example) KDE stops working, it's best if you report that to the KDE maintainers.

dnf-plugin-system-upgrade's People

Contributors

Stargazers

Watchers

dnf-plugin-system-upgrade's Issues

Updating DNF can cause the upgrade to do nothing

Something about updating from DNF 1.0.x to 1.1.x seems to remove the cached metadata (or change the metadata policy). So if you do:

dnf system-upgrade download --releasever 23
dnf upgrade dnf
dnf system-upgrade reboot

The upgrade starts OK, but then DNF says "Nothing to do", and we clean up (possibly deleting all the downloaded packages) and reboot.

Probably we need to check validity of the packages/metadata when doing reboot, and reset state.download_status if needed.

We might also need to do something to prevent DNF from removing our metadata once the upgrade is ready.

propagate `--exclude` to upgrade transaction

If someone uses --exclude or -x to prune packages from the transaction during download, we need to do the same thing during the upgrade or we won't get the same transaction.

So either we need a reliable way to save/restore the transaction, or we need to pass along the --excludes so we can reconstruct the transaction.

dnf system-upgrade reboot starts the upgrade but fails

System doesn't get upgraded when I do the dnf system-upgrade reboot
While rebooting, it does show. "Upgrading system, this may take a while" for 10-15 sec but then reboots into older version
I am trying to shift to rawhide from F26
This is the relevant system upgrade log - https://paste.fedoraproject.org/paste/gzMF-9OMv97HJd8gdWzLqQ

distro-sync as default behavior?

Please enable distro-sync mode by default. One of the major hopes I had for dnf-plugin-system-upgrade was to have finally functional distro-sync mode. The lack of distro-sync caused us endless issues with fedup ugprades. Maintainers can't be expected to keep upgrade path when Branched is frozen towards the release. We need to sync to Branched versions.

This has been discussed here [1] and people seemed to agree that distro-sync is the better default.

Also, dnf now resolves broken deps differently then fedup. Fedup used to download the target packages and force-install them, even if deps were broken. DNF now skips packages recursively, if they are broken. The end result is that if there's an upgrade path inconsistency in one of major system packages (like systemd, gtk, etc), people might end up with half system upgraded and half system old, because the packages were skipped due to broken deps. I don't see any other way to prevent this except for distro-sync mode. We need to make upgrades more reliable.

Please change --distro-sync option to something like --no-distro-sync option and set distro-sync as default. Thanks.

[1] http://lists.rpm.org/pipermail/rpm-ecosystem/Week-of-Mon-20150727/000180.html

"Error: system is not ready for upgrade" is not helpful

We're getting a lot of feedback from people who try to run dnf system-upgrade reboot and get

Error: system is not ready for upgrade

I think that often happens when you perform some other dnf operation after downloading the packages, which invalidates them (and rightfully so). But the error itself is not very helpful, people are confused and don't know what to do. Please make it more explanatory. What about:

Error: system is not ready for upgrade. This often happens when FIXME. Please try to start system-upgrade procedure from scratch (downloading the packages first).

traceback on invalid option

Not a big issue, but it would be nice to suppress the traceback, and only print the error message:

[test@fedora22 ~]$ sudo dnf system-upgrade --releasever 23 download --distrosync
Traceback (most recent call last):
  File "/bin/dnf", line 36, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 198, in user_main
    errcode = main(args)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 84, in main
    return _main(base, args)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 117, in _main
    cli.configure(map(ucd, args))
  File "/usr/lib/python2.7/site-packages/dnf/cli/cli.py", line 1029, in configure
    self.command.configure(self.base.extcmds)
  File "/usr/lib/python2.7/site-packages/dnf-plugins/system_upgrade.py", line 263, in configure
    self.opts = self.parse_args(args)
  File "/usr/lib/python2.7/site-packages/dnf-plugins/system_upgrade.py", line 254, in parse_args
    opts = p.parse_args(extargs)
  File "/usr/lib64/python2.7/argparse.py", line 1704, in parse_args
    self.error(msg % ' '.join(argv))
  File "/usr/lib/python2.7/site-packages/dnf-plugins/system_upgrade.py", line 206, in error
    raise AttributeError(message)
AttributeError: unrecognized arguments: --distrosync

dnf-1.1.1-2.fc22.noarch
dnf-plugin-system-upgrade-0.4.1-1.fc22.noarch

--refresh should be implied

I have just run this:

$ sudo dnf system-upgrade download --releasever=24 --allowerasing

and was shown this:

Downloading Packages:
[MIRROR] audit-libs-python3-2.5-3.fc24.x86_64.rpm: Status code: 404 for http://download.eng.brq.redhat.com/pub/fedora/linux/development/24/Everything/x86_64/os/Packages/a/audit-libs-python3-2.5-3.fc24.x86_64.rpm
[MIRROR] audit-2.5-3.fc24.x86_64.rpm: Status code: 404 for http://download.eng.brq.redhat.com/pub/fedora/linux/development/24/Everything/x86_64/os/Packages/a/audit-2.5-3.fc24.x86_64.rpm
[MIRROR] audit-libs-2.5-3.fc24.x86_64.rpm: Status code: 404 for http://download.eng.brq.redhat.com/pub/fedora/linux/development/24/Everything/x86_64/os/Packages/a/audit-libs-2.5-3.fc24.x86_64.rpm
[MIRROR] audit-libs-python3-2.5-3.fc24.x86_64.rpm: Curl error (78): Remote file not found for ftp://mirror.vutbr.cz/fedora/development/24/Everything/x86_64/os/Packages/a/audit-libs-python3-2.5-3.fc24.x86_64.rpm [RETR response: 550]
[MIRROR] audit-2.5-3.fc24.x86_64.rpm: Curl error (78): Remote file not found for ftp://mirror.vutbr.cz/fedora/development/24/Everything/x86_64/os/Packages/a/audit-2.5-3.fc24.x86_64.rpm [RETR response: 550]
[MIRROR] audit-libs-2.5-3.fc24.x86_64.rpm: Curl error (78): Remote file not found for ftp://mirror.vutbr.cz/fedora/development/24/Everything/x86_64/os/Packages/a/audit-libs-2.5-3.fc24.x86_64.rpm [RETR response: 550]
[MIRROR] audit-2.5-3.fc24.x86_64.rpm: Status code: 404 for http://mirror.vutbr.cz/fedora/development/24/Everything/x86_64/os/Packages/a/audit-2.5-3.fc24.x86_64.rpm
[MIRROR] audit-libs-2.5-3.fc24.x86_64.rpm: Status code: 404 for http://mirror.vutbr.cz/fedora/development/24/Everything/x86_64/os/Packages/a/audit-libs-2.5-3.fc24.x86_64.rpm
[MIRROR] audit-libs-python3-2.5-3.fc24.x86_64.rpm: Status code: 404 for http://mirror.vutbr.cz/fedora/development/24/Everything/x86_64/os/Packages/a/audit-libs-python3-2.5-3.fc24.x86_64.rpm
[MIRROR] audit-libs-2.5-3.fc24.x86_64.rpm: Status code: 404 for http://mirror.slu.cz/fedora/linux/development/24/Everything/x86_64/os/Packages/a/audit-libs-2.5-3.fc24.x86_64.rpm
[MIRROR] audit-2.5-3.fc24.x86_64.rpm: Status code: 404 for http://mirror.slu.cz/fedora/linux/development/24/Everything/x86_64/os/Packages/a/audit-2.5-3.fc24.x86_64.rpm
[MIRROR] audit-libs-python3-2.5-3.fc24.x86_64.rpm: Status code: 404 for http://mirror.slu.cz/fedora/linux/development/24/Everything/x86_64/os/Packages/a/audit-libs-python3-2.5-3.fc24.x86_64.rpm
[MIRROR] audit-libs-2.5-3.fc24.x86_64.rpm: Curl error (78): Remote file not found for ftp://mirror.slu.cz/fedora/linux/development/24/Everything/x86_64/os/Packages/a/audit-libs-2.5-3.fc24.x86_64.rpm [RETR response: 550]
[MIRROR] audit-2.5-3.fc24.x86_64.rpm: Curl error (78): Remote file not found for ftp://mirror.slu.cz/fedora/linux/development/24/Everything/x86_64/os/Packages/a/audit-2.5-3.fc24.x86_64.rpm [RETR response: 550]
[MIRROR] audit-libs-python3-2.5-3.fc24.x86_64.rpm: Curl error (78): Remote file not found for ftp://mirror.slu.cz/fedora/linux/development/24/Everything/x86_64/os/Packages/a/audit-libs-python3-2.5-3.fc24.x86_64.rpm [RETR response: 550]
[MIRROR] audit-2.5-3.fc24.x86_64.rpm: Downloading successful, but checksum doesn't match. Calculated: 8feebc27aa326861bdd5197496f28ed3f90d6ea5ce710243b4f954b97d614198(sha256)  Expected: dc7702ad7525a7e35cd45987effb86a4a128fd36dc43f7f5f1e7665085ee4ed5(sha256) 
[MIRROR] audit-libs-2.5-3.fc24.x86_64.rpm: Downloading successful, but checksum doesn't match. Calculated: 8feebc27aa326861bdd5197496f28ed3f90d6ea5ce710243b4f954b97d614198(sha256)  Expected: 809b3b95321f1e95da4eadd1d57ec7143dc0d1a148b2c7e1e09f09be475b95ee(sha256) 
[MIRROR] audit-libs-python3-2.5-3.fc24.x86_64.rpm: Downloading successful, but checksum doesn't match. Calculated: 8feebc27aa326861bdd5197496f28ed3f90d6ea5ce710243b4f954b97d614198(sha256)  Expected: 274859efd0681df4c9aaa6f6066aff743f95981340e9b7988c61f33b2ddef84a(sha256) 
[MIRROR] audit-2.5-3.fc24.x86_64.rpm: Curl error (78): Remote file not found for ftp://ftp.halifax.rwth-aachen.de/fedora/linux/development/24/Everything/x86_64/os/Packages/a/audit-2.5-3.fc24.x86_64.rpm [RETR response: 550]
[MIRROR] audit-libs-2.5-3.fc24.x86_64.rpm: Curl error (78): Remote file not found for ftp://ftp.halifax.rwth-aachen.de/fedora/linux/development/24/Everything/x86_64/os/Packages/a/audit-libs-2.5-3.fc24.x86_64.rpm [RETR response: 550]
[MIRROR] audit-libs-python3-2.5-3.fc24.x86_64.rpm: Curl error (78): Remote file not found for ftp://ftp.halifax.rwth-aachen.de/fedora/linux/development/24/Everything/x86_64/os/Packages/a/audit-libs-python3-2.5-3.fc24.x86_64.rpm [RETR response: 550]
[MIRROR] audit-2.5-3.fc24.x86_64.rpm: Status code: 404 for http://ftp.halifax.rwth-aachen.de/fedora/linux/development/24/Everything/x86_64/os/Packages/a/audit-2.5-3.fc24.x86_64.rpm

(and on and on and on, I hit Ctrl+C after a minute or so)

When I executed the same command again but with --refresh, everything went fine and packages were correctly downloaded.

General users don't know this, so let's avoid it. When running system-upgrade, always imply --refresh. Because when doing a distro upgrade, we always want to make sure we have the latest metadata and latest packages.

dnf-plugin-system-upgrade-0.7.1-1.fc23.noarch

"You can removed cached packages..." message is a lie

So DNF 1.1.0, at the end of the download, says:

Download complete! Use 'dnf system-upgrade reboot' to start the upgrade.
The downloaded packages were saved in cache till the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.

The first line is printed by the plugin, the latter two lines are printed by DNF itself.

But: (AFAIK) dnf clean packages actually won't remove the downloaded packages, because it doesn't know that we stashed them in our own datadir instead of the normal cachedir.

So: we should suppress this message, and/or suggest dnf system-upgrade clean instead.

'systemctl reboot' at end of upgrade returns.. -15?

After the upgrade completes, we try to run systemctl reboot, but for some reason it exits with the mysterious (and suspicious) exit code -15, causing a traceback:

Traceback (most recent call last):
File "/usr/bin/dnf", line 36, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 193, in user_main
    errcode = main(args)
File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 84, in main
    return _main(base, args)
File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 150, in _main
    cli.command.run_transaction()
File "/usr/lib/python2.7/site-packages/dnf-plugins/system_upgrade.py", line 257, in run_transaction
    self._call_sub("transaction")
File "/usr/lib/python2.7/site-packages/dnf-plugins/system_upgrade.py", line 262, in _call_sub
    subfunc(*args)
File "/usr/lib/python2.7/site-packages/dnf-plugins/system_upgrade.py", line 410, in transaction_upgrade
    reboot()
File "/usr/lib/python2.7/site-packages/dnf-plugins/system_upgrade.py", line 59, in reboot
    check_call(["systemctl", "reboot"])
File "/usr/lib64/python2.7/subprocess.py", line 540, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['systemctl', 'reboot']' returned non-zero exit status -15

Luckily, this failure causes the system to reboot anyway, as shown in the logs:

dnf[622]: Complete!
dnf[622]: Cleaning up downloaded data...
dnf[622]: Traceback (most recent call last):
          [traceback]
systemd[1]: dnf-system-upgrade.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: Stopped System Upgrade.
systemd[1]: dnf-system-upgrade.service: Unit entered failed state.
systemd[1]: dnf-system-upgrade.service: Failed with result 'exit-code'.
systemd[1]: Rebooting as result of failure.

But that's pretty weird. We use the same reboot() function in dnf system-upgrade reboot, so we know it works outside of the upgrade. So: why would systemctl reboot return -15 at the end of the upgrade?

Maybe the upgrade itself is the cause of the problem, since we (might) be mixing a new systemctl with an older systemd? Maybe re-executing systemd before reboot would fix this?

We should investigate and figure this out!

print system-upgrade version to stdout and dnf.log

As I learned today by spending way too much time on bug 1277894, due to some unfortunate timing many people used old system-upgrade version to upgrade their F22 to F23. However, it's often hard to figure out this from the logs. Lets make this more obvious.

Please print system-upgrade version every time the plugin is used (dnf is called as dnf system-upgrade ...). Lets print it to both stdout and dnf.log, if possible. Thanks!

Upgrade process fails with ENOENT

After dnf reboot, the system boots twice without installing anything, I have the following logs:

sept. 24 14:19:16 Fedora dnf[232]: [Errno 2] No such file or directory
sept. 24 14:19:16 Fedora systemd[1]: dnf-system-upgrade.service: main process exited, code=exited, status=1/FAILURE

This is from an up-to-date Fedora 22.
It's a fairly small VM, maybe some implicit dependencies are missing?

Can't load plugin in f22 with Chinese locale

Hi, my language environment is zh_CN.utf8, with using the latest version 0.7.0-1 in dnf
I will got
Traceback (most recent call last):
File "/bin/dnf", line 36, in
main.user_main(sys.argv[1:], exit_code=True)
File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 198, in user_main
errcode = main(args)
File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 84, in main
return _main(base, args)
File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 117, in _main
cli.configure(map(ucd, args))
File "/usr/lib/python2.7/site-packages/dnf/cli/cli.py", line 1006, in configure
self.base.plugins.run_init(self.base, self)
File "/usr/lib/python2.7/site-packages/dnf/plugin.py", line 104, in run_init
plugin = p_cls(base, cli)
File "/usr/lib/python2.7/site-packages/dnf-plugins/system_upgrade.py", line 359, in init
super(SystemUpgradePlugin, self).init(base, cli)
TypeError: must be type, not None

But if I use the LANG=C, it would work

Error upgrading fedora 22 to 23

After running: dnf system-upgrade download --releasever=23, I get the following error.

Error: Transaction check error:
file /usr/lib/systemd/system-preset/90-default.preset from install of fedora-release-23-0.15.noarch conflicts with file from package systemd-219-21.fc22.x86_64

debug output is duplicated

When I hit an arrow/esc during the upgrade to see the details, every package update seems to be printed twice, differently formatted. See screenshot.

dnf-plugin-system-upgrade-0.4.0-1.fc22

require versioned python library

In the spec file there's this:

%if 0%{?fedora} >= 23
# DNF in Fedora 23 uses Python 3 by default
Requires: python3-%{name}
%else
Requires: python2-%{name}
%endif

And so when we instruct people to use the latest system-upgrade from updates-testing, they do this:

sudo dnf update dnf-plugin-system-upgrade --enablerepo=updates-testing

which will not update python*-dnf-plugin-system-upgrade. See here:

OK.... That did improve things... But one thing to note....
I updated dnf-plugin-system-upgrade from updates-testing but it did NOT pull-in
python2-dnf-plugin-system-upgrade. Without pulling in python2-dnf-plugin-system-upgrade
the issues I had still remained.
https://lists.fedoraproject.org/pipermail/test/2015-November/128413.html

Please use a versioned python dependency in the spec file, thanks.

upgrade in offline mode to another PC F37->F38

There is a magic plugin "dnf-plugin-system-upgrade" which has magic commands but still can't see differences in using commands system-upgrade and offline-upgrade.
I have my Fedora37 OS customized to my preferences then I do the steps:

#dnf update
#reboot
#dnf system-upgrade download --releasever=38
#dnf system-upgrade reboot

The upgrade is done well when rebooting. The following commands give me same results and I cant see the differences

#dnf update
#reboot
#dnf offline-upgrade download --releasever=38
#dnf offline-upgrade reboot

The first question is: what is the difference between the two procedure for upgrade as soon as I get same results?

But the main problem is here in following procedure.

#dnf update
#reboot
#dnf offline-upgrade download --releasever=38

at this step I get the entire folder /var/lib/dnf with all my downloaded packages and replace it to another PC which is in offline then I give the next command.
#dnf offline-upgrade reboot
the system is rebooting but not in upgrading mode, give some errors then booting without upgrade. Is it something missed somewhere else than dnf folder?

So the question is, never found on internet, how to upgrade in offline mode replicated to another PC not the one which is in online. What something else is missing as soon as I have all packages in dnf folder.

use unicode strings everywhere

At the beginning of the plugin should be from __future__ import unicode_literals. This will break the other things though and needs to be fixed on more places.
see https://bugzilla.redhat.com/show_bug.cgi?id=1262082 which failed due to non unicoded characters in system-upgrade command.
We have fixed this in DNF (rpm-software-management/dnf@9e8638d) but the common practice is to use Unicode everywhere and convert bytestring to Unicode as soon as possible.

dnf system-upgrade reboot fails: unable to upgrade from f26 to f27

This is what I find in /var/log/dnf.log:

2017-11-14T17:56:17Z DEBUG Kann nicht herunterladen 'https://mirrors.fedoraproject.org/metalink?repo=updates-released-f27
&arch=x86_64': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for https://mirrors.fedorap
roject.org/metalink?repo=updates-released-f27&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org].
2017-11-14T17:56:17Z DDEBUG Cleaning up.
2017-11-14T17:56:17Z SUBDEBUG
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/dnf/repo.py", line 229, in _perform
    return super(_Handle, self).perform(result)
  File "/usr/lib64/python3.6/site-packages/librepo/__init__.py", line 1522, in perform
    _librepo.Handle.perform(self, result)
librepo.LibrepoException: (8, "Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for https:/
/mirrors.fedoraproject.org/metalink?repo=updates-released-f27&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.
org]", 'An Curl handle error')

However, on my command line, curl works:

$ curl https://mirrors.fedoraproject.org/metalink?repo=updates-released-f27&arch=x86_6
<?xml version="1.0" encoding="utf-8"?>
<metalink version="3.0" xmlns="http://www.metalinker.org/" type="dynamic" pubdate="Tue, 14 Nov 2017 18:51:33 GMT" generator="mirrormanager" xmlns:mm0="http://fedorahosted.org/mirrormanager">
<!--
# either path=, or repo= and arch= must be specified
-->
</metalink>

I tried if this a IPv6 problem in the line of https://ask.fedoraproject.org/en/question/32319/could-not-resolve-host-mirrorsfedoraprojectorg/ but:

$ curl -6 https://mirrors.fedoraproject.org/metalink?repo=updates-released-f27&arch=x86_6
<?xml version="1.0" encoding="utf-8"?>
<metalink version="3.0" xmlns="http://www.metalinker.org/" type="dynamic" pubdate="Tue, 14 Nov 2017 18:53:36 GMT" generator="mirrormanager" xmlns:mm0="http://fedorahosted.org/mirrormanager">
<!--
# either path=, or repo= and arch= must be specified
-->
</metalink>

crash after sudo dnf system-upgrade reboot

Upgrade to fc24 from 4.5.7-200.fc23.x86_64
After download package, execute 'sudo dnf system-upgrade reboot'
I don't see new option in grub as fedup did befoe, which is expected.
System boots but immediately crash and reboot.
How can I grab the log of boot? It is too fast to see error message.
thanks.

obsolete fedup-dracut-plymouth.noarch too.

After upgrade my system, dnf list extras show that fedup-dracut-plymouth was not deleted, I think that also should be obsoleted by dnf-plugin-system-upgrade

Thanks

disable screen blanking during system upgrade in text mode

If you don't have plymouth or switch from graphical splash to text mode during system-upgrade, the screen will blank in 10 minutes (default timeout for screen blanking). Quite interestingly, it will not turn blank right away, but columns of characters gradually disappear before the screen is black.

Either way, it's a good idea to disable screen blanking during system upgrade, the same way we disable it during system installation. Otherwise some people might get confused and harm the upgrade process unintentionally. Please call:

setterm -blank 0

at the beginning of the upgrade process. That should disable screen blanking. Thanks.

No update or progress indication at all

Please have a look at https://bugzilla.redhat.com/show_bug.cgi?id=1317195 for details.

Under some conditions (details unclear), there is no progress indication for the system-upgrade dnf plugin at all.

[WSL] System has not been booted with systemd as init system (PID 1). Can't operate.

I installed fedora 35 as a WSL distribution following this guide: https://dev.to/bowmanjd/install-fedora-on-windows-subsystem-for-linux-wsl-4b26

Then, I tried to follow these instructions to upgrade to 36: https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/

Here is the error I received:

$ sudo dnf system-upgrade download --releasever=36
$ sudo dnf system-upgrade reboot
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

I found the system-upgrade upgrade command, ran it, and that seemed to work.

document where to find logs and what to provide in bug report

Please document in the README where to look for logs for failed upgrade runs, and what to attach to bug reports. You'll make your life easier when people report problems, and you'll make our life easier when trying to find out where all the important pieces are stored. Thanks.

Also, please consider creating a separate system-upgrade.log. It would make debugging and bug reporting so much easier.

include "reporting problems" section in github's readme

There's this section in man dnf.plugin.system-upgrade:

REPORTING BUGS
       Bugs should be filed here:

              https://bugzilla.redhat.com/

       For more info on filing bugs, see the Fedora Project wiki:

              https://fedoraproject.org/wiki/How_to_file_a_bug_report
              https://fedoraproject.org/wiki/Bugs_and_feature_requests

       Please include /var/log/dnf.log and the output of dnf system-upgrade log -1 (if applicable) in your bug reports.

       Problems with dependency solving during download are best reported to the maintainers of the package(s) with the dependency prob‐
       lems.

       Similarly,  problems encountered on your system after the upgrade completes should be reported to the maintainers of the affected
       components.  In other words: if (for example) KDE stops working, it's best if you report that to the KDE maintainers.

However, this text is not online anywhere, so I can't link to it easily, when telling people how to report problems. Please include the same section in the readme here on github.

please create version for el7 and el8 on epel

please it's a real mess to update

centos 7 to 8 or 8 to 9

with the conflicts

please create dnf-plugin-system-upgrade for this version

and publish it on epel please thank you

Upgrade to version 26 process froze

I waited awhile for it to finish upgrading the Thunderbird package then I walked away for supper returning about 30 minutes later, it was still on that step.

Because I couldn't ctrl-C out of it, I closed the terminal. then rebooted.

Now when I run the dnf command it reports that "Failed loading plugin: system_upgrade" ,
It doesn't exist in /usr/lib/python3.5 or /usr/lib/python3.6 but does in /usr/lib/python2.7.
I tried reinstalling it again but it indicated that "python3-dnf-plugins-extras-system-upgrade-0.10.0-1.fc26.noarch is already installed" and when I tried reinstalling the package, it indicated it isn't available.

Is there a way to repair, downgrade, clean the dnf database to return it to version 25? Dnf check reports a large number of conflicting files between fc25 and fc26.

Thanks
Ernie Wagner

promote "fedup" as primary documented command?

I dunno if github is the best place for this, but since the feature page links to a bunch of things here, I figure, why not?

I'd like to suggest that we continue to refer to the process of updating a Fedora system as "using FedUp", and to document the process as "run fedup".

Rationale:

FedUp has gotten a lot of positive press recently, including this interview with Jim Whitehurst
Although the mechanisms are different, the basic concepts, especially from a user point of view, are very similar
Documentation won't need (as much) updating
fedup.sh is already done
FedUp is an awesome name
People get all stabby over changes. Let's save it for when we really need it. (This is more serious than it sounds; I'd like to reduce the perception that Feodora = constant pointless churn.)

Add extra diskspace check

For various reasons (huge number of packages, scriptlet data, rounding errors, differing block sizes, inaccurate reserved space calculations, etc.) the RPM diskspace check performed during a test transaction is far more likely to return a false positive (success) for system upgrades than normal update transactions.

A few users who were very close to the amount of free space required have hit false positives and had trouble upgrading - see e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1295213

It might be safer if we added an extra diskspace check to the system-upgrade plugin which pads the required disk space by a configurable amount - like "10%" or "20MB" - probably defaulting to 10% or so. anaconda does something like this during installation (see DNFPayload._spaceRequired()) but that calculation is specific to new installations, and upgrades generally don't create as many new files, so the plugin would probably need an upgrade-specific fudge factor.

Oh, and obviously this would need a configuration option and CLI flag so users who are certain they have enough disk space to proceed can change or disable the extra check.

RFE: prompt or cancelable delay on reboot command

I'm seeing some feedback like this from this article on upgrading Fedora :

This will trigger a reboot (immediately - you might be startled by how suddenly it reboots, so make sure you are ready)

Could we make this command prompt to continue (unless -y is given)?

reboot and upgrade does not appear to work

the reboot process will run startup load fedora and then just restart immediately after that. I'm pretty sure the reboot upgrade process did not quite work on my system.

Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 121, in _main
cli.check()
File "/usr/lib/python2.7/site-packages/dnf/cli/cli.py", line 1036, in check
self.command.doCheck(self.base.basecmd, self.base.extcmds)
File "/usr/lib/python2.7/site-packages/dnf-plugins/system_upgrade.py", line 251, in doCheck
self._call_sub("check", basecmd, extcmds)
File "/usr/lib/python2.7/site-packages/dnf-plugins/system_upgrade.py", line 262, in _call_sub
subfunc(*args)
File "/usr/lib/python2.7/site-packages/dnf-plugins/system_upgrade.py", line 323, in check_upgrade
if os.readlink(MAGIC_SYMLINK) != self.state.datadir:
OSError: [Errno 2] No such file or directory: '/system-update'

it looks like the /system-update folder is never actually created.

help page improvements

When I display help like this, most of important information is missing, like supported options:

$ sudo dnf help system-upgrade 
system-upgrade [OPTIONS] [download --releasever=VERSION|reboot|clean]

Prepare system for upgrade to a new release

alias: fedup

When I display it like this, it's much better, but it does not document --releasever option, which is essential in order to perform an upgrade:

$ sudo dnf system-upgrade 
usage: dnf system-upgrade [--distro-sync] [--datadir DATADIR]
                          {download,clean,reboot,upgrade}

positional arguments:
  {download,clean,reboot,upgrade}
                        action to perform

optional arguments:
  --distro-sync         downgrade packages if the new release's version is
                        older
  --datadir DATADIR     save downloaded data to this location
Error: too few arguments

Could both help outputs look the same, and document --releasever option? Thanks.

add tmpfiles snippet to remove downloaded packages after some time

If a user attempts a download, but never goes through with it, a large amount of disk space can be wasted. Downloaded packages should be automatically rotated after some time (2 weeks?).

System upgrade is stuck on boot, renders whole PC unusable

I tried upgrading F22 to F23 using dnf plugin. I used these steps:
https://fedoraproject.org/wiki/Changes/DNF_System_Upgrades#How_To_Test
First I used the plugin from the copr repo: dnf-plugin-fedup-0-2.20150716git6d6a316.fc22.noarch. That worked well, but didn't run in distro-sync mode - after upgrade, there were packages to be downgraded to F23 version.

Then I realized how old that plugin is and tried it once again using current git version (5f62542). That didn't work at all. The system is stuck on boot into the offline upgrade process. This is all I see:

How can I provide more useful details?

The biggest problem is that I have no way to boot the original system. No matter which kernel I select, it always gets stuck, because I assume it always tries to upgrade. I can't even boot the rescue kernel, it has the same issue. We really, really need a separate upgrade boot option in grub which runs the upgrade process, and if it fails to start for any reason like the one above, people can simply boot to their original system. Currently, any bug in system-upgrade plugin will render their whole PC unusable. That will be seen very harshly by our users.

UnicodeDecodeError on invalid argument options

When executing dnf system-upgrade with an invalid argument option (e.g. dnf system-upgrade --foobar) dnf crashes with following TraceBack:

Traceback (most recent call last):
  File "/bin/dnf", line 36, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 198, in user_main
    errcode = main(args)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 84, in main
    return _main(base, args)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 117, in _main
    cli.configure(map(ucd, args))
  File "/usr/lib/python2.7/site-packages/dnf/cli/cli.py", line 1033, in configure
    self.command.configure(self.base.extcmds)
  File "/usr/lib/python2.7/site-packages/dnf-plugins/system_upgrade.py", line 414, in configure
    self.opts = self.parse_args(args)
  File "/usr/lib/python2.7/site-packages/dnf-plugins/system_upgrade.py", line 379, in parse_args
    opts = self.parser.parse_args(extargs)
  File "/usr/lib/python2.7/site-packages/dnf-plugins/system_upgrade.py", line 308, in parse_args
    self.print_help()
  File "/usr/lib64/python2.7/argparse.py", line 2340, in print_help
    self._print_message(self.format_help(), file)
  File "/usr/lib64/python2.7/argparse.py", line 2314, in format_help
    return formatter.format_help()
  File "/usr/lib64/python2.7/argparse.py", line 281, in format_help
    help = self._root_section.format_help()
  File "/usr/lib64/python2.7/argparse.py", line 212, in format_help
    item_help = join([func(*args) for func, args in self.items])
  File "/usr/lib64/python2.7/argparse.py", line 290, in _join_parts
    if part and part is not SUPPRESS])
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 96: ordinal not in range(128)

"/system-update not found" after reboot

When issuing

dnf fedup --releasever=22 download
dnf fedup --releasever=22 reboot

the system boots up, but reboots immediately again, because journalctl -b -1 tells me clearly what doesn't work

Jun 28 00:11:55 neocortex systemd[1]: Starting System Upgrade...
Jun 28 00:11:55 neocortex systemd[1]: Started System Upgrade.
Jun 28 00:11:55 neocortex systemd[1]: Starting firewalld - dynamic firewall daemon...
Jun 28 00:11:55 neocortex systemd[1]: Starting Updates the operating system whilst offline...
Jun 28 00:11:55 neocortex systemd[1]: Started Updates the operating system whilst offline.
Jun 28 00:11:55 neocortex systemd[1]: Started Drop Read-Ahead Data.
Jun 28 00:11:55 neocortex systemd[1]: Starting System Update.
Jun 28 00:11:55 neocortex systemd[1]: Reached target System Update.
Jun 28 00:11:55 neocortex systemd[1]: Starting Stop Read-Ahead Data Collection 10s After Completed Startup.
Jun 28 00:11:55 neocortex systemd[1]: Started Stop Read-Ahead Data Collection 10s After Completed Startup.
Jun 28 00:11:55 neocortex pk-offline-update[651]: failed to read /var/lib/PackageKit/prepared-update: No offline updates have been prepared
Jun 28 00:11:55 neocortex kernel: nf_conntrack version 0.5.0 (65536 buckets, 262144 max)
Jun 28 00:11:55 neocortex kernel: ip6_tables: (C) 2000-2006 Netfilter Core Team
Jun 28 00:11:55 neocortex kernel: Ebtables v2.0 registered
Jun 28 00:11:55 neocortex kernel: bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this.
Jun 28 00:11:55 neocortex systemd[1]: Starting D-Bus System Message Bus...
Jun 28 00:11:55 neocortex systemd[1]: Started D-Bus System Message Bus.
Jun 28 00:11:55 neocortex systemd[1]: Started firewalld - dynamic firewall daemon.
Jun 28 00:11:55 neocortex systemd[1]: Startup finished in 754ms (kernel) + 1.906s (initrd) + 2.292s (userspace) = 18.167s.
Jun 28 00:11:56 neocortex dnf[648]: [Errno 2] Datei oder Verzeichnis nicht gefunden: '/system-update'
Jun 28 00:11:56 neocortex systemd[1]: fedup-system-upgrade.service: main process exited, code=exited, status=1/FAILURE
Jun 28 00:11:56 neocortex systemd[1]: Unit fedup-system-upgrade.service entered failed state.
Jun 28 00:11:56 neocortex systemd[1]: Triggering OnFailure= dependencies of fedup-system-upgrade.service.
Jun 28 00:11:56 neocortex systemd[1]: fedup-system-upgrade.service failed.
Jun 28 00:11:56 neocortex systemd[1]: Starting Show Plymouth Reboot Screen...

I'm currently running Fedora 21 with systemd 216.
The strange thing is

I had to specify the --releasever flag for the reboot command, too, else my current one would end up in .fedup-system-upgrade
Trying to get around this, I created the symlink by hand, but then cannot run dnf fedup reboot anymore due to it existing already.

But why does it then reboot if initially non-existing, therefore create, but doesn't find it in the offline environment? Let me try to prepare the env by hand and reboot manually ...

Branches and versions on Zanata

Currently there is a Zanata "version" for every release [1]. I know it might be counter-intuitive, but "version" should correspond to a branch, not a release. So, in the case of dnf-plugin-system-upgrade, there should be only one "version", master.

[1] https://fedora.zanata.org/project/view/dnf-plugin-system-upgrade/versions

Unable to update

This is the console output:

[root@localhost ~]# dnf system-upgrade download --releasever=23
Traceback (most recent call last):
  File "/usr/bin/dnf", line 36, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 185, in user_main
    errcode = main(args)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 84, in main
    return _main(base, args)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 115, in _main
    cli.configure(map(ucd, args))
  File "/usr/lib/python2.7/site-packages/dnf/cli/cli.py", line 981, in configure
    self.optparser.usage = self.optparser.get_usage()
  File "/usr/lib/python2.7/site-packages/dnf/cli/option_parser.py", line 255, in get_usage
    usage += "%-25s %s\n" % (name, summary)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 8: ordinal not in range(128)

downloaded packages are removed too eagerly

If I do system-upgrade download, but there is an error, e.g. in the transaction check, subsequent download command wants to redownload everything. This is not acceptable for people with slow links and metered connections.

`sudo dnf system-upgrade reboot ` ran into boot loop

Hi, I have an issue upgrading my fedora 22 to 23. I installed dnf-plugin-system-upgrade, python2-dnf-plugin-system-upgrade and python3-dnf-plugin-system-upgrade, and ran a sudo dnf-3 update to make sure everything is up-to-date. (I used dnf-3 because under Chinese locale (zh_CN.utf8), the python2 version of the plugin makes dnf unable to ran any command even dnf help)

The download command (sudo dnf-3 system-upgrade download --releasever=23 --best) ran smoothly, but the reboot command didn't function as it should. After reboot it booted into f22 kernel, displayed the fedora logo, then rebooted again, and again, and again. During the reboots I saw several lines like 'Starting System Upgrade' 'Started System Upgrade'. I followed the instructions in README.md, deleted /system-update, and came here to file a bug.

I upload my /var/log/boot.log here, hope it will be useful.

prevent reboot loops

There are numerous people reporting they are stuck in a reboot loop when attempting upgrade. That's the worst outcome we can get, because suddenly their system is "bricked", and it's not easy to fix. Some of them might be Chinese, due to the this bug, but it seems not all of them. So there are some other issues as well.

We need to make failures more resistant. Because currently, when this fails to start, due to whatever dnf or python error, the system is stuck in a reboot loop, because /system-update is never removed:

ExecStart=/usr/bin/dnf --releasever=${RELEASEVER} system-upgrade upgrade

I suggest to change it to something like this:

ExecStart=/usr/bin/bash -c "/usr/bin/dnf --releasever=${RELEASEVER} system-upgrade upgrade || (/usr/bin/rm -f /system-update; false)"

We need to verify whether the $RELEASEVER envvar will work as intended. We can also create a bash script for this, if we don't want to have it all on a single command line. But I think this is really important, because we need to ensure people won't end up in reboot loops if the system-upgrade command fails to start for any reason.

Add an 'upgrade' repo so stuff doesn't look like it all came from '@commandline'

After you run the upgrade, it seems like all the packages that were installed are from a repo named @commandline?

...or maybe not, because my system seems to have had its hard drive crash during the upgrade and so is completely screwed. But if someone can confirm this is a problem it might be worth working on further.