Home_greyopenFATE - openSUSE feature tracking > #312799
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Safer distribution updates

Feature state


Currently the documentation says that to do a distribution upgrade you should first update your software stack to the target distribution, then do a zypper dup. The software stack update can already kill your system.

zypper could allow an option that makes it first install a miniroot containing the update stack itself, then automatically switch over to the miniroot to do the "zypper dup".

User benefit:

Failsafe migrations for SLE



Bob wants to migrate his server from SLE12 to SLE13 (or from SP1 to SP2). Upgrading the package management stack fails, but he keeps his original system untouched.

Joe wants to migrate his desktop from openSUSE 12.1 to 12.2.


icons/user_comment.png J. W. wrote: (2 years ago)

If we decide to actually allow "online" zypper dup on SLE 12 this is indeed mandatory.
In case the decision is made that we should always boot into an update system for a distribution update, this is still nice to have for openSUSE, but would be downgraded for SLE.

icons/user_comment.png J. S. wrote: (2 years ago)

We don't intend to support 'zypper dup' updates from SLE11 to SLE12.

The service pack migration (which is the only case for the on-line migration) is being handled as separate features and the discussion may have quite different results (based on the channel set-up).

One of the ideas for on-line migration indeed was to boot SP-new system to perform the migration itself, as documented in Fate #315161.

Because of the above, I suggest to reject (not meaning that the request is invalid).

icons/user_comment.png A. S. wrote: (8 months ago)

Can you please agree on one product here and copy if needed for 2 products, so we can track that separately?

icons/user_comment.png J. W. wrote: (6 months ago)

Making this an SP1-only feature. Of course the expectation is that any improvement in zypper for 12 SP1 will also be rolled into openSUSE as a matter of policy.

icons/user_comment.png J. S. wrote: (6 months ago)

We agreed that for SP upgrade we will first update the update stack from the _old_ repositories - it will be known to work in the old system as well as support new packages.

What's requested beyond this from this feature?

icons/user_comment.png J. W. wrote: (6 months ago)

I have no experience how often the zypper update would actually cause problems, and given that we now offer btrfs snapshots, maybe the problem Michael describes isn't that bad after all.

But always running the update stack from a miniroot would definitely provide one more layer of safety and allow us to introduce more new stuff during distribution update than we can with the conservative approach.

Ultimately an engineering decision, but I'd like to keep this at least important for SP1.

icons/user_comment.png J. W. wrote: (6 months ago)

PM Priority for product SLES-12-SP1 downgraded from mandatory to important:

Reconsidered importance, given that we now have btrfs snapshots that allow relatively painless rollbacks.

icons/user_comment.png a. v. wrote: (5 months ago)

Joachim if wanted to reject the feature you could have rejected it by editing the product and should have given reason explaining reason why you rejected the feature. Instead of deleting the project itself.

icons/user_comment.png J. W. wrote: (4 months ago)

Hi, I didn't want to confuse anybody, but given that this was a request created internally by a SUSE employee in the first place and that we shouldn't have requests for both openSUSE and SLES in the same FATE I thought that removing openSUSE was the most straightforward change.

icons/user_comment.png a. v. wrote: (5 months ago)

In order to avoid confusion that why product is missing. Adding openSUSE distribution as product and rejecting it.

Last change: 4 months ago
Score: 14
  • Negative: 1
  • Neutral: 2
  • Positive: 15
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint