#3590 Issue open: Migrating Digitalocean droplet to Hetzner VPS: hangs on booting rescue media via kexec¶
Labels: support / question
dfear opened issue at 2026-03-24 13:31:¶
ReaR version¶
Relax-and-Recover 2.9 / 2025-02-13
Describe the ReaR bug in detail¶
I am using a guide (https://abbbi.github.io/hetzner/)
to migrate a Digitalocean droplet to a Hetzner VPS
using ReaR and kexec.
I am not 100% sure that the rescue media is being created correctly.
Here is the output from running, "sudo rear mkrescue -d"
(on the Digitalocean droplet):
Relax-and-Recover 2.9 / 2025-02-13
Running rear mkrescue (PID 370982 date 2026-03-23 22:20:11)
Command line options: /usr/sbin/rear mkrescue -d
Using log file: /var/log/rear/rear-vps1.log
Using build area: /var/tmp/rear.L0LpN1mL3kJs0Bw
Setting TMPDIR to ReaR's '/var/tmp/rear.L0LpN1mL3kJs0Bw/tmp' (was unset when ReaR was launched)
Running 'init' stage ======================
Running workflow mkrescue on the normal/original system
Running 'prep' stage ======================
Using '/usr/bin/xorrisofs' to create ISO filesystem images
Secure Boot is not supported, not using Secure Boot shim:
EFI variables are not supported on this system
Using autodetected kernel '/boot/vmlinuz-6.8.0-106-generic' as kernel in the recovery system
Modified ReaR recovery system area after 'prep' stage (/var/tmp/rear.L0LpN1mL3kJs0Bw/rootfs contains regular files)
Running 'layout/save' stage ======================
Creating disk layout
Overwriting existing disk layout file /var/lib/rear/layout/disklayout.conf
Disabling excluded components in /var/lib/rear/layout/disklayout.conf
GRUB found in first bytes on /dev/vda and GRUB 2 is installed, using GRUB2 as a guessed bootloader for 'rear recover'
Skip saving storage layout as 'barrel' devicegraph (no 'barrel' command)
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)
Running 'rescue' stage ======================
Creating recovery system root filesystem skeleton layout
Adding 'console=tty1' to KERNEL_CMDLINE
Adding 'console=ttyS0' to KERNEL_CMDLINE
Handling network interface 'eth0'
eth0 is a physical device
Handled network interface 'eth0'
Handling network interface 'eth1'
eth1 is a physical device
Handled network interface 'eth1'
Skipping 'lo': not bound to any physical interface.
Included current keyboard mapping (via 'dumpkeys -f')
No default US keyboard mapping included (no KEYMAPS_DEFAULT_DIRECTORY specified)
No support for different keyboard layouts (neither KEYMAPS_DEFAULT_DIRECTORY nor KEYMAPS_DIRECTORIES specified)
Copying logfile /var/log/rear/rear-vps1.log into initramfs as '/tmp/rear-vps1-partial-2026-03-23T22:20:19+00:00.log'
Running 'build' stage ======================
Copying files and directories
Copying binaries and libraries
Copying all kernel modules in /lib/modules/6.8.0-106-generic (MODULES contains 'all_modules')
Failed to copy all contents of /lib/modules/6.8.0-106-generic (dangling symlinks could be a reason)
Copying all files in /lib*/firmware/
Skip copying broken symlink '/etc/resolv.conf' target '/run/systemd/resolve/stub-resolv.conf' on /proc/ /sys/ /dev/ or /run/
Skip copying broken symlink '/etc/mtab' target '/proc/379878/mounts' on /proc/ /sys/ /dev/ or /run/
Testing that the ReaR recovery system in '/var/tmp/rear.L0LpN1mL3kJs0Bw/rootfs' contains a usable system
Testing each binary with 'ldd' for 'not found' libraries within the ReaR recovery system
Testing that the existing programs in the PROGS array can be found as executable command within the ReaR recovery system
Testing that each program in the REQUIRED_PROGS array can be found as executable command within the ReaR recovery system
Running 'pack' stage ======================
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
Created initrd.cgz with gzip default compression (792 MiB) in 60 seconds
Running 'output' stage ======================
Making ISO image
Wrote ISO image: /var/lib/rear/output/rear-vps1.iso (810M)
Exiting rear mkrescue (PID 370982) and its descendant processes ...
Running exit tasks
To remove the build area you may use (with caution): rm -Rf --one-file-system /var/tmp/rear.L0LpN1mL3kJs0Bw
There is an error in output of the above command,
but I am unsure if it is causing the rescue media to fail to boot..
The error in the debug output is:
Failed to copy all contents of /lib/modules/6.8.0-106-generic (dangling symlinks could be a reason)
FYI:
Running "sudo rear mkrescue -d" does produce an ISO.
The rescue media is booted from a running Hetzner VPS
using the following command:
kexec --initrd /tmp2/initrd.cgz --command-line="consoleblank=0 systemd.show_status=true console=tty1 console=ttyS0" /tmp2/kernel
Running Kexec does result in the VPS rebooting and
running the kernel and initrd from rescue media;
however the rescue media hangs at the following point:
[ 4.780612] clk: Disabling unused clocks
[ 4.788480] Freeing unused decrypted memory: 2028K
[ 4.792429] Freeing unused kernel image (initmem) memory: 4920K
[ 4.808866] Write protecting the kernel read-only data: 38912k
[ 4.813574] Freeing unused kernel image (rodata/data gap) memory: 1976K
[ 4.869100] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[ 4.870673] Run /init as init process
[ 4.878758] systemd[1]: Inserted module 'autofs4'
[ 4.903531] systemd[1]: systemd 255.4-1ubuntu8.12 running in system mode (+PA
M +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +
BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PC
RE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWOR
K -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
[ 4.919813] systemd[1]: Detected virtualization kvm.
[ 4.922871] systemd[1]: Detected architecture x86-64.
[ 4.925923] systemd[1]: Detected first boot.
[ 4.931667] systemd[1]: Hostname set to.
[ 4.934933] systemd[1]: Initializing machine ID from VM UUID.
[ 4.968610] systemd[1]: /usr/lib/systemd/system/getty@.service:46: Failed to
resolve instance name in DefaultInstance="%I": Invalid slot
[ 4.983474] systemd[1]: /usr/lib/systemd/system/getty@.service:46: Failed to
resolve instance name in DefaultInstance="%I": Invalid slot
[ 4.987690] systemd[1]: Failed to populate /etc with preset unit settings, ig
noring: Invalid slot
Platform¶
Linux x64
OS version¶
"Ubuntu 24.04.4 LTS"
Backup¶
No response
Storage layout¶
NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
/dev/loop0 /dev/loop0 loop squashfs 55.5M /snap/core18/2979
/dev/loop1 /dev/loop1 loop squashfs 55.5M /snap/core18/2999
/dev/loop3 /dev/loop3 loop squashfs 63.8M /snap/core20/2717
/dev/loop4 /dev/loop4 loop squashfs 91.9M /snap/lxd/36554
/dev/loop5 /dev/loop5 loop squashfs 63.8M /snap/core20/2769
/dev/loop6 /dev/loop6 loop squashfs 91.9M /snap/lxd/38333
/dev/loop7 /dev/loop7 loop squashfs 48.1M /snap/snapd/25935
/dev/loop8 /dev/loop8 loop squashfs 48.4M /snap/snapd/26382
/dev/vda /dev/vda virtio disk 25G
|-/dev/vda1 /dev/vda1 /dev/vda virtio part ext4 cloudimg-rootfs 24.9G /
|-/dev/vda14 /dev/vda14 /dev/vda virtio part 4M
`-/dev/vda15 /dev/vda15 /dev/vda virtio part vfat UEFI 106M /boot/efi
What steps will reproduce the bug?¶
Run sudo rear mkrescue -d on a 1 vCPU 1GB Digtalocean Droplet.
Then run
kexec --initrd /tmp2/initrd.cgz --command-line="consoleblank=0 systemd.show_status=true console=tty1 console=ttyS0" /tmp2/kernel
on a "cx23" VPS on Hetzner running "Ubuntu 24.04.4 LTS".
Workaround, if any¶
No response
jsmeix commented at 2026-03-24 14:37:¶
I know nothing about Digitalocean droplet or Hetzner VPS
so I cannot actually help with issues that are specific
for those kind of systems.
In general regarding system migration with ReaR:
ReaR is first and foremost meant to recreate a system
as much as possible exactly as it was before
so normally
"Fully compatible replacement hardware is needed"
see
https://en.opensuse.org/SDB:Disaster_Recovery
In general migrating a system onto different hardware
(where "hardware" could be also a virtual machine)
does not "just work", cf. "Inappropriate expectations" at
https://en.opensuse.org/SDB:Disaster_Recovery
In sufficiently simple cases it may "just work" but in general
do not expect too much built-in intelligence from a program
(written in plain bash which is not a programming language
that is primarily meant for artificial intelligence ;-)
to automatically do the annoying legwork for you.
ReaR is primarily meant to recreate a system
as much as possible exactly as it was before
on fully compatible replacement hardware.
Additionally ReaR supports to migrate a system
but here "supports" means that ReaR provides a lot
that could help you to get such a task done
but it does not mean that it would "just work" without
possibly laborious manual settings and adaptions
with trial and error legwork until you made things work
for you in your particular case.
jsmeix commented at 2026-03-24 14:48:¶
@dfear
do you perhaps have another Digitalocean droplet available
which is fully compatible with your original Digitalocean droplet
where you created the ReaR recovery system with "rear mkrescue"?
If yes, does it work to boot your ReaR recovery system
on your other Digitalocean droplet?
This is only a test to check whether or not
your ReaR recovery system was properly created
according to how ReaR is primarily meant to be used.
It depends how much a Digitalocean droplet behaves
like a usual system on usual hardware or a usual VM
in a usual VM environment (e.g. a QEMU/KVM environment)
whether or not "rear mkrescue" on a Digitalocean droplet
creates a ReaR recovery system which boots on another
fully compatible Digitalocean droplet.
In general if you are not yet experienced with ReaR
you may have a look at the section
"First steps with Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery
[Export of Github issue for rear/rear.]