Linux client: dm snapshots (option 4) on dracut-based distros & working dracut module

client
1

Yes, this was created with the help of claude.

Image backups of the root filesystem cannot be set up by the installer on
Fedora/RHEL/CentOS/Rocky/Alma/openSUSE. Here is what is missing and a working fix.

Would be nice to see a detection for distros which are using dracut in future updates.

Script and full documentation are in the attached urbackup-dracut-setup.zip
(urbackup-dracut-setup.sh plus README.md).

1. The installer bails out on dracut systems

Choosing 4) Linux device mapper based snapshots and confirming the root device
conversion gives:

Did not find initramfs-tools. Installation failed.
Configured snapshot mechanism via /usr/local/etc/urbackup/snapshot.cfg

The client then reports Image backup: not supported, even with ext4 root.

Cause: in install_client_linux.sh the initramfs integration is guarded by
if [ -e /usr/share/initramfs-tools/hooks ], which only exists on Debian/Ubuntu.
There is no dracut branch.

Fix: a dracut module (91urbackupsnap) that does what
scripts_local-top_urbackup-setup-snapshot does on Debian - create a 1:1 linear
mapping over the root device in a pre-mount hook and point sysroot.mount at
it. Same device name (root-98d1f8b1f435), so the shipped dm_create_snapshot /
dm_remove_snapshot scripts work unmodified.

The attached script installs the module, detects the root UUID automatically and
bakes it into the initramfs, so nothing needs editing per machine:

sudo ./urbackup-dracut-setup.sh            # module + a TEST initramfs only
sudo ./urbackup-dracut-setup.sh --apply    # make it permanent for all kernels
sudo ./urbackup-dracut-setup.sh --verify   # check everything, print fixes
sudo ./urbackup-dracut-setup.sh --cleanup  # clear leftovers of an aborted backup
sudo ./urbackup-dracut-setup.sh --uninstall

The default builds a test image only, so you can try it via a one-shot GRUB edit
(e, change the initrd line, Ctrl+X) without touching the normal boot path.
Every failure path in the hook falls through to a normal boot, and
setup-snapshot=0 on the kernel command line disables it entirely.

--verify also checks the two issues below and prints the exact commands to fix
them.

2. Binaries linked against the Debian soname

urbackupclient_dmsnaptool: error while loading shared libraries:
libdevmapper.so.1.02.1: cannot open shared object file

Fedora ships libdevmapper.so.1.02:

ln -s /lib64/libdevmapper.so.1.02 /lib64/libdevmapper.so.1.02.1 && ldconfig

3. Dependencies installed only via apt

apt-get install thin-provisioning-tools partclone has no RPM counterpart in the
installer:

dnf install device-mapper-persistent-data partclone

Server-side setting

Leave Volumes to backup at C. A mount point like / gives
Could not read MBR; C before root is a dm device gives
Backing up System Reserved (SYSVOL) partition failed. Once the module is active,
C works and includes the ESP automatically. Run a full backup first - an
incremental with no full to base on fails with the same SYSVOL error.

Pitfalls, if this is ever implemented upstream

  1. udevadm settle in a pre-mount hook deadlocks - the hook runs inside the
    event chain it would wait on. Symptom:
    Job dracut-pre-mount.service/start running (2min 52s / no limit).
  2. timeout is not in a default initramfs - wrapped calls silently return
    empty and the hook aborts with no error.
  3. blkid -U <uuid> is unreliable there (no blkid.tab); use
    /dev/disk/by-uuid/<uuid>.
  4. A drop-in in /etc/systemd/system/sysroot.mount.d/ is ignored -
    sysroot.mount comes from dracut-rootfs-generator, before any hook.
    /run/systemd/system/sysroot.mount.d/ at hook time works;
    /run/systemd/generator does not survive daemon-reload.
  5. Write the mount override only after the mapping exists - doing it
    unconditionally hangs the boot forever waiting on a .device unit.
  6. Depend on dracut module dm, not just base, or systemd never sees the
    mapping’s .device unit.
  7. Validate in check(), never install() - a failure in install() aborts the
    whole initramfs build and can leave an unbootable kernel after a kernel update.

Not a bug: what stays after a backup

The -clone, -clone-era, -era-metadata, -era-metadata-access and -origin
devices plus a ~5 MB /.era-meta_* file persist between backups. That is the
dm-era CBT layer and it is meant to stay; -cow-storage and the 5 GB
/.overlay_* are released correctly. Took me a while to realise this was
intended.

An aborted backup does leave a partial era stack that blocks later attempts
(create ioctl on ...-clone-era failed: Device or resource busy). Use the shipped
script first:

/usr/local/share/urbackup/dm_remove_snapshot "<snapid>" "/mnt/urbackup_snaps/<snapid>" "" "" "/"

then remove leftover devices, and only once none remain,
chattr -i + rm the files - deleting them while a snapshot is active can
corrupt the filesystem (cf. the older overlay-files-filling-up-disk thread).

Status

Fedora 44, kernel 7.1.5, ext4 root on NVMe, no LVM, client 2.5.31: full →
incremental → full all succeed repeatedly. Forced fsck after days on the
mapping: clean. SELinux ruled out (same in permissive), no stuck udev cookies.

Possible upstream fix

In the snapn = 4 branch: detect dracut alongside initramfs-tools, ship the
module and run dracut --force --regenerate-all, use dnf/yum for the two
packages, and either link against libdevmapper.so.1.02 or ship both sonames.
Happy to turn this into a PR if useful.

urbackup-dracut-setup.zip (10.1 KB)