#3567 Issue closed: openSUSE Tumbleweed no ssh and recovery fails: RPC portmapper 'rpcbind' unavailable¶
Labels: enhancement, fixed / solved / done
svlv opened issue at 2026-02-19 10:20:¶
ReaR version¶
2.9
Describe the ReaR bug in detail¶
Hi,
I've tested backup/restore on openSUSE Tumbleweed 20260209 and encountered several issues:
/etc/ssh/sshd_configwas moved to/usr/etc/ssh/sshd_config. However, it not a big issue, I simply copied it to/etc/ssh/sshd_config. Just something good to know.sshdin the rescue system didn't work due to the following error:
/usr/libexec/openssh/sshd-auth does not exist or is not executable- I was using
BACKUP=NETFSand received the error:RPC portmapper 'rpcbind' unavailable. When I ranrpcinfo -p, the output wasNo remote programs registered.Since I've read that this is in general it is fine for nfsv4 because it is not requiredrpcbind, I commented out the error and was able to finish the recovery successfully.
Platform¶
Linux x64
OS version¶
openSUSE Tumbleweed 20260209
Backup¶
NETFS
Storage layout¶
No response
What steps will reproduce the bug?¶
No response
Workaround, if any¶
No response
Additional information¶
No response
jsmeix commented at 2026-02-19 12:58:¶
@svlv
thank you so much for testing ReaR
even on openSUSE Tumbleweed!
It is very much appreciated.
Some time ago I tested ReaR for the new SUSE SLES 16.
I found different issues at various places.
Several things need to be adapted and enhanced
in ReaR to make it work on SLES 16.
Only as a side note FYI:
openSUSE Tumbleweed is not officially supported by ReaR.
For the reason see in the section
"Supported and Unsupported Operating Systems"
https://github.com/rear/rear/blob/rear-2.9/doc/rear-release-notes.txt#L151
In theory ReaR 2.9 should work on openSUSE Tumbleweed
but in practice arbitrary failures could happen at any time
because the Tumbleweed distribution is a pure rolling release
version of openSUSE containing the latest stable versions
of all software (cf. https://en.opensuse.org/Portal:Tumbleweed)
so arbitrary changes of any software are possible at any time
that could arbitrarily break how ReaR works.
svlv commented at 2026-02-19 13:33:¶
@jsmeix
I understand that, due to the rolling-release model of openSUSE
Tumbleweed, it is difficult to support it officially.
I have been using it for some of my personal and work-related
researches, and I would like to share some findings and possible fixes.
Perhaps this will be useful and save someone some time. If not, and my findings are incorrect or not relevant, that is also fine — please just let me know what I did wrong so I do not repeat the mistake in the future.
I am going to take a look at SUSE Linux Enterprise Server 16; maybe these issues are not present there :)
jsmeix commented at 2026-02-19 14:05:¶
@svlv
your work is useful and it does save someone some time.
This "someone" is in particular me and therefore
I am so thankful for your testing and for your fixes in
https://github.com/rear/rear/pull/3569
A far as I remember what I found during my test on SLES 16
the issues there are same or very similar to those here.
The reason behind is that at a certain point in time
the SLES 16 RPM package sources were basically copied
from what there was in openSUSE Tumbleweed at that time
(except exceptions for special RPM packages).
jsmeix commented at 2026-02-19 14:32:¶
To answer possible questions in advance
why current ReaR 2.9 has issues on SLES 16:
See
https://en.opensuse.org/SDB:Disaster_Recovery
in the section
"Version upgrades with Relax-and-Recover"
(excerpt)
For any kind of innovation that belongs to the basic system
(e.g. kernel, storage, bootloader, init)
the new kind (e.g. ...) will be there first
and afterwards ReaR can adapt step by step to support it.
Because SLES 16 is a new major release of SLES
there are intentionally backward incompatible changes
(in practice it is not possible with reasonable effort
to support old stuff for unlimited time - in particular not
when there is no longer upstream support for old stuff)
and some of those backward incompatible changes break ReaR.
Furthermore in practice it is not possible
(I am alone at SUSE for ReaR and I have also other working areas)
to have ReaR already adapted and enhanced for SLES 16
at the time when the initial SLES 16 release is done
(because it is a too much moving target until its initial release).
In practice this is no severe problem because it is known
that SUSE customers won't use an initial SLES major release
directly "as is" on their production systems.
In practice they use an initial SLES major release
to try out and test things on their test systems
to find out how far the new major release of SLES
will work in their specific production environments.
In practice what I planned to have working for SLES 16
will be the upcoming next ReaR release (i.e. ReaR 3.0).
svlv commented at 2026-02-19 14:51:¶
@jsmeix
Thank you for the explanation!
Yes, It’s clear that some work has to be done first, and that it takes
time, before it will be adapted to new software/hardware
svlv commented at 2026-02-20 08:39:¶
@jsmeix
Today morning I had a chance to test a bit the recovery on SLES 16.
I reproduced all of the issues above. I only forgot to mention that vi
didn't work in the rescue system as well.
I was wondering what is wrong with rpcbind, so I looked though its
source code and likely found the root cause.
On SLES 16, /usr/etc/nsswitch.conf contains the following line:
services: files usrfiles
It allows to look for both /etc/services and /usr/etc/services
files - please see
libnss_usrfiles
for more details.
On SLES 16, /etc/services contains the following line:
#This file was moved to /usr/etc/services. This file will be removed soon.
So only /usr/etc/services includes real services and is used.
Please look for __nss_configure_lookup("services", "files") or just
__nss_configure_lookup in the rpcbind.c for more details.
I guess it is necessary to specialise
nsswitch.conf
for SUSE by adding usrfiles at least for services.
I'll update my patch when I have time (maybe even today).
Just wanted to let you know and wrote down this observation.
svlv commented at 2026-02-20 11:21:¶
strace vi revealed the issue with vi:
...
openat(AT_FDCWD, "/root/.config/libalternatives.conf", O_RDONLY|O_NOFOLLOW|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/libalternatives.conf", O_RDONLY|O_NOFOLLOW|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/libalternatives", O_RDONLY|O_DIRECTORY) = -1 ENOENT (No such file or directory)
exit_group(-1) = ?
+++ exited with 255 +++
To fix it, I added the following lines into local.conf (please note
that I used fresh SLES 16 setup):
COPY_AS_IS+=( /usr/share/libalternatives/vi )
PROGS+=( vim-nox11 )
jsmeix commented at 2026-02-27 13:31:¶
The vi part is not in https://github.com/rear/rear/pull/3569
so I made https://github.com/rear/rear/pull/3575
[Export of Github issue for rear/rear.]