SDB Talk:System upgrade
- 1 Unclear section adding Update Repo (May 2019)
- 2 autorefresh for update repo
- 3 multimedia repositories
- 4 Upgrade or Update
- 5 alternative using YaST
- 6 Zypper Dup Abortion Gotcha
- 7 Recomend doing the upgrade in runlevel 3
- 8 Instructions confusing
- 9 Using tmux has its dangers too!
- 10 Important Gotcha when upgrading a Xen virtual machine
- 11 Upgrade graphics drivers BEFORE first re-boot
- 12 Strongly warn to not upgrade to a version that is not the next one
- 13 Runlevel 3
- 14 Add extra repos,... and then?
- 15 The upgrade from 13.2 is impossible 'cause http://download.opensuse.org/update/13.2 is not available
- 16 No space left on device from btrfs during zypper dup
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)
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)
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
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.
Based on the above comments, and specifically based on the comments of User:Robin_listas (thanks) I have updated the page
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.