What were you trying to do that didn't work?

When executing rear mkbackup to create a UEFI rescue system, the process fails to unmount the loop device used for the EFI System Partition (ESP) image. As a result, the file is copied while still being accessed, leading to a corrupted efiboot.img within the generated ISO.

A customer has encountered this issue. When the resulting ISO is mounted and the internal efiboot.img is checked, the filesystem appears empty or corrupted:

[root@localhost ~]# mount -o loop,ro rear-test.iso /mnt/1
[root@localhost ~]# mount /mnt/1/boot/efiboot.img /mnt/2
[root@localhost ~]# find /mnt/2
/mnt/2
# (No files found) 

The script output/ISO/Linux-i386/700_create_efibootimg.sh fails to unmount the temporary directory because the "target is busy." The script then proceeds to rename/move the image file before the buffers are properly flushed or the mount is released.

The rear log confirms the "target is busy" error during the unmount attempt:

10226 mount: /dev/loop0 mounted on /var/tmp/rear.XXXX/tmp/efi_virt.
...
10233 '.../EFI/BOOT/locale' -> '.../efi_virt/./EFI/BOOT/locale'
10234 umount: /var/tmp/rear.XXXX/tmp/efi_virt: target is busy.
10235 renamed '/var/tmp/rear.XXXX/tmp/efiboot.img' -> '/var/tmp/rear.XXXX/tmp/isofs/boot/efiboot.img' 

The upstream ReaR project has addressed this issue by implementing a retry mechanism and a "lazy unmount" (umount -l) in the following commit: https://github.com/rear/rear/commit/aadf9b40a

 
 
Following this logic, we had the customer modify as follows:

-- /usr/share/rear/output/ISO/Linux-i386/700_create_efibootimg.sh --
-umount $v $TMP_DIR/efiboot.img
+for _ in _ ; do
+    umount $v $TMP_DIR/efi_virt && break
+    sleep 1
+    umount $v $TMP_DIR/efi_virt && break
+    fuser -v -M -m "$TMP_DIR/efi_virt" || Log "'fuser' failed"
+    umount $v --lazy $TMP_DIR/efi_virt && break 
+    LogPrintError "Could not umount efi_virt"
+done 

Implementing this change successfully resolved the customer's issue.
 
Since "target is busy" errors can occur due to various environmental factors during ISO creation, we request that this fix (including the lazy unmount and retry logic) be backported/adopted into the RHEL version of the rear package.

How reproducible is this bug?:

The cause is unknown, but rear execution always results in a umount failure on the customer's system.