SDB Talk:System upgrade
tagline: From openSUSE
- 1 autorefresh for update repo
- 2 multimedia repositories
- 3 Upgrade or Update
- 4 alternative using YaST
- 5 Zypper Dup Abortion Gotcha
- 6 Recomend doing the upgrade in runlevel 3
- 7 Instructions confusing
- 8 Using tmux has its dangers too!
- 9 Important Gotcha when upgrading a Xen virtual machine
- 10 Upgrade graphics drivers BEFORE first re-boot
- 11 Strongly warn to not upgrade to a version that is not the next one
- 12 Runlevel 3
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)
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).
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
It is strongly recommended that you run this inside GNU screen or tmux to protect the upgrade process in case anything should go wrong with the X session during the upgrade. Packages for both screen and tmux are available in the main openSUSE repositories. tmux is probably a safer bet, because for example if upgrading from 12.1 to 12.2, you would go from a version of GNU screen which uses FIFO pipes to a version which uses UNIX sockets, and GNU screen has a bug which breaks compatibility between these two approaches, which means that you cannot resume a screen session created in 12.1 using the version of screen from 12.2.
It is strongly recommended that you run the upgrade not in runlevel 5 (graphical mode) but in runlevel 3 (text + network).
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.