SDB:Upgrade Tumbleweed
How to Update Tumbleweed
openSUSE Tumbleweed is a rolling release desktop/server project, which means it provides the latest stable software updates continuously.
Zypper is a command-line interface to ZYpp system management library (libzypp). It can be used to install, update, remove software, manage repositories, perform various queries, and more in Tumbleweed.
There are 2 ways to update a openSUSE system:
- sudo zypper update (or sudo zypper up, for convenience).
- sudo zypper dist-upgrade (or sudo zypper dup, for convenience).
Because Tumbleweed has a rolling release model, it doesn't have distinct versions which you often see in other distributions. As the system gets continuously updated and released, new "snapshots" or "distributions" of Tumbleweed become available, which some would label as a version for reference purposes.
Because we don't just want to update our individual applications (which is the purpose of zypper up), but our entire Tumbleweed system, we use option #2, the zypper dup command.
Why? Because we want to update everything in Tumbleweed to "catch up" to the latest snapshot that was released, including things like:
- The Kernel
- Libraries
- Core System Tools
While most users will be just fine with this command, below are some extra flags and parameters that allow further updating capabilities ranging from but not limited to:
- What if I have software from several repos?
- What if I want to test the update before actually running it?
- What if I want to run the update without having to confirm or select update options for software (no intervention)?
Zypper can handle all of these scenarios! For a small sample, check out a small sample of zypper commands below that might be helpful.
For a more complete and generally more up to date documentation on zypper, go to here.
If you are really paranoid, and want to execute zypper dup in such a way so as not to disrupt or hang packages related to your Desktop Environment (extremely rare) check out the Updating Via Root Logged Out section below.
As with anything dealing with software, rolling or not, there is a chance for bugs for underlying packages conflicting with one another. Thanks to the power of snapper, simply rollback to an earlier state and run zypper dup in a couple of days to see if the issue was resolved. For this reason, it is recommended that you become familiar with using snapper to rollback to previous states of your machine. It is super easy and a convenient to ensure you always have a working system.
If you still find issues, don't hesitate to get help from the awesome community via our channels/communications page.
Sample-Zypper-Commands
The following (truncated) information is from SDB:Zypper_manual. See the zypper repository for the list of authors.
dist−upgrade (dup) [options]
Perform a distribution upgrade. This command applies the state of (specified) repositories onto the system; upgrades (or even downgrades) installed packages to versions found in repositories, removes packages that are no longer in the repositories and pose a dependency problem for the upgrade, handles package splits and renames, etc.
If no repositories are specified via the −−from option, zypper will do a global upgrade with all defined repositories. This global form of dup will also consider unchanged installed packages and re−evaluate their dependencies.
−−from alias|name|#|URI
The option can be used multiple times and restricts the upgrade to the specified repositories only. Nevertheless all enabled repositories are visible to the resolver and will be considered to satisfy dependency problems.
−l, −−auto−agree−with−licenses
Automatically say yes to third party license confirmation prompt. By using this option, you choose to agree with licenses of all third−party software this command will install. This option is particularly useful for administrators installing the same set of packages on multiple machines (by an automated process) and have the licenses confirmed before.
−−auto−agree−with−product−licenses
Automatically accept product licenses only. This is used by tools like SUSEconnect, which ask for confirmation before the product gets registered. So there’s no need to confirm the product license again at install time.
−−replacefiles
Install the packages even if they replace files from other, already installed, packages. Default is to treat file conflicts as an error. −−download−as−needed disables the fileconflict check because access to all packages filelists is needed in advance in order to perform the check.
−D, −−dry−run
Test the upgrade, do not actually install or upgrade any package. This option will add the −−test option to the rpm commands run by the dist−upgrade command.
−y, −−no−confirm
Don’t require user interaction. Alias for the −−non−interactive global option.
−−details
Show the detailed installation summary.
Solver related options:
−−debug−solver
Create solver test case for debugging. Use this option, if you think the dependencies were not solved all right and attach the resulting /var/log/zypper.solverTestCase directory to your bug report. To use this option, simply add it to the problematic install or remove command.
−−force−resolution
Force the solver to find a solution by allowing to remove packages with unfulfilled requirements. This is the default when removing packages (zypper remove). This option overrides −−no−force−resolution in case both are specified on the command line.
−R, −−no−force−resolution
Do not force the solver to find a solution. Instead, report dependency problems and prompt the user to resolve them manually. This is the default except when removing packages (zypper remove).
−−recommends
Install also recommended packages in addition to the required ones. The default behavior is determined by [zypp.conf:solver.onlyRequires].
−−no−recommends
Do not install recommended packages, but only required ones. The default behavior is determined by [zypp.conf:solver.onlyRequires].
Expert Options:
Don’t use them unless you know you need them.
−−[no−]allow−downgrade
Whether to allow downgrading installed resolvables [zypp.conf:solver.dupAllowDowngrade].
−−[no−]allow−name−change
Whether to allow changing the names of installed resolvables [zypp.conf:solver.dupAllowNameChange]. Setting this to no will not replace packages which have been renamed.
−−[no−]allow−arch−change
Whether to allow changing the architecture of installed resolvables [zypp.conf:solver.dupAllowArchChange].
−−[no−]allow−vendor−change
Whether to allow changing the vendor of installed resolvables [zypp.conf:solver.dupAllowVendorChange]. Setting this to no might be useful if you do not want packages from foreign repos being dup’ed to the distributions version (or vice versa).
This command also accepts the Download−and−install mode options described in the install command description.
Examples:
$ zypper dup −−from factory −−from packman
Upgrade the system to the latest versions provided by the factory and packman repositories.
UPGRADING via ROOT and LOGGED OUT
It's recommended that you become familiar with using snapper to rollback.
It's generally safer to logout of your desktop environment (DE) and upgrade from a virtual terminal: This avoids anything related to the DE freezing or dying in the middle of the upgrade. However, you can safely download all the changed packages from within the DE without installing. This can be done from a DE terminal with:
su -c 'zypper dup -d'
This can be more convenient if you need to ask about conflicts on the forum.
Either way, the following will complete the upgrade:
- Log out of your desktop environment and press
Ctrl+Alt+F1at the login manager. - Log in as root.
- Enter the command:
# zypper dup
- Deal with any conflicts and then agree to the upgrade.
- When the upgrade is complete, enter the command:
# reboot
A reboot isn't always required: Zypper will tell you when it is. To return to the DE enter the exit command, and press CTRL+ALT+F2.
Theoretically, the safest way to upgrade when a reboot isn't required is to isolate the rescue.target, because the fewest things are loaded in this state, which means that most things will be reloaded when switching back to the DE. The idea is to avoid having outdated processes running that the upgraded packages might try to interact with. You can isolate the rescue.target with one of the following commands:
# systemctl isolate rescue.target