How install new version of Opensuse in Virtualbox and keep data?

Hi everyone,

For many years I used Opensuse in multiple versions in a dual-boot setup with Windows. Usually I kept a separate /home partition so I could update the system and keep the data in place. Although not deeply knowledgeable, I grew reasonably familiar with how to handle system updates and necessary adjustments.

The situation changed a year ago when I was forced to run Opensuse through VirtualBox on a virtual machine (VM). So my current setup is: Windows 10 Home 20H2 64bit up to date; VirtualBox 6.1.18 r142142 (Qt5.6.2) with Extension Pack; Opensuse Leap 15.1 64-bit; storage situation is “286GB free of 454GB”. I see a Win folder <USRFLDR>\VirtualBox_VMs\Opensuse 15.1 64-bit\ and in it a file export-disk1.vdi with a size of about 54GB.

Now that support for Leap 15.1 has ceased, I would like to update to the current version 15.2, or maybe wait for 15.3 (for workload reasons). In any case, here is where my questions start.

What is a setup that has a separate /home so I can change OS versions easily?
How do I get this setup? What is the procedure to do a version change?
I have never done an “upgrade”, would that also be an option?
Are there downsides for any of the available options, what could go wrong? -
In extension, is there a way to share a (test) data partition among different guests (and maybe also the host) so these guests can be tried out and compared?

Please let me know if further information is needed. In your reply, please be specific where to look for it or what command to use since I am rather a “top-level” user.

Thank you very much in advance for your help and input.

I have never done an “upgrade”, would that also be an option?

this is what i did to move from 15.1 to 15.2

i edited the repo files to point to 15.2 and then ran " zypper dup"

this upgraded the system

also see:

there is a upgrade rpm you can install instead of manually editing the repo files

Are there downsides for any of the available options, what could go wrong?

there might be issues with any extra repos you have installed

i have MANY and need to use the priories( 0 to 99 ) to make sure there are not conflicts

I have done this several times and never had an issue but always make a full backup of the VM and then take a snapshot so I have an instant rewind option. Tends to grow the VDI by a large amount so when I am happy it’s all gone ok I zero out the unused space and shrink the VDI.

“keep data” is already a bit ambiguous.

Most people are primarally concerned about the user data. That is basically all that is inisde /home (remark, we talk about a rather basic/default system where there is not much other “users data”, e.g. in databases outside /home, etc. but the theory of those is the same).
How to keep all in /home?
When you have a separate file system for /home, that is easy. Even a fresh installation can then be done without touching it.
When that is not the case, when just doing an upgrade without fresh installation also /home /will not be touched. When doing it with a fresh installation, one should first make a (extra, because you do have backups already haven’t you?) backup of /home to retstore after the upgrading.

But there is more data that you might want to keep. The several configuration files of your system (mostly within /etc). When doing a fresh install, you must aftrwards create these configurations anew. A backup where you can check what they were earlier might help you in re-creating.

But all this might not be needed as @JohnVV already told.

When going from one version to the next (like 15.1 > 15.2) you can update al software packages to the version of the new openSUSE version and keep the data. This upgrade can be done from the installation DVD (it has an Upgrade itime in it’s boot menu), or on-line.
The on-line way, as introduced by @JohnVV) is officially described in:
Read it and when in doubt ask here before you start.

BTW, the action of changing the 15.1 into 15.2 in all your repository definitions might be superfluous. Since some time you should not see the string 15.1 in the URL definitions, but the string $releasever. Which then means that you do not have to change anymore, but can define your new version in the zypper dup command

zypper --releasever 15.2 dup

This will use the 15.2 repos and at the end of the installation, 15.2 will be your default from then on.

To check your list, and maybe get further advice, please post

zypper --releasever FOOBAR lr -d

Thanks for your first replies.

Regarding “data”, indeed there are also backup copies of system files (as hcvv mentioned, mostly from /etc) that are kept across versions in a dedicated directory. My solution was to keep them in a /home/local/ directory and create softlinks in /usr/local/. /home/local/ then lives on between versions.

Do I understand correctly that the concept of separate partitions does not apply when working with a VM?

I had not heard about the $releasever variable. Usually, I handle repositories, package selection etc. through the appropriate Yast module. As requested (I am listing only those which have at least one “yes” among “Enabled” and “Refresh”):

linux-hppav:~ # zypper --releasever FOOBAR lr -d
Warning: Enforced setting: $releasever=FOOBAR
#  | Alias                     | Name                                   | Enabled | GPG Check | Refresh | Priority | Type   | URI                                                                                   | Service
 1 | openSUSE-Leap-15.1-1      | openSUSE-Leap-15.1-1                   | Yes     | (r ) Yes  | No      |   99     | rpm-md | cd:/?devices=/dev/disk/by-id/ata-VMware_Virtual_IDE_CDROM_Drive_10000000000000000001 | 
 2 | openSUSE_Leap_15.1        | Virtualbox [up2d8 for Guest Additions] | Yes     | (r ) Yes  | Yes     |   99     | rpm-md |        | 
 3 | openSUSE_Leap_15.1_1      | Packman Repo Substitute                | Yes     | (r ) Yes  | Yes     |   99     | rpm-md |                   | 
 4 |   | Libdvdcss Repository                   | Yes     | (r ) Yes  | Yes     |   99     | rpm-md |                                   | 
10 | repo-non-oss              | Non-OSS Repository                     | Yes     | (r ) Yes  | Yes     |   99     | rpm-md |                   | 
11 | repo-oss                  | Main Repository                        | Yes     | (r ) Yes  | Yes     |   99     | rpm-md |                       | 
14 | repo-update               | Main Update Repository                 | Yes     | (r ) Yes  | Yes     |   99     | rpm-md |                                   | 
15 | repo-update-non-oss       | Update Repository (Non-Oss)            | Yes     | (r ) Yes  | Yes     |   99     | rpm-md |                              | 

All the “15.1” are hard-coded. Do I understand correctly that all “15.1” should be replaced by “$releasever” in Yast Repositories module or, as root, with the command

sed -i 's/15.1/${releasever}/g' /etc/zypp/repos.d/*.repo


Should they all stay “Enabled” and “Refresh” for the upgrade?

A disclaimer: I do not know much about using a VM. My remarks are based on the assumption that inside a virtual system all is the same as it would be on a non-virtual system. That includes the fact of having or not having (personal preference) of a separate file system for /home.

Another remark: please not that I talk about file systems (like having a separate file system for /home), not about partitions. If a file system is on a partition or on some other type of volume/partition is something different.

As you see from your repo list, the basic repos do already have $releasever (those that show FOOBAR. My advice would be to change the other ones also to be consistent and to complete the step to using the $realeasever feature.

You can either do the command you suggested or just edit the appropriate files in /etc/zypp/repos.d, only 3 of them to do. Or use YaST. All to your preference.

In any case, I would disable #1 from your list, which is the DVD. As it is now, it will probably ask for it to be inserted/connected every time you want to do some software management. After you have switched to15.2, it will be of no use in any case and you can delete it.

I have not re-read the advice on how to upgrade, but I assume it suggests to disable the non-standard (in your case libdvdcss, Packman and Sauerland) repos during the upgrade. Later you can enable them (and when they have now $releasever, they will then be ready for usage), update from libdvdcss (allthough I guess the one package there will still be the same), switch to Packman and update that what you have from Sauerland.

BTW, during “normal life” you can disable libdvdcss repo. nothing will change there and the refresh every time is thus lost resources.

Please also be aware of this
if going the “online upgrade” route.

Clearing up some muddiness and addressing problems…

You should know that a virtual machine is no different than a physical installation except that a virtual machine’s disk drive is a file.
Everything about its disk layout including partitions, volumes and filesystems are consistently the same.

openSUSE has traditionally deployed /home in a separate partition (the filesystem is irrelevant, can be same as root’s or any other) up to what version, was it 15.0? And then after that, a new installation by default deploys /home in the same partition but as a BTRFS subvolume, so it’s technically still separate from the root partition or volume. This can make a difference and cause problems in some scenarios if you aren’t aware of the change.
So, if your installation was originally installed with root and /home as separate partitions, that will not change over the lifetime of your system unless you expressly change it. Upgrades will continue to preserve the same disk layout.

But, it shouldn’t concern you whether your openSUSE is the old or new layout.
The upgrade will not generally touch your files in /home, only possibly modify hidden files related to your Desktop settings because your Desktop will be upgraded along with the rest of your system.
But, be safe.
Besides making a working backup ahead of time, copy your personal files to another location before upgrading and you should have peace of mind.
Or, as I am about to say, make at least one full copy of the directory containing your virtual machine which will of course include your personal files.

The upgrade should be planned carefully before actually executing the upgrade.
For most common workstation installs, you’ll only be installing common client apps, and those will generally upgrade without a problem.
On the other hand, if this is a server running server apps or you’re running a full server application on your workstation, be aware that anything related to the server apps will likely have to be upgraded by hand. If it is running a RDBMS like MySql/Mariadb, you’ll likely have to export your data and import into the new database engine. If you’re running a webserver like Apache, depending on how it’s set up may require a re-deployment.
This is one reason why deploying in a virtual machine can be so useful… You have at your disposal a number of possible strategies to help with your upgrade, not only do you have common backup/restore and openSUSE snapshot options, you can also make copies of your virtual machine by simply copying the entire directory holding your virtual machine (which contains your diskfile and configurations) and you can use the virtualization technology’s snapshot option.
I caution that although you can and sometimes should use the virtualization’s snapshotting as needed, don’t keep snapshots around very long… If sometime anything goes very wrong and the diskfile becomes corrupted, a repair attempt is practical only against a single disk file. Snapshots are one way many files together comprise a single virtual disk, and can make a disk repair extremely difficult.

Of the two upgrade methods,
Like the others I recommend the “online upgrade” where you modify the repository names either by editing or by using the $releasever variable. Be familiar with both methods, they do the same thing but from time to time I find a system doesn’t work as it should… That method is now described in the SDB reference others posted.

Your question about whether to leave your repos enabled is… Yes.
You’ve changed the repo names to the new, upcoming openSUSE version and you want the upgrade to use the information. If you disable the repos, the upgrader won’t know where the upgrade sources are.

You made a mistake literally copying FOOBAR into your repo URI

10 | repo-non-oss              | Non-OSS Repository                     | Yes     | (r ) Yes  | Yes     |   99     | rpm-md |**FOOBAR**/repo/non-oss/                   | 
11 | repo-oss                  | Main Repository                        | Yes     | (r ) Yes  | Yes     |   99     | rpm-md |**FOOBAR**/repo/oss/                       | 
14 | repo-update               | Main Update Repository                 | Yes     | (r ) Yes  | Yes     |   99     | rpm-md |**FOOBAR**/oss                                   | 
15 | repo-update-non-oss       | Update Repository (Non-Oss)            | Yes     | (r ) Yes  | Yes     |   99     | rpm-md |**FOOBAR**/non-oss/     

You should know that “foobar” is a term commonly used to be a placeholder for something of your choice, it’s not meant to actually be written.
In this case, $releasever should be inserted in place of FOOBAR or if that doesn’t work, then “15.3” or whatever version number is appropriate.

The comment about configuration files in /etc probably is not an issue. Those files are generally configuration files for system processes and apps… Your personal User configurations should generally be located in your /home directory.

But, the online method is just more convenient.
The offline method is the more sure, and not subject to the risks of an online upgrade which requires a fast, reliable Internet connection.
The offline upgrade where you simply download the DVD and select “upgrade” instead of “New Install” when you boot the disk does not require a reliable Internet connection.
Also, the DVD ISO is very easy to deploy in a virtual machine, just point your VirtualCDROM to the ISO file and boot your virtual machine. No need to actually burn to an optical disk or USB drive(I hope you did your initial install this way instead of the unnecessary work of burning the ISO image to another medium).

If you have a problem doing the online upgrade, the general recommendation is to do the offline upgrade which should repair and complete the upgrade.


You are completely amiss about the usage of FOOBAR in this thread and in the zypprer command. Please reread the command. It is

zypper --releasever FOOBAR lr -d

and read the man zypper page about --releasever global option and the relation with $releasever in the *.repos file.

You will then find out that the text FOOBAR is not in the repository definition (as you assumed above), but $releasever is. Example:

boven:/etc/zypp/repos.d # cat /etc/zypp/repos.d/main.repo 
name=Main (OSS)
boven:/etc/zypp/repos.d #

Inn the “normal” situation, $releasever is replaced by the current openSUSE version when used by zypper. One can override this with the zypper global option --releasever . When this string $releasever is available in the correct place in all applicable *.repo files in the baseurl= parameter, there is no need anymore to edit the .repo files before a version upgrade using zypper dup, because you can then do e.g.

zypper --releasever 15.2 dup

on a 15.1 system. during such a zypper dup, the 15.1 that was the default in the system will be replaced by 15.2 thus after the upgrade all is well again.

And the repo list as shown above with the FOOBAR in it is only created to check if each and all repos on that system do already have the $releasever in them, Which was only partly the case, because some have FOOBAR and some have 15.1.

I guess the wording of how this feature works may be better in

man zypper

Please search the string releasever, read and ask yourself how it is possible that you have missed the introduction completely.
It is also in , again look for releasever.

I must have been unclear.
In more descriptive text, I think you are saying what I meant to say.
If you look at the “zypper lr” output the @OP posted, you will see he actually has the text string FOOBAR in his repository paths.

prompted to review the latest zypper MAN pages,
Although it’s not consistent with what is trying to be accomplished here, I found that the releasever option can be used to create a custom variable or name, so technically speaking if done right FOOBAR can actually show up as a $releasever value if done correctly.

Learned something new today although not in the way it’s being used here.


No, he hasn’t. Ask him to post (or check on an openSUSE system you have access to, no need to be root):

grep baseurl /etc/zypp/repos.d/*.repo

to see what is really there.
The zypper lr list does NOT show what is in those files, it shows what is in those files after replacement of the $releaver with either the default version (which is the current installed version), or by the string defined in the global zypper option --releasever.

In my post responding to him,
I included the snippet of his posting and highlighted his FOOBAR values in his repo URI in bold red.


I know that he has FOOBAR in several of the lines of his zypper lr -d, and I also know why. Because I asked him to do so. It is me that introduced the word FOOBAR in this thread by asking him to do

zypper --releasever FOOBAR lr -d

I know you highlighted this as FOOBAR in your snippet, but you still fail to see why it is there in the first place.

There is no FOOBAR in /etc/zypp/repos.d/*.repo. And I asked you to look in your own system, but you are too stubborn to do so. You can do the

zypper --releasever lr -d

on your own system, but you are too lazy to do so.

I stop this discussion. There is no use to repeat saying “yes” and “no” to each other where I every time show things from the zypper man page and from my system and ask you to do the same, but you refuse to gather evidence of your statements. In short: useless discussion on deaf ears.

As a last try:

boven:~ # zypper --releasever STUPID lr -d |grep main
 6 | main                 | Main (OSS)             | Yes     | (r ) Yes  | Yes     |   99     | rpm-md |            | 
 7 | main-non-oss         | Main (Non-OSS)         | Yes     | (r ) Yes  | Yes     |   99     | rpm-md |        | 
boven:~ # zypper --releasever STUBBORN lr -d |grep main
 6 | main                 | Main (OSS)             | Yes     | (r ) Yes  | Yes     |   99     | rpm-md |            | 
 7 | main-non-oss         | Main (Non-OSS)         | Yes     | (r ) Yes  | Yes     |   99     | rpm-md |        | 
boven:~ #