#3397 Issue closed: Could not remove build area

Labels: enhancement, fixed / solved / done

xwhitebeltx opened issue at 2025-02-06 14:20:

ReaR version

Relax-and-Recover 2.9 / 2025-01-31

Describe the ReaR bug in detail

Greetings REAR developers =)

i have an ubuntu 22.04 system (this behavior also occurred on RHEL 7.9),
it has a sata SSD /dev/sda as the REAR target, that was formatted by REAR using "rear -v format -- --efi /dev/sda"
i created a backup by executing "rear -v mkbackup" and i get this error right before returning to prompt:

Image

what does "since it's on a different device" mean?

some info about the environment:

cat/etc/rear/local.conf

Image

cat /etc/os-release

Image

lsblk - note that the lsblk shows the still mounted rear mount

Image

it happened recently on two different environments (repeatedly) and i'm not sure how to avoid it or what i'm doing wrong,

can you advise?

Platform

No response

OS version

Ubuntu 22.04

Backup

NETFS

Storage layout

Image

What steps will reproduce the bug?

  1. install latest rear
  2. backup using rear -v mkbackup to a preformatted /dev/sda

Workaround, if any

i can just unmount and delete the folder, but i'm not sure if it this error indicates something is wrong

Additional information

i did not see this error in REAR v2.6 & 2.7 for more than a year of using it

gdha commented at 2025-02-10 08:55:

@xwhitebeltx Could you copy/paste the /etc/fstab file please? And, also the output of grep -v \# /var/lib/rear/layout/disklayout.conf

xwhitebeltx commented at 2025-02-12 15:42:

apologies for the delayed response,
sadly my server was taken away, however i do still have the RHEL 7.9 with the same issue on REAR v2.7 if you are willing to investigate further on a different setup.
(in previous comment i wrote i did not see this issue on v2.7, at the time i thought this RHEL has the latest REAR version)

see screenshots from the second server below including the outputs you requested:
same error from a backup i took today:
Image

attempt to execute the suggested command

Image

rear -V

Image

cat /etc/os-release

Image

grep -v \# /etc/rear/local.conf

Image

grep -v \# /var/lib/rear/layout/disklayout.conf

Image

lsblk

Image

cat /etc/fstab

Image

gdha commented at 2025-02-13 10:11:

@xwhitebeltx Could you just run rear -D mkrescue to see why the temporary rear-efi.xxxx is not unmounted at the end of the rear run?

jsmeix commented at 2025-02-13 10:34:

In
https://github.com/rear/rear/issues/3397#issuecomment-2654100973
the first screenshot shows

"Could not umount EFI partition '...' at '...' (you should do it manually)

which comes from
output/USB/Linux-i386/100_create_efiboot.sh

I guess we may need in
output/USB/Linux-i386/100_create_efiboot.sh
the same kind of umounting code as at the end of
output/ISO/Linux-i386/700_create_efibootimg.sh
see https://github.com/rear/rear/pull/2909
and https://github.com/rear/rear/issues/2908

xwhitebeltx commented at 2025-02-13 14:31:

@gdha of course,

see below screenshots of output:
Image

Image

Image

jsmeix commented at 2025-02-13 14:50:

@xwhitebeltx
does it help when you add in
usr/share/rear/output/USB/Linux-i386/100_create_efiboot.sh
a line with

sleep 3

just before umount $efi_mpt is done, i.e. like this

# Cleanup of EFI temporary mount point:
sleep 3
if umount $efi_mpt ; then
    rmdir $efi_mpt || LogPrintError "Could not remove temporary directory '$efi_mpt' (you should do it manually)"
else
    LogPrintError "Could not umount EFI partition '$efi_part' at '$efi_mpt' (you should do it manually)"
fi

gdha commented at 2025-02-13 14:50:

@xwhitebeltx Could you attach the rear-localhost.log file please? The screenshot doesn't give me any hint.

xwhitebeltx commented at 2025-02-13 15:12:

@jsmeix yes it does, i tried twice, the process completes with no errors, but still gives the message about removing the build area even though it is not mounted (lsblk right after):

Image

@gdha unfortunately my environment makes it very hard to extract files, i can only take screenshots, if it is crucial i can try and obtain it but it can take a few days

jsmeix commented at 2025-02-13 16:37:

@xwhitebeltx
KEEP_BUILD_DIR is automatically set to true
in debug mode (-d) and in debugscript mode (-D)
see usr/share/rear/conf/default.conf
https://github.com/rear/rear/blob/rear-2.9/usr/share/rear/conf/default.conf#L227

xwhitebeltx commented at 2025-02-14 18:42:

@jsmeix thank you, although i'm not sure i fully understand yet, is adding the "sleep 3" line the solution to this issue? or is it a workaround?

jsmeix commented at 2025-02-26 16:20:

https://github.com/rear/rear/pull/3408
intends to avoid this issue, cf.
https://github.com/rear/rear/wiki/Coding-Style#dirty-hacks-welcome

@xwhitebeltx
both ;-)

The added 'sleep' is the solution to this issue
(as far as what we can do in ReaR)
and it is also a workaround for what I think
is some error elsewhere (probably in kernel area)
why 'umount' (sometimes?) fails in such cases nowadays.
I think a sequence of commands like

mount something somewhere
cp somefile somewhere
umount something

should "just work".
But here and also in
https://github.com/rear/rear/issues/2908
that kind of code which had "just worked" "for ages"
recently fails (sometimes?) and in both cases
the "something" is some EFI stuff so it seems

mount some_EFI_stuff somedir
cp somefile somedir
umount somedir

lets 'umount' fail (perhaps with recent kernels?) but

mount some_EFI_stuff somedir
cp somefile somedir
sleep 1
umount somedir

succeeds.

Perhaps there is a general issue with the VFAT filesystem?

jsmeix commented at 2025-03-04 12:11:

With https://github.com/rear/rear/pull/3408 merged
this issue should be sufficiently avoided.

[Export of Github issue for rear/rear.]