#3528 Issue `open`: debian 13, libsystemd-core-25*, restore does not work¶

Labels: support / question, old version

speefak opened issue at 2025-10-15 12:37:¶

ReaR version : /usr/sbin/rear -V Relax-and-Recover 2.7 / Git¶

Describe the ReaR bug in detail¶

Hi,

I’ve been using ReaR for several years to create “installable” ISO images from preconfigured VMs. On Debian 12 everything worked perfectly, but on Debian 13 it seems some paths have changed, causing the following error during ISO creation:

Copying all files in /lib*/firmware/
Testing that the recovery system in /var/tmp/rear.NFEXo6mcvv4JqAn/rootfs contains a usable system
/usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-257.so requires additional libraries
    libsystemd-shared-257.so => not found
ReaR recovery system in '/var/tmp/rear.NFEXo6mcvv4JqAn/rootfs' needs additional libraries, check /var/log/rear/rear-D13-netinstall-clon-source.log for details

After searching for solutions, I found a partial workaround:

echo "/usr/lib/x86_64-linux-gnu/systemd" > /etc/ld.so.conf.d/libsystemd-core.conf
ldconfig

This resolved the missing library, but then another issue appeared:

Symlink '/usr/share/misc/magic' -> '/usr/share/file/magic' refers to a non-existing directory on the recovery system.
It will not be copied by default. You can include '/usr/share/file/magic' via the 'COPY_AS_IS' configuration variable.

After researching this, I added the following line to /etc/rear/local.conf:

COPY_AS_IS+=( /usr/share/file /usr/lib/systemd /lib*/firmware )

Now, the ISO builds without errors. However, during automatic restore, ReaR gets stuck in a loop displaying:

Started getty@tty1.service - Getty on tty1

After approximately 3 minutes, the screen goes blank and nothing happens.

It seems like the Recovery ISO is incomplete or missing some essential paths/files for Debian 13 automatic restore.

Are there updated best practices for creating ReaR recovery ISOs on Debian 13?
Is there a recommended way to include all systemd-related libraries and other necessary paths so the restore boots reliably?
Could this be related to changes in systemd or the getty services on Debian 13?

cat /etc/rear/local.conf

        OUTPUT=ISO
        ISO_DIR=/mnt/speefak@192.168.1.20_ReaR/ReaR_Backups
        ISO_PREFIX="D13-TESTING"
        OUTPUT_URL=null
        BACKUP=NETFS
        BACKUP_URL="iso:///backup"

              # TESTING OPTIONS
COPY_AS_IS+=( /usr/share/file /usr/lib/systemd /lib*/firmware )
PROGS+=( systemd )

        # increase data compression by using pigs instead of gzip
        BACKUP_PROG_COMPRESS_OPTIONS=( --use-compress-program=pigz )
        REQUIRED_PROGS+=( pigz )

        # input timeout for autorecover
        USER_INPUT_TIMEOUT=30

        # resize partitions
        AUTORESIZE_PARTITIONS=true

        # disable iso filesize limit => 0 (default 2 GB ISO_FILE_SIZE_LIMIT=2147483648)
        ISO_FILE_SIZE_LIMIT=0

Terminal output:

rear -v mkbackup
Relax-and-Recover 2.7 / Git
Running rear mkbackup (PID 17078 date 2025-10-15 15:11:03)
Using log file: /var/log/rear/rear-D13-netinstall-clon-source.log
Running workflow mkbackup on the normal/original system
Using backup archive '/var/tmp/rear.qItqomMl3231B0c/tmp/isofs/backup/backup.tar.gz'
Using autodetected kernel '/boot/vmlinuz-6.12.48+deb13-amd64' as kernel in the recovery system
Creating disk layout
Overwriting existing disk layout file /var/lib/rear/layout/disklayout.conf
Using guessed bootloader 'GRUB' for 'rear recover' (found in first bytes on /dev/sda)
Verifying that the entries in /var/lib/rear/layout/disklayout.conf are correct
Created disk layout (check the results in /var/lib/rear/layout/disklayout.conf)
Creating recovery system root filesystem skeleton layout
To log into the recovery system via ssh set up /root/.ssh/authorized_keys or specify SSH_ROOT_PASSWORD
Copying logfile /var/log/rear/rear-D13-netinstall-clon-source.log into initramfs as '/tmp/rear-D13-netinstall-clon-source-partial-2025-10-15T15:11:09+02:00.log'
Copying files and directories
Copying binaries and libraries
Copying all kernel modules in /lib/modules/6.12.48+deb13-amd64 (MODULES contains 'all_modules')
Copying all files in /lib*/firmware/
Testing that the recovery system in /var/tmp/rear.qItqomMl3231B0c/rootfs contains a usable system
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
Created initrd.cgz with gzip default compression (164603054 bytes) in 15 seconds
Making backup (using backup method NETFS)
Creating tar archive '/var/tmp/rear.qItqomMl3231B0c/tmp/isofs/backup/backup.tar.gz'
Archived 851 MiB [avg 34897 KiB/sec] OK
Archived 851 MiB in 26 seconds [avg 33555 KiB/sec]
Making ISO image
Wrote ISO image: /mnt/speefak@192.168.1.20_ReaR/ReaR_Backups/D13-TESTING_OS.iso (1.1G)
Exiting rear mkbackup (PID 17078) and its descendant processes ...
Running exit tasks

Recover alleready stuck when loading getty@tty1

Thank you for any guidance!

Platform¶

Linux ARM64

OS version¶

debian 13

Backup¶

No response

Storage layout¶

No response

What steps will reproduce the bug?¶

No response

Workaround, if any¶

No response

Additional information¶

No response

pcahyna commented at 2025-10-15 14:20:¶

/lib/modules/6.12.48+deb13-amd64

How's that possible if your platform is Linux ARM64?

Regarding "/usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-257.so requires additional libraries" IIRC this is an informational message that does not prevent successful generation of a rescue image, so you can ignore it for experiments.

Have you tried a version later than 2.7 ?

jsmeix commented at 2025-10-15 14:29:¶

@speefak FYI :

My generic boilerplate regarding Ubuntu / Debian
and Linux distributions which are based on them:

I am neither a Ubuntu nor Debian nor Linux Mint user.
Currently we at ReaR upstream do not have an active
maintainer for Ubuntu / Debian / Linux Mint.
So ReaR support for Ubuntu / Debian / Linux Mint
can be only as good as voluntary contributors
who use those Linux distributions contribute
which is much appreciated!

In particular regarding Ubuntu:
It seems Canonical is not sufficiently interested in ReaR
in contrast to Red Hat and SUSE who pay developers
(like me from SUSE and e.g. @pcahyna and @lzaoral from Red Hat)
to contribute to upstream ReaR because Red Hat and SUSE
support ReaR in their enterprise Linux distributions.

jsmeix commented at 2025-10-15 14:50:¶

@speefak

first and foremost:
In general it is not a bug when a software
which worked OK in known environments
does no longer work in new and unexpected environments.
It depends whether or not a change in the environment
is a bug in the environment or a proper new way
whether or not issues because of such a change
would need to be fixed in the environment
or if enhancements are neded in current software
to adapt existing software to new environments.

In ReaR 2.9 I improved things a bit to better
deal with this "systemd private library" issue.
But - as far as I see - ReaR cannot fix it when
'ldd' reports that it cannot find a needed library.
When 'ldd' reports that it cannot find libraries
for programs within the ReaR recovery system, then
ReaR forwards that finding to you and then you
must make a decision if what ReaR reported to you
is actually an issue in your specific case or not.
For details see the GitHub issues and pull requests
regarding this "systemd private library" issue.
You may use
https://github.com/rear/rear/blob/rear-2.9/doc/rear-release-notes.txt#L600
as a starting point.

If you found a generically working solution
how ReaR could automatically and correctly deal
with this "systemd private library" issue, then
contribute your enhancement as GitHub pull request
to us and all other ReaR users.
Please follow our coding style recommendations in
https://github.com/rear/rear/wiki/Coding-Style

speefak commented at 2025-10-15 14:53:¶

No support for Debian and other deb-based distros sounds bad.

The latest ReaR version in the Debian 13 repositories is 2.7. After several hours of trial and error with version 2.7, I decided to upgrade to the latest release. The latest version on GitHub is 2.9.

I usually avoid installing software outside the official Debian repositories, because in the past, some non-repo software caused issues on production systems — which is never good.
However, I wanted to try ReaR 2.9, so I cloned the Git repository, installed the required development tools, and ran make.

My goal was to build a proper Debian package (.deb) to install via apt on other systems.
But using the latest master branch (https://github.com/rear/rear/archive/refs/heads/master.zip) caused build errors.

After some searching, I found the official Debian tracker page for ReaR:
👉 https://tracker.debian.org/pkg/rear

This page points to a working upstream source:

A new upstream version is available: [2.9](https://github.com/rear/rear/archive/refs/tags/release/2.9.tar.gz)

With that, I successfully built and installed ReaR 2.9 using these steps:

bash
apt install devscripts
mkdir rear_v2.9_source
cd rear_v2.9_source
wget https://github.com/rear/rear/archive/refs/tags/release/2.9.tar.gz
tar -xvf release-2.9.tar.gz
cd rear-release-2.9
make deb
apt install ./var/tmp/build-rear-2.9-git.0.0.unknown/rear_*.deb dist/rear_2.9-git.0.0.unknown_amd64.deb

Now ReaR 2.9 is working fine on Debian 13, and I can continue testing the recovery ISO creation and restore process.

The latest code from Github is from October 2025 and causes errors while build process. The Source code from Debian Package Tracker works (code from January 2025). Deb building via make deb works, install the builded deb package works and rear works again. Image building and recover works fine. The error message when rear create and check its rootfs :

Copying binaries and libraries
Copying all kernel modules in /lib/modules/6.12.48+deb13-amd64 (MODULES contains 'all_modules')
Copying all files in /lib*/firmware/
Symlink '/usr/share/misc/magic' -> '/usr/share/file/magic' refers to a non-existing directory on the recovery system.
It will not be copied by default. You can include '/usr/share/file/magic' via the 'COPY_AS_IS' configuration variable.
Testing that the ReaR recovery system in '/var/tmp/rear.7QVpDBWPkvPSQmj/rootfs' contains a usable system
usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-257.so requires libraries where 'ldd' shows 'not found'
usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-257.so requires libsystemd-shared-257.so which exists as usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-257.so
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression

This Error message is still present but restore works, so i think i can ignore this message

jsmeix commented at 2025-10-15 15:23:¶

@speefak
I don't see an actual Error message.

If there is something where it is known it means an actual error,
then ReaR will abort with an "ERROR: ..." message.

The part

Symlink '/usr/share/misc/magic' -> '/usr/share/file/magic' refers to a non-existing directory on the recovery system.
It will not be copied by default. You can include '/usr/share/file/magic' via the 'COPY_AS_IS' configuration variable.

is an information where you must decide
if this means problems for your particular use case
or if you can safely ignore it.

Also

usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-257.so requires libraries where 'ldd' shows 'not found'
usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-257.so requires libsystemd-shared-257.so which exists as usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-257.so

is an information where you must decide
if this means problems for your particular use case
or if you can safely ignore it.

The behaviour in ReaR 2.9 is not yet fully correct, see
https://github.com/rear/rear/issues/3021#issuecomment-2717780623
i.e.
https://github.com/rear/rear/issues/3414
where its fix
https://github.com/rear/rear/pull/3497
is after the ReaR 2.9 release
i.e. currently only in our GitHub master code
so you may have a look at the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery
cf. the "QUICK START GUIDE" on
https://github.com/rear/rear

By the way FYI:
https://schlomo.schapiro.org/2015/04/warning-is-waste-of-my-time.html

pcahyna commented at 2025-10-15 15:51:¶

No support for Debian and other deb-based distros sounds bad.

The latest ReaR version in the Debian 13 repositories is 2.7. After several hours of trial and error with version 2.7, I decided to upgrade to the latest release. The latest version on GitHub is 2.9.

Yeah, I would not call a bug if older version of ReaR does not work on a new version of Debian. We do not maintain the package in Debian. According to your report, it would be helpful if the Debian maintainer updated the package to 2.9.

I usually avoid installing software outside the official Debian repositories, because in the past, some non-repo software caused issues on production systems — which is never good. However, I wanted to try ReaR 2.9, so I cloned the Git repository, installed the required development tools, and ran make.

My goal was to build a proper Debian package (.deb) to install via apt on other systems. But using the latest master branch (https://github.com/rear/rear/archive/refs/heads/master.zip) caused build errors.

After some searching, I found the official Debian tracker page for ReaR: 👉 https://tracker.debian.org/pkg/rear

This page points to a working upstream source:

A new upstream version is available: [2.9](https://github.com/rear/rear/archive/refs/tags/release/2.9.tar.gz)

With that, I successfully built and installed ReaR 2.9 using these steps:
bash
apt install devscripts
mkdir rear_v2.9_source
cd rear_v2.9_source
wget https://github.com/rear/rear/archive/refs/tags/release/2.9.tar.gz
tar -xvf release-2.9.tar.gz
cd rear-release-2.9
make deb
apt install ./var/tmp/build-rear-2.9-git.0.0.unknown/rear_*.deb dist/rear_2.9-git.0.0.unknown_amd64.deb
Now ReaR 2.9 is working fine on Debian 13, and I can continue testing the recovery ISO creation and restore process.

The latest code from Github is from October 2025 and causes errors while build process.

Sounds like an actual problem that could be fairly easy to fix, what errors do you get?

The Source code from Debian Package Tracker works (code from January 2025). Deb building via make deb works, install the builded deb package works and rear works again. Image building and recover works fine.

Good to hear!

The error message when rear create and check its rootfs :

Copying binaries and libraries
Copying all kernel modules in /lib/modules/6.12.48+deb13-amd64 (MODULES contains 'all_modules')
Copying all files in /lib*/firmware/
Symlink '/usr/share/misc/magic' -> '/usr/share/file/magic' refers to a non-existing directory on the recovery system.
It will not be copied by default. You can include '/usr/share/file/magic' via the 'COPY_AS_IS' configuration variable.
Testing that the ReaR recovery system in '/var/tmp/rear.7QVpDBWPkvPSQmj/rootfs' contains a usable system
usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-257.so requires libraries where 'ldd' shows 'not found'
usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-257.so requires libsystemd-shared-257.so which exists as usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-257.so
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression

This Error message is still present but restore works, so i think i can ignore this message

Strange, I thought that this was fixed via #3250 which should be present in 2.9 .

speefak commented at 2025-10-15 16:05:¶

"Strange, I thought that this was fixed via https://github.com/rear/rear/pull/3250 which should be present in 2.9 ."
=> This is the output from january codebase, perhabt in the october release it is fixed.

I`ll create a new debian 13 netinstall VM to test the latest october again and send you detail make error infos. now all vms are update to rear 2.9 (jan)

jsmeix commented at 2025-10-16 07:17:¶

Info messages (via LogPrint when ReaR runs in verbose mode) like

usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-257.so requires libraries where 'ldd' shows 'not found'
usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-257.so requires libsystemd-shared-257.so which exists as usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-257.so

is the latest state, see
https://github.com/rear/rear/pull/3250
see also
https://github.com/rear/rear/pull/3308
Both pull requests were merged into ReaR 2.8
so they are in in ReaR 2.9.

See
https://github.com/rear/rear/pull/3308#issuecomment-2328876718
how normally things should look like.

Only
https://github.com/rear/rear/issues/3414
with its fix
https://github.com/rear/rear/pull/3497
was merged after the ReaR 2.9 release.

pcahyna commented at 2025-10-31 19:26:¶

@speefak so I would say that the messages are due to using the -v (verbose) flag and without it you would not see them.

It seems that there is only one actual problem left: the build errors that you got:

The latest code from Github is from October 2025 and causes errors while build process.

Can you please provide a copy of these build error messages?

schoekek commented at 2025-11-16 18:16:¶

I'm the new rear Debian maintainer. Version 2.9 is already in unstable; a backport for stable (deb13) is in preparation and should be released in the next few days.

[Export of Github issue for rear/rear.]

#3528 Issue open: debian 13, libsystemd-core-25*, restore does not work¶

speefak opened issue at 2025-10-15 12:37:¶

ReaR version : /usr/sbin/rear -V Relax-and-Recover 2.7 / Git¶

Describe the ReaR bug in detail¶

Platform¶

OS version¶

Backup¶

Storage layout¶

What steps will reproduce the bug?¶

Workaround, if any¶

Additional information¶

pcahyna commented at 2025-10-15 14:20:¶

jsmeix commented at 2025-10-15 14:29:¶

jsmeix commented at 2025-10-15 14:50:¶

speefak commented at 2025-10-15 14:53:¶

jsmeix commented at 2025-10-15 15:23:¶

pcahyna commented at 2025-10-15 15:51:¶

speefak commented at 2025-10-15 16:05:¶

jsmeix commented at 2025-10-16 07:17:¶

pcahyna commented at 2025-10-31 19:26:¶

schoekek commented at 2025-11-16 18:16:¶

#3528 Issue `open`: debian 13, libsystemd-core-25*, restore does not work¶