The problem with mount -a is that it runs busybox/toybox mount with fake generated fstab (which is left only for compatibility with command-line tools) on H9/H10 recoveries. It is not really needed to mount any specific partitions on these devices, since we have fake cache set up with userdata partition and it is left mounted.
Halium 10 particular issue is that Android 10 moved binaries from /bin to /system/bin and so on. If UBPorts rootfs gets mounted over /system, things break horribly. It may work fine on first run when system is erased (e. g. during bootstrap or by wiping manually), so it may go unnoticed for some time (like on recently added miatoll device), but is going to cause issues later on.
It can (and likely will be) workarounded in device recoveries by changing /system to /system_root in fstab, but better to avoid executing at all mount -a if we can.
See https://github.com/ubports/ubports-installer/blob/master/src/core/plugins/adb/plugin.js#L207
The problem with mount -a is that it runs busybox/toybox mount with fake generated fstab (which is left only for compatibility with command-line tools) on H9/H10 recoveries. It is not really needed to mount any specific partitions on these devices, since we have fake cache set up with userdata partition and it is left mounted.
Halium 10 particular issue is that Android 10 moved binaries from /bin to /system/bin and so on. If UBPorts rootfs gets mounted over /system, things break horribly. It may work fine on first run when system is erased (e. g. during bootstrap or by wiping manually), so it may go unnoticed for some time (like on recently added miatoll device), but is going to cause issues later on.
It can (and likely will be) workarounded in device recoveries by changing /system to /system_root in fstab, but better to avoid executing at all
mount -a
if we can.