My notes for updating 15.1 to 15.2

English Install/Boot/Login
#1

I have updated about 12 machines from 15.1 to 15.2 - 6 real and 6 virtualbox machines. Here are lessons learned.

first - make sure you are up to date

sudo zypper ref ; zypper up

reboot if any library need rebooting

second - for everyone check your repo’s to see if you have 15.1 or $releasever on you http lines.
if you have 15.1 replace all the 15.1 with $releasever

to see:
grep http /etc/zypp/repos.d/*

to fix

sudo sed -i ‘s/15.1/$releasever/g’ /etc/zypp/repos.d/*.repo

If your 15.1 machine is a guest in virtualbox you need to remove the old virtualbox entries

sudo zypper rm virtualbox*

now disable added repos like packman and adobe

to see the repo numbers

sudo zypper lr

to disable

sudo zypper mr -d # # (where # is the repo number from the list)

I got burned by packagekit running and refreshing the repos’s so we need to kill packagekitd

sudo pkill packagekitd

this next section works for wifi and ethernet - it is required for wifi

sudo zypper -vvv --releasever 15.2 ref

sudo zypper -vvv --releasever 15.2 dup --download only --allow-vendor-change

when this finishes you have to get into a console

in VirtualBox guests you use right-ctl+insert+f1 (or f2 or f3) it may be slow keep trying - it may need to switch to get root to type in - I went f3 then f1 to get root.

on real computers you use crtl+alt+f1 (of f2 or f3)

at login

root
your root password

init 3 (important to kill the gui or things can go wrong - don’t worry about any lines that follow this - press return/enter if garbage is on the prompt line after this)

zypper -vvv --releasever dup --allow-vendor-change

say yes to questions on license ctrl+c out and say yes

when done
if this is virtualbox guest

zypper rm virtual*

for all

zypper mr -e # # (this is the same as you disabled above)

reboot

#2

That looks pretty good.

For my own systems, I did clean installs of 15.2. But for testing online upgrade, I did pretty much what you describe.

I did the test in KVM virtual machines, so I did not need to remove any virtualbox packages (there weren’t any). The KVM guess support packages are part of the repo, and upgraded without a problem. Any needed kernel modules are part of the kernel already – which is the advantage of KVM over virtualbox.

I did not do the “–download-only” prior step. But I have a pretty good Internet connection (fiber).

#3

I got burned by packagekit doing a “zypper ref” before I could do the dup step on wifi only laptops.
doing an “init 3” kills the wifi connection so you have to pre-load the upgrade.

The suggestion on this board said to pkill packagekitd but that does not work in 15.1 but I found away to prevent it by making it unexecutable.

I would change the “pkill packagekitd” to
chmod 000 /usr/lib/packagekitd

and

before the reboot
chmod 755 /usr/lib/packagekitd

#4

Forgot an option --no-refresh is needed for wifi or it will hang

sorry about that - I just did another wifi and got caught.

after the init 3

init 3

zypper -vvv --releasever --no-refresh dup --allow-vendor-change

#5

Your described procedure looks like it should work, no problems jump out at me.

But here are some informational comments…

  • If you want to save yourself a step, a zypper up will always check whether a refresh is needed before actupally doing the update, so there is no need to explicitly do a refresh first

  • rebooting is generally only required if a process is active and a reboot is needed to create a new process to replace the old. This isn’t usually associated with a library but something more critical to a running system like the kernel itself. But, especially before an upgrade, when in doubt be safe and reboot.

  • I think using $releaserver is great, but when a first attempt to implement a year ago, it wasn’t clear how any system would already be using the variable or explicitly use a version number. Even today, I’m surprised that some systems seem to be using $releaserver but don’t know how their systems are configured that way. I’ve even installed some 15.1 recently with freshly downloaded media so I don’t know that can be one way how it happened, and all machines have been updated regularly without “15.1” explicitly set, so I doubt changes could have been pushed that way, either. Wish someone could clear up this mystery, but if the majority or all systems can be migrated to using the $releaserver variable, I’m all for it.

  • Since VBox virtual machines are so easy to backup by simply copying the machine files, for simplicity I’d recommend just doing that and then upgrade using a windowed console which would be easiest and should work something like 95% of the time… Instead of trying to change to real console for upgrading. In any case, running the old init 3 and init 5 commands doesn’t guarantee what you expect when in systemd… It’s documented that systemd will attempt to switch you to the console you want, but will switch you to a different console if it’s already being used for something else. IIRC there is supposed to be a higher likelihood of multiple consoles running when running the Gnome desktop. So, given all the uncertainties people should recognize that whatever you do to try to upgrade in a real console, it’s only a “best effort.”

  • When you reference specific repos, you can do so using any unique identifier, not just the enumeration number. So, for example if you know that Packman is always (or nearly always) added using the same name, then you can just use that name instead of listing all the repos and looking for the enumeration on that particular system.

  • I’ve upgraded several machines with Packman enabled. I’m currently of the opinion fewer errors are thrown and things broken if I leave Packman enabled.

  • Not sure what you’re doing when you remove virtualbox packages… I would guess that if you’re not moving the virtual machine to a new HostOS, the guest packages should remain the same. Or, if the HostOS itself is upgraded, then maybe the Guest packages might be upgraded to be consistent with whatever version is running on the HostOS. Lots of permutations, so I guess YMMv…

And, perhaps does not apply to you but if any Servers or machines are running “big” applications like webservers, database apps, etc then those should be considered and researched before doing an upgrade.

HTH,
TSU

#6

Virtualbox over time in 15.1 leaves a lot of unneed modules from older versions so I remove them before the update.
The virtualbox code that installs during the upgrade sometime leaves a blank screen.
By removing it I guaranty a working screen.
The zypper up afterwards will install the good virtualbox kernel driver.

#7

Good to know!
+1

TSU

#8

It is the virtualbox-guest-X11 that has the issue.
When it is installed - you get black screen.