Update form openSUSE Leap 15.6 to 16.0

WalterH · 2026-04-13T16:12:44+00:00

openSUSE 15.6 is nearly at the end of its life cycle. The Grommunio developers have resolved the dependency issues for the openSUSE 16.0 packages, so it is t...

DL3HBF

My grommunio runs also as Community Edition on a Synology-224plus-VM with 8 GB RAM

grep -m1 "model name" /proc/cpuinfo - result:
Intel(R) Celeron(R) J4125 CPU @ 2.00GHz

WalterH

Read this article to find out if your CPU is compatible: https://en.opensuse.org/X86-64_microarchitecture_levels

darkstar76

Thank you…

ld.so --help

gives me personally the clearest result regarding the x64-64-v2 requirement (yes, it will work in my case) - independent of a specific virtualization software (or even if there is no virtualization in place…)

WalterH

darkstar76 the last lines ot his command, show the CPU capabilities:

Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4 (supported, searched)
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)

dneuhaeuser

thank you for this howto.
I have one more package conflict while upgrading the appliance:

Problem: 1: das installierte php8-imagick-3.7.0-bp156.4.5.x86_64 erfordert 'php(api) = 20220829', aber diese Anforderung kann nicht bereitgestellt werden
Gelöschte Anbieter: php8-8.2.30-150600.3.25.1.x86_64

 Lösung 1: Folgende Aktionen werden ausgeführt:
  veraltetes php8-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-zlib-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-zip-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-xmlwriter-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-xmlreader-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-dom-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-sysvsem-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-posix-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-pcntl-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-openssl-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-mysql-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-mbstring-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-intl-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-iconv-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-gmp-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-gd-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-ftp-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-fileinfo-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-exif-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-curl-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-ctype-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-bz2-8.2.30-150600.3.25.1.x86_64 beibehalten
  veraltetes php8-bcmath-8.2.30-150600.3.25.1.x86_64 beibehalten
 Lösung 2: Deinstallation von grommunio-files-31.0.13-lp156.1.1.noarch
 Lösung 3: php8-imagick-3.7.0-bp156.4.5.x86_64 durch Ignorieren einiger Abhängigkeiten brechen

Wählen Sie aus den obigen Lösungen mittels Nummer oder Sie (u)eberspringen, (w)iederholen oder brechen (a)b [1/2/3/u/w/a/d/?] (a):

which is the suggested solution for this?

DVCon

plymouth-start is still showing as failed in my setup
UNIT LOAD ACTIVE SUB DESCRIPTION ● plymouth-start.service masked failed failed plymouth-start.service

after disabling it with

`systemctl --now disable plymouth-start.service
The unit files have no installation config (WantedBy=, RequiredBy=, UpheldBy=,
Also=, or Alias= settings in the [Install] section, and DefaultInstance= for
template units). This means they are not meant to be enabled or disabled using systemctl.

Possible reasons for having these kinds of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/, .requires/, or .upholds/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.

WalterH

DVCon If you following this step: 18. Disable the plymouth-start.service, this service is disabled and masked.

DVCon

I did follow step 18.

Duese6

Hi,

I'm also testing the update-path. And @dneuhaeuser I'm also getting the problem with php-imagick which is needed by grommunio-files
So what would be the best option here? 1 or 3 ?

Duese6

And if I go further (in my case I tried Option 1)... there are some more problems...

Resolving dependencies...
Computing distribution upgrade...
10 Problems:
Problem: 1: the installed php8-8.2.30-150600.3.25.1.x86_64 requires 'php-sapi = 8.2.30', but this requirement cannot be provided
deleted providers: php8-cli-8.2.30-150600.3.25.1.x86_64
php8-fpm-8.2.30-150600.3.25.1.x86_64

Problem: 2: the installed php8-mysql-8.2.30-150600.3.25.1.x86_64 requires 'php-pdo = 8.2.30', but this requirement cannot be provided
deleted providers: php8-pdo-8.2.30-150600.3.25.1.x86_64

Problem: 3: the installed php8-bcmath-8.2.30-150600.3.25.1.x86_64 requires 'php = 8.2.30', but this requirement cannot be provided
deleted providers: php8-8.2.30-150600.3.25.1.x86_64

Problem: 4: the to be installed php8-pear-1.10.24-160000.2.2.noarch requires 'php8-phar', but this requirement cannot be provided
deleted providers: php8-phar-8.2.30-150600.3.25.1.x86_64
not installable providers: php8-phar-8.4.10-160000.2.2.x86_64[base]
php8-phar-8.4.16-160000.1.1.x86_64[base]

Problem: 5: the installed php8-bz2-8.2.30-150600.3.25.1.x86_64 requires 'php = 8.2.30', but this requirement cannot be provided
deleted providers: php8-8.2.30-150600.3.25.1.x86_64

Problem: 6: the installed php8-ctype-8.2.30-150600.3.25.1.x86_64 requires 'php = 8.2.30', but this requirement cannot be provided
deleted providers: php8-8.2.30-150600.3.25.1.x86_64

Problem: 7: the installed php8-curl-8.2.30-150600.3.25.1.x86_64 requires 'php = 8.2.30', but this requirement cannot be provided
deleted providers: php8-8.2.30-150600.3.25.1.x86_64

Problem: 8: the installed php8-dom-8.2.30-150600.3.25.1.x86_64 requires 'php = 8.2.30', but this requirement cannot be provided
deleted providers: php8-8.2.30-150600.3.25.1.x86_64

Problem: 9: the installed php8-exif-8.2.30-150600.3.25.1.x86_64 requires 'php = 8.2.30', but this requirement cannot be provided
deleted providers: php8-8.2.30-150600.3.25.1.x86_64

Problem: 10: the installed php8-fileinfo-8.2.30-150600.3.25.1.x86_64 requires 'php = 8.2.30', but this requirement cannot be provided
deleted providers: php8-8.2.30-150600.3.25.1.x86_64

WalterH

Duese6 I've only updated the core product. I'm not sure if the other products are ready for the update to openSUSE 16.0.

just-magic

after Step 19 i could not login again via ssh.
Via VNC Console directly on the CUI my root login works.
Any idea what could be the Problem?

dneuhaeuser

just-magic
I had the same problem. After the upgrade the SSH root login was not permitted anymore.

My solution:
check if you have /etc/ssh/sshd_ config (remove the blankspace after _ )

on my system it was not there, so I copied it from the default file:
cp /usr/etc/ssh/sshd_ config /etc/ssh/sshd_ config (remove 2 blanks after _ )

then edit this file and put:
PermitRootLogin yes

restart service: systemctl restart sshd

PS: is there some kind of security in this forum preventing to post certain pathnames?
I had to put some blanks in the paths, otherwise I was not allowed to post this!?

WalterH

just-magic is the sshd daemon running?
systemctl status sshd
Any changes in the sshd configuration in /etc/ssh/*

Duese6

So, it's me again 😉

So first of all big thanks to @WalterH for his post.
It’s just the nature of things that not all systems are the same. The only remaining issue, in my opinion, is with grommunio-files.

Neither I nor any of my customers are currently using Grommunio-Files.
So I decided to go with Option 2 and uninstall it. Everything else went smoothly, just as described in the instructions.

Grommunio-Files also cannot be "installed later"
The same error occurs.

In the end, the only issue I ran also in the "minor glitch" (step 18 regarding plymouth). @DVCon

I used these commands to remove it.

sed -i 's/splash//g' /etc/default/grub
sed -i 's/quiet//g' /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="rd.plymouth=0"

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

systemctl mask plymouth-start.service plymouth-quit.service plymouth-quit-wait.service
systemctl reset-failed

dneuhaeuser

Duese6
instead of "rd.plymouth=0" I use "plymouth.enable=0" because I like to see all boot messages.

Andy

dneuhaeuser I had the same problem. After the upgrade the SSH root login was not permitted anymore.

Same here and I try with VNC Terminal but without success. I dont know at which step I can modify the mentioned file, I think before of using of command init 6 at step 19.

Same also with Grommunio Files, at this point I also choose step 2.

At the moment I use old Leap 15.6 and try again later.

Duese6

dneuhaeuser

I can confirm that. I didn't notice it right away because I switched to key-based authentication a while ago. So I wasn't actually "locked out." Thanks for the tip.

WalterH

dneuhaeuser When you edit your post, you should be able to save the paths without spaces; at least it works for me.

dneuhaeuser

WalterH
current grommunio-files depends on php8-imagick, for which there is no package in opensuse leap 16 (yet).
on my test system I reinstalled this module from a community repository now:

zypper addrepo https://download.opensuse.org/repositories/home:ecsos:server/16.0/home:ecsos:server.repo
zypper refresh
zypper install php8-imagick-3.8.1-lp160.33.1.x86_64

this seems to work so far, but use at your own risk!

Duese6

WalterH
No issue.

I got it runnig again.
I reinstalled grommunio-fiules with option 2)
Only thing I had to do is getting back my old config:
/var/lib/grommunio-files/config/config.php

I think (may bee) option 3 ( @dneuhaeuser ) from aboves post dose se same.

DVCon

Archive does not seem to be working after the update. At least indexing does not run as scheduled.

dneuhaeuser

Andy
I did the ssh configuration after reboot directly on the console (probably VNC terminal in your case).
You can also try to do this before step 19 reboot, while still connected via ssh.

Andy

I try again later if I´m back in my home office with all my tools. Therefore also step 17, which I exclude in that first round, I want to consider. But it seems I can also work in step 17 after all is running.