This is the preparation part of ReaR (i.e. the 'prep' stage) before starting the rescue/recovery system build phase. You should not put scripts into this 'prep' stage that modify things in ROOTFS_DIR or in VAR_DIR/recovery and VAR_DIR/layout because scripts for ROOTFS_DIR belong to the 'rescue' stage and scripts for VAR_DIR/recovery and VAR_DIR/layout belong to the 'layout' stages. The 'prep' stage is used for preparing and configuring ReaR for the later stages, e.g. auto-detect features or settings. Therefore code in 'prep' should not modify ROOTFS_DIR (the rescue/recovery system) but only manipulate ReaR variables or check and prepare requirements so that the 'prep' stage can also be run by workflows which do not make a rescue/recovery system. Reasoning for ROOTFS_DIR: Only those workflows that actually make a rescue/recovery system by running the stages 'rescue', 'build', 'pack', and 'output' (in particular the workflows mkrescue, mkbackup and mkopalpba) should modify something in ROOTFS_DIR. In contrast when other workflows that run the 'prep' stage (e.g. mkbackuponly) modify something in ROOTFS_DIR then all those modifications will be lost because no rescue/recovery system with those modifications is made. So the problem is possible inconsistencies between what gets actually used during "rear recover" (i.e. the last actually made rescue/recovery system) versus what other workflows that run the 'prep' stage may need to have. For example mkbackuponly may need a modified rescue/recovery system when backup config variables need updated values in the recovery system (e.g. an updated value for BACKUP_PROG_EXCLUDE or something similar). The prep/default/990_verify_empty_rootfs.sh script checks at the end of the 'prep' stage that ROOTFS_DIR is unmodified (i.e. still empty).