SDB Talk:System upgrade
New var $releasever
There is a new variable $releasever used in repository links. Should be used as follows:
zypper --releasever 15.5 refresh
To update repocache
zypper --releasever 15.5 dist-upgrade
For upgrade to new version
--felbre (Diskussion) 04:44, 05. Feb. 2022 (UTC)
Edit removing support for 42.1, 42.2, 42.3
Today (6 March 2020) an edit was submitted modifying this SDB so that references and support for using the methods described in this SDB were removed for 42.1, 42.2 and 42.3 with only the comment "removed EOL-distro version."
I ask whether EOL is relevant at all. The point is that the methods described have not changed substantially since those versions and in fact were the official recommended methods when those versions were current.
Additionally, from time to time people who support extremely old versions post in the Technical Help Forums asking for advice for upgrading versions going at least as far back as 11.3, and people should know that these exact steps should be followed when upgrading from the versions that were removed
Contrary opinion? I will not revert this change immediately but will wait for the opinion of others.
- I was the editor and I did this edit in the assumption to remove "old cruft" and to "tidy up". BUT related to long-outdated versions you are IMO right that there is no big relevance here. Let's see what others are thinking. thalunil
- There is Archive namespace. Old but valid content can go there. --Meksykaniec (talk) 12:43, 9 March 2020 (UTC)
- The Archive namespace makes sense for articles that are not relevant for the currently supported releases anymore. However, it doesn't make sense to create a copy of this article there only to clarify that the upgrade worked in the same way for Leap 42.x ;-)
- Especially for an article about upgrading, keeping 42.x mentioned makes lots of sense IMHO so that people who still run 42.x know how the upgrade to 15.x can be done. --Cboltz (talk) 19:37, 13 March 2020 (UTC)
08:05, 4 September 2019 Zhangxiaofei change
UPDATE:
After some hacking, I fixed or found workarounds that should make this method work, and have posted a script to guide the User through the necessary steps to properly convert the repo configuration files to use $releasever and upgrade properly in the following Technical Forum post. I recommend waiting for word from Maintainers how the various issues are addressed before updating the legacy methods described in this SDB
https://forums.opensuse.org/showthread.php/537424-Need-volunteer-verification-change-to-quot-SDB-System-Upgrade-quot-does-not-work?p=2913534#post2913534
There is a proposed change that has been undone (See History) that replaces the sed command with the following
zypper --releasever 15.1 --gpg-auto-import-keys ref
Unfortunately, this zypper command does not work, and has been independently verified not only by myself, the following bug has been submitted https://bugzilla.opensuse.org/show_bug.cgi?id=1149511
When the bug has been fixed, this section can be reviewed again and the "undo" possibly reverted.
Unclear section adding Update Repo (May 2019)
Am guessing that this entire section is what should be done on a system before upgrading, but it's not 100% clear is the case. If so, then this section has numerous errors, including specifying openSUSE 15.1 and 15.0 in the examples... Instead should clearly specify an older openSUSE version. Testing for a working update repo needs clarification (my guess upgrading a badly outdated version past EOL). Because whoever updated this section didn't properly comment the changes, History does not clearly identify which updates should be undone, or perhaps any idea of rolling back should be discarded and just make changes going forward.
Am hesitant to make changes immediately should my interpretation of this content be incorrect. If others agree with me that this is meant to be executed on the system before upgrading, then I (or anyone else) can move forward and make the necessary changes.
Addition June 2019 - I have concluded this section applies entirely to the system prior to upgrading, so have made necessary changes to reflect correct openSUSE versions assuming rpe-upgrade is 15.0. If someone disagrees, can discuss here or make new changes or undo the changes I made June 21 2019.
autorefresh for update repo
Should the update repo not be set to autorefresh? Rabauke 12:46, 21 September 2010 (UTC)
- It should ;-) I just fixed it (one year later), so please just do such obvious fixes yourself the next time ;-) --Cboltz 16:41, 16 November 2011 (MST)
multimedia repositories
The page says "Search for updated openSUSE 11.3 compatible third-party repositories that you used before and add them" but then "Warning: Use with caution. Using third-party repositories could increase the chances that the upgrade will not complete correctly".
So specifically, should the packman and/or libdvdcss repositories be enabled or not?
The http://opensuse-community.org/Restricted_formats/11.3 pages (and 11.2) both have troubleshooting sections that I've found necessary to use since the one-click didn't work. What is the situation when doing a distribution upgrade? Djh-novell 05:57, 12 February 2011 (MST)
I have found and others have verified that leaving Packman enabled during the upgrade 15.0 > 15.1 won't cause problems and in fact will avoid a number of version conflicts that would otherwise have to be resolved manually. Since there is no certainty this would be the case always, am reluctant to officially advise leaving enabled. Tsu2
Upgrade or Update
The first part of this page id for updating a distro with the last version of the same version. Only the second part explain really an upgrade, that is going from one version to the upper next (11.3>11.4 or 11.4>12.1).
Believe this was resolved with current re-write (15.0). Was very confusing before.
alternative using YaST
Nowaday, the distro names are consistant. So it's enough to go to YaST, repositories, edit any line to change 11.3 for 11.4 (example). If the repository is accepted you are OK.
Then in a root windows, do "zypper dup" (and pray :-))
Zypper Dup Abortion Gotcha
Before running zypper dup, check that nothing is using the zypper database, for example an updater applet / packageKit. If zypper finds the conflict before you do, you are in trouble. I find that Zypper is completely incompetent and incapable of updating its conception of whether the database is locked (including if invocation is through Yast). Zypper will not revise its opinion even after spending 20 minutes apparently waiting for an long-dead process to stop allegedly locking the database. Besides the zypper lock management incompetency, isn't it obvious that it should check for locks before making destructive changes! Hopefully somebody else can suggest a definitive, or at least convenient check, to run beforehand. Until I come up with a better idea, I'm running yast2 sw_single before zypper dup, to flush out any locking problems.
If zypper dup aborts after it has removed the packages to be updated, the system will be unusable such that you can't even shut down the system gracefully. I recovered from this by powering down and performing an upgrade installation from optical media, which is very inconvenient compared to the in-place upgrade documented here.
- Report a bug using http://bugs.opensuse.org/ . Complaint here it is completely useless, for you and for the rest of us. If zypper is acting like that, it is a bug, and describing it on the wiki solves nothing. Also, I had no problems with zypper for a long time, and I did few upgrades in that time. --Rajko m 16:30, 18 December 2011 (MST)
Recomend doing the upgrade in runlevel 3
The summary says: “During the upgrade you can still use your workstation (even if this is not recommended); the only downtime will be the reboot after the upgrade.” I think doing this is nuts. People had the X session crash during the upgrade (example: http://forums.opensuse.org/showthread.php?t=478924), as is to be expected when all of X is being replaced with a different version. When X does crash, the upgrade also aborts and leaves the system in an inconsistent state, and often it can not be restarted. The system is unbootable or unworkable. Thus I strongly recommend that the procedure is run in runlevel 3 and barely nothing else be done on the computer meanwhile. Ir level 5 is used, then use one of the VTs.
--Robin listas 06:37, 28 September 2012 (MDT)
Instructions confusing
I find these upgrade instructions very confusing. I've tried following them, but zypper will not accept what I enter as an upgrade repository.
I'm going to download the DVD and just re-install, but I would like to be able to upgrade in future.
And yes, I am not an expert.
Using tmux has its dangers too!
I used tmux to do the 'zypper dup' to update from 12.2 to 12.3. I detached from the screen, to check some other things. When I tried to reattach to the tmux screen I got:
> tmux attach
protocol version mismatch (client 7, server 6)
So I can't view what's on the screen. I can check 'zypper dup' is finished with 'pgrep zypper', but that's about it. So now I'm hoping there aren't any important messages on the screen and have to trust the reboot is going to work... (The updated server is at a co-location)
Important Gotcha when upgrading a Xen virtual machine
This procedure renders your virtual machine unbootable because of bug https://bugzilla.novell.com/show_bug.cgi?id=801883
The distribution upgrade installs the bloated Plymouth packages, even if you have previously removed them. So before rebooting you must get rid of them with
# list=$(rpm -qa | grep -i plymouth)
# rpm -e $list
# mkinitrd
Upgrade graphics drivers BEFORE first re-boot
The post-upgrade instructions for third party repositories only mention adding them back in.
In my case, using the nVidia repository for graphics drivers and using the Gnome desktop, I was left with a system which was unusable at anything other than runlevel 3 after I had followed these instructions and re-booted with the old graphics drivers.
Explicitly mentioning that graphics drivers should be upgraded before first re-boot will avoid this issue.
The problem is compounded for users of the Gnome 3 desktop, because the origin and significance of the grey FAIL screen that appears ("Oh no! something has gone wrong") is not apparent. That screen could have come from anywhere - only Googling reveals it is actually a Gnome 3 error.
Strongly warn to not upgrade to a version that is not the next one
A strong warning should me made that the supported scenario is upgrading from one release to the next one: like from 11.4 to 12.1, but not from 12.2 to 13.1.
While such an upgrade may work, often it does not. For instance, the upgrade from 12.3 to 13.1 needs certain patches to the zypper toolchain, that were added to 12.3 about when 13.1 was released. But 12.2 does not have these patches (can not have them), and a live upgrade should fail.
People that know what they are doing can risk jumping over a release, it is up to them; but the instructions should strongly warn against it.
So the recommended procedure to upgrade across several releases, is to go one release at a time. Upgrade one release, verify that the system is working properly, apply all mandatory patches, then upgrade to the next release, etc, till the intended target is reached.
--Robin listas (talk) 23:34, 2 April 2014 (UTC)
Runlevel 3
Based on the above comments, and specifically based on the comments of User:Robin_listas (thanks) I have updated the page
Was:
Now:
People had their X session crash during the upgrade, causing the upgrade to aborts which leaves the system in an inconsistent state.
To change to runlevel 3, see SDB:Switch_runlevel.
Add extra repos,... and then?
The user is instructed to "zypper addrepo ...". That is ok, but after that, how does he get the applications from that repo installed? Since during the zypper dup, all applications are returned to their versions from the main openSUSE repos.
The upgrade from 13.2 is impossible 'cause http://download.opensuse.org/update/13.2 is not available
Archived update repositories for EOL versions of openSUSE can be found at the following location https://ftp5.gwdg.de/pub/opensuse/discontinued/update/
Try mirrors site: http://mirrors.opensuse.org/list/all.html
Select a mirror of your choice and change your zypper repos URI:
For example http://mirror.23media.de
sed -i 's,download\.opensuse\.org,mirror\.23media\.de/opensuse,g' /etc/zypp/repos.d/*
No space left on device from btrfs during zypper dup
Before doing an upgrade, it may be worth considering disabling snapper snapshots and/or cleaning up snapshots to avoid btrfs space errors.
An upgrade from 42.3 to 15.0 using zypper dup experienced "No space left on device" errors from btrfs. There were around 250 packages left to install out of 3500 total on this particular system. Deleting several pre/post pairs of snapshots allowed approximately 120 more small packages to install. Unfortunately, not all snapshots could be removed. The snapper command stopped functioning due to zypper dup upgrading files.
The system was rebooted at this point. There was enough of 15.0 installed to allow it come up sanely. The zypper dup was run again to complete the upgrade.
Although not tested, uninstalling the snapper-zypp-plugin package before performing the zypper dup might be a consideration during an upgrade. This may avoid having snapper automatically create snapshots during the upgrade and causing btrfs "No space left on device" errors.
Broken link
Under "Related Articles","Leap official upgrade documentation" attempts to display https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.startup/cha.update.osuse.html which returns "Object not found!" I have no idea how to fix this broken link.
PatrickDGarvey (talk) 16:38, 20 April 2020 (UTC)
This page is about upgrade of Leap
I think this page is only about upgrade of
- Leap to a newer version of Leap - Leap to Tumbleweed (mentioned, not really described) - Leap to SLES (mentioned, referred to another page)
Should we not clarify this?
So, I propose:
- Rename the title from "SDB:System upgrade" to "SDB:System upgrade of Leap".
- Replace this:
"This guide shows how to use Zypper to do a live distribution upgrade of openSUSE"
by this
"This guide shows how to do a live distribution upgrade of openSUSE Leap to a newer version of Leap".
M_vanderwulp (talk) 14:03, 14 Januari 2022