Vfat boot partition file delete error

EasyOS has the ability to rollback and roll forward, using the Easy Version Control GUI application. Rolling back or forward to a snapshot works fine. However, rolling to another version, does not.

That is, if 'easy.sfs', 'initrd' and 'vmlinuz' have to be replaced in the boot-partition, it is broken.

Yes, you can do it, but it doesn't work from within the initrd. I modified the 'init' script in the initrd to just exit to the commandline, so that I can try some experiments. The boot-partition on my laptop is /dev/mmcblk0p1, and it is mounted on /mnt/mmcblk0p1. Running a commandline shell in the initrd:

# df -h
# rm -f /mnt/mmcblk0p1/easy.sfs
# df -h

'easy.sfs' is 422MB. Before the deletion, 'df' shows 70% of drive used, about 190MB free. Fine, but after running the 'rm', 'ls' shows that 'easy.sfs' is deleted, however 'df' shows the free space is unchanged.

The file is deleted, but the space is not freed!

So, if try to 'cp' a new 'easy.sfs' to the boot-partition, only about 190MB of the file gets copied, then there is an error that has run out of space.

This only happens in the initrd, on the desktop after bootup, deleting 'easy.sfs' works properly.

I do not know the cause of this, nor the cure. Well, I do know what could be done, out of desperation. Unmount 'mmcblk0p1', then run:

# fsck.vfat -aw /dev/mmcblk0p1

Then mount it, then there is a file named like '*.REC', delete that, and the space is then freed up.

But, I want to know why this problem is occurring! 

EDIT:
The penny dropped! I was googling, searching for a reason why this could have happened, and there was one post where the chap said that will happen if the file is "open" when it is deleted.

Yes, of course. In retrospect, I should have seen it straight away. Running a command shell in the initrd:

# df -h
/dev/loop0 431.1M 431.1M 0 100% /tro
aufs       1.8G   1.8M     0%   /tnew
rootfs     1.8G   1.8M     0%   /tnew/dev
...
# losetup -a
/dev/loop0 0 /mnt/mmblk0p1/easy.sfs

 Ha ha, 'easy.sfs' is open, it is mounted in an aufs layer. This situation came in about six months ago. before that, deleting of 'easy.sfs' would have worked, hence version rollback would have worked.

What I did was introduce a layered aufs filesystem on folder /tnew in the initrd, to chroot into and run various utilities, including the Xorg gtkdialog-based keyboard-selection and password-entry GUIs used with the non-English builds of EasyOS.

Now that I know the cause, should be able to fix it. 

EDIT:
The fix was simple, the call to script /sbin/rollback in the 'init' script in the initrd has to occur after /tnew is unmounted, so it was just moved down a bit:

if [ -s /mnt/${WKG_DEV}/${WKG_DIR}.session/.fsckme.flg ];then
 fscheck ${WKG_DRV} ${WKG_DEV} #ex: improper shutdown
 [ $? -ne 0 ] && err_exit "Fatal error when filesystem check"
fi

###umount temporary easy.sfs###
sync
umount tnew/dev/pts
umount tnew/proc
umount tnew/dev
umount tnew
umount tro

#191224 if easy.sfs mounted on /tro (via loop0), rollback fails (easy.sfs seems to delete, but isn't),
# hence moved rollback below unmount /tnew
[ -s /mnt/${WKG_DEV}/${WKG_DIR}.session/.rollback.flg ] && rollback ${WKG_DRV} ${WKG_DEV} ${BOOT_DRV} ${BOOT_DEV} #180602

On the other hand, the call to 'fscheck' has to remain where it is, before /tnew is unmounted.

There is still a problem with rollback. This /tnew stuff was introduced early in 2019, April I think. It means that rolling back to an earlier version from April 2019 onward, will be broken. Rolling back to an earlier session works, only a version jump is broken.

I could patch the initrd of earlier versions with the above fix, but that is messy. Users could do it manually. Or, I might just ignore the problem, as it will "go away", since all releases from now on are fixed. 

Tags: easy