#2471 Issue closed: UEFI ISOLINUX boot failed with "Failed to load ldlinux.c32" on Ubuntu 18.04

Labels: enhancement, bug, cleanup, no-issue-activity

cvijayvinoth opened issue at 2020-08-05 13:20:

Relax-and-Recover (ReaR) Issue Template

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

  • ReaR version ("/usr/sbin/rear -V"): 2.6

  • OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):

NAME="Ubuntu"
VERSION="18.04.4 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.4 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
OUTPUT=ISO
BACKUP=RSYNC
RSYNC_PREFIX="$HOSTNAME"
OUTPUT_URL=rsync://diskimage@192.168.1.123::rsync_backup
BACKUP_URL=rsync://diskimage@192.168.1.123::rsync_backup
MESSAGE_PREFIX="$$: "
BACKUP_RSYNC_OPTIONS+=(-z --progress --password-file=/etc/rear/rsync_pass)
PROGRESS_MODE="plain"
AUTOEXCLUDE_PATH=( /tmp )

  • Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
    PC

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
    x86 compatible

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
    UEFI and GRUB

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
    local disk

  • Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT" or "lsblk" as makeshift):

NAME        KNAME       PKNAME   TRAN   TYPE FSTYPE     SIZE MOUNTPOINT
/dev/loop0  /dev/loop0                  loop squashfs    97M /snap/core/9665
/dev/loop1  /dev/loop1                  loop squashfs 140.7M /snap/gnome-3-26-1604/100
/dev/loop2  /dev/loop2                  loop squashfs    55M /snap/core18/1880
/dev/loop3  /dev/loop3                  loop squashfs 140.7M /snap/gnome-3-26-1604/98
/dev/loop4  /dev/loop4                  loop squashfs   2.2M /snap/gnome-system-monitor/148
/dev/loop5  /dev/loop5                  loop squashfs  14.5M /snap/gnome-logs/37
/dev/loop6  /dev/loop6                  loop squashfs  96.5M /snap/core/9436
/dev/loop7  /dev/loop7                  loop squashfs  62.1M /snap/gtk-common-themes/1506
/dev/loop8  /dev/loop8                  loop squashfs  34.7M /snap/gtk-common-themes/319
/dev/loop9  /dev/loop9                  loop squashfs 255.6M /snap/gnome-3-34-1804/33
/dev/loop10 /dev/loop10                 loop squashfs    55M /snap/core18/1754
/dev/loop11 /dev/loop11                 loop squashfs   276K /snap/gnome-characters/550
/dev/loop12 /dev/loop12                 loop squashfs   2.2M /snap/gnome-system-monitor/145
/dev/loop13 /dev/loop13                 loop squashfs 255.6M /snap/gnome-3-34-1804/36
/dev/loop14 /dev/loop14                 loop squashfs   2.3M /snap/gnome-calculator/180
/dev/loop15 /dev/loop15                 loop squashfs   956K /snap/gnome-logs/100
/dev/loop16 /dev/loop16                 loop squashfs   276K /snap/gnome-characters/539
/dev/loop17 /dev/loop17                 loop squashfs   2.4M /snap/gnome-calculator/748
/dev/sda    /dev/sda             sata   disk          465.8G
|-/dev/sda1 /dev/sda1   /dev/sda        part vfat       512M /boot/efi
`-/dev/sda2 /dev/sda2   /dev/sda        part ext4     465.3G /

  • Description of the issue (ideally so that others can reproduce it):

  • Workaround, if any:

  • Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

Failed to load ldlinux c32 when i tried to load rescue (iso) image in my vm.
I am using rsync to backup. I have done a backedup from my physical machine.
I tried to restore it in my VM. But is was throwing error like

Failed to load ldlinux.c32
Boot failed. Press a key to retry.

Please help me on this.

rear-harish.log
VirtualBox_ubuntu-21-rs1_05_08_2020_18_48_30

jsmeix commented at 2020-08-07 11:16:

@cvijayvinoth

In general regarding system migration with ReaR
(e.g. from physical to virtual hardware):

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 ;-)
that would do the annoying legwork for you.

In general ReaR is first and foremost meant to recreate
a system as much as possible exactly as it was before.

Additionally ReaR supports to migrate a system
but here "supports" means that ReaR provides a lot
that should 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.

See also
http://lists.relax-and-recover.org/pipermail/rear-users/2018-November/003626.html

pcahyna commented at 2020-08-10 08:11:

Why does the message mention ISOLINUX if it is on UEFI? I thought that in case of UEFI, ReaR uses GRUB2, not ISOLINUX. And it does not even seem to run under UEFI, because in that case it should mention ldlinux.e64, not ldlinux.c32, no? https://wiki.syslinux.org/wiki/index.php?title=Library_modules

pcahyna commented at 2020-08-10 08:15:

@jsmeix

In general migrating a system onto different hardware
(where "hardware" could be also a virtual machine)
does not "just work"

In particular, migrating bootloader form BIOS to UEFI (and probably also vice-versa, if this is what the OP tried to do) is not supported, cf. #1601

jsmeix commented at 2020-08-10 11:11:

@pcahyna
I added UEFI ISOLINUX to the subject line of this issue because
https://github.com/rear/rear/issues/2471#issue-673534538
reads Firmware ...: UEFI and GRUB and the screenshot
https://user-images.githubusercontent.com/426209/89417444-51ea0900-d74c-11ea-8b00-10b628ae659e.png
contains ISOLINUX so we have some UEFI and GRUB and ISOLINUX issue here.

I am always confused which bootloader is used in which circumstances.

For details what exactly happens during "rear -D mkrescue" see
https://github.com/rear/rear/files/5028604/rear-harish.log

Here an excerpt from
https://github.com/rear/rear/files/5028604/rear-harish.log
what the user should have seen on his terminal

# grep '+ Print ' rear-harish.log | cut -d "'" -f2- | sed -e "s/\\\''//g" -e "s/'$//"#

Running workflow mkrescue on the normal/original system
Found EFI system partition /dev/sda1 on /boot/efi type vfat
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
Using autodetected kernel '/boot/vmlinuz-4.15.0-112-generic' as kernel in the recovery system
Creating disk layout
Overwriting existing disk layout file /var/lib/rear/layout/disklayout.conf
Using guessed bootloader 'EFI' (found in first bytes on /dev/sda)
Verifying that the entries in /var/lib/rear/layout/disklayout.conf are correct ...
Creating recovery system root filesystem skeleton layout
Handling network interface 'enp2s0'
enp2s0 is a physical device
Handled network interface 'enp2s0'
Trying to find what to use as UEFI bootloader...
Trying to find a 'well known file' to be used as UEFI bootloader...
Using '/boot/efi/EFI/ubuntu/grubx64.efi' as UEFI bootloader file
Copying logfile /var/log/rear/rear-harish.log into initramfs as '/tmp/rear-harish-partial-2020-08-05T18:40:17+05:30.log'
Copying files and directories
Copying binaries and libraries
Copying all kernel modules in /lib/modules/4.15.0-112-generic (MODULES contains 'all_modules')
Copying all files in /lib*/firmware/
Skip copying broken symlink '/etc/mtab' target '/proc/20884/mounts' on /proc/ /sys/ /dev/ or /run/
Skip copying broken symlink '/etc/resolv.conf' target '/run/systemd/resolve/stub-resolv.conf' on /proc/ /sys/ /dev/ or /run/
Testing that the recovery system in /var/www/html/imageBackup/iso/rear.3JxcUO7Vwb1pM5x/rootfs contains a usable system
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
Created initrd.cgz with gzip default compression (297649994 bytes) in 27 seconds
GRUB2 modules to load: ext2 fat part_gpt
Making ISO image
Wrote ISO image: /var/www/html/imageBackup/iso/harish/rear-harish.iso (333M)
Copying resulting files to rsync://diskimage@192.168.1.123::rsync_backup location
Copying resulting files to rsync location
Saving /var/log/rear/rear-harish.log as rear-harish.log to rsync location
Exiting rear mkrescue (PID 10435) and its descendant processes ...
Running exit tasks
You should also rm -Rf /var/www/html/imageBackup/iso/rear.3JxcUO7Vwb1pM5x

jsmeix commented at 2020-08-10 12:09:

I am not at all an expert in the ReaR recovery system bootloader area
so I could totally misunderstand things but I think the root cause might be
that usr/share/rear/output/ISO/Linux-i386/300_create_isolinux.sh
https://github.com/rear/rear/blob/master/usr/share/rear/output/ISO/Linux-i386/300_create_isolinux.sh
calls its functions in any case in an unconditioned way
i.e. also in case of UEFI + GRUB as recovery system bootloader

# egrep ' source |GRUB2 modules to load|ldlinux\.c32|Created isolinux configuration' rear-harish.log
...
+ source /usr/share/rear/output/ISO/Linux-i386/250_populate_efibootimg.sh
++ LogPrint 'GRUB2 modules to load: ext2 fat part_gpt'
...
+ source /usr/share/rear/output/ISO/Linux-i386/300_create_isolinux.sh
++ [[ -r /usr/lib/syslinux/modules/efi64/ldlinux.c32 ]]
++ Log 'Created isolinux configuration'

jsmeix commented at 2020-08-10 12:11:

It seems some cleanup bug fixing is needed
in the ReaR recovery system bootloader area.

pcahyna commented at 2020-08-10 12:16:

Could the root cause be that the ISO was created on an UEFI system and booted on a BIOS system? In that case, success is not expected, but the behavior seems a bit strange.

github-actions commented at 2020-10-10 01:45:

Stale issue message

[Export of Github issue for rear/rear.]