resize2fs creates a filesystem with unclean orphan file when resizing
to more than 32GB if the orphan_file option is enabled, resulting in
an unmountable storage partition after initial resize.
Explicitly disable the option until the issue is resolved.
Signed-off-by: Matthias Reichl <hias@horus.com>
In case SYSTEM_SIZE was higher than 1024, mcopy would fail without the
failure being caught. The failure was probably due to invalid geometry
(number of sectors per track too high?). However mformat should be able
to determine the geometry on its own, when no geometry parameters are
supplied. After discussion on IRC with vpeter we came to this solution.
* create temporary folder in the target folder
* use sparse files to create image and partitions
* no extractions of the partitions from image
* modify mcopy alias to copy to the partition sparse file
* add `-o` switch to mcopy alias, so mcopy does not prompt in case of
existing file in the partition
* remove alias for mformat (is used only one time)
* catch errors for mformat/mcopy/mmd
* use mcopy alias when copying files to virtual appliance part1
* move DISK_LABEL setting closer to the part where it is used
* write MBR without test (it should be already present and if not, dd
will fail anyway and error is caught)
* update output when vmdk is created
Co-authored-by: Peter <peter.vicman@gmail.com>
fsck.fat is available in toolchain, so use that instead of fsck from
build host (which may not support checking FAT filesystems).
Signed-off-by: Matthias Reichl <hias@horus.com>
