When fstools is unable to parse our root=<...> arg correctly, it can
fall back to scanning all block devices for a 'rootfs_data' partition.
This fallback was deemed wrong (or at least, a breaking/incompatible
change) for some targets, so we're forced to opt back into it with
fstools_partname_fallback_scan=1.
Without this, OnHub devices will use a rootfs-appended loop device for
rootfs_data instead of the intended 3rd partition.
While I'm at it, just move all the boot args into the 'cros-vboot'
build rule, instead of using the custom bootargs-append. All cros-vboot
subtargets here are using the same rootwait (to support both eMMC and
USB boot) and root/partition args.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
[ drop unrelated comments in commit description ]
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
/ {
model = "ASUS OnHub";
compatible = "asus,onhub", "google,arkham", "qcom,ipq8064";
-
- chosen {
- bootargs-append = " rootwait";
- };
};
&qcom_pinmux {
/ {
model = "TP-Link OnHub";
compatible = "tplink,onhub", "google,whirlwind-sp5", "qcom,ipq8064";
-
- chosen {
- bootargs-append = " rootwait";
- };
};
&qcom_pinmux {
# (PARTNROFF=1) partition as their rootfs.
define Build/cros-vboot
$(STAGING_DIR_HOST)/bin/cros-vbutil \
- -k $@ -c "root=PARTUUID=%U/PARTNROFF=1" -o $@.new
+ -k $@ \
+ -c "root=PARTUUID=%U/PARTNROFF=1 rootwait fstools_partname_fallback_scan=1" \
+ -o $@.new
@mv $@.new $@
endef