| Message ID | 20230125064207.2518191-1-computersforpeace@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | ipq806x: onhub: Enable fstools_partname_fallback_scan | expand |
diff --git a/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-asus-onhub.dts b/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-asus-onhub.dts index 5b60ddb04b3f..442bcf19a675 100644 --- a/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-asus-onhub.dts +++ b/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-asus-onhub.dts @@ -11,10 +11,6 @@ / { model = "ASUS OnHub"; compatible = "asus,onhub", "google,arkham", "qcom,ipq8064"; - - chosen { - bootargs-append = " rootwait"; - }; }; &qcom_pinmux { diff --git a/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-tplink-onhub.dts b/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-tplink-onhub.dts index 6dd39f0d9584..6adc6be4aec6 100644 --- a/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-tplink-onhub.dts +++ b/target/linux/ipq806x/files-5.15/arch/arm/boot/dts/qcom-ipq8064-tplink-onhub.dts @@ -11,10 +11,6 @@ / { model = "TP-Link OnHub"; compatible = "tplink,onhub", "google,whirlwind-sp5", "qcom,ipq8064"; - - chosen { - bootargs-append = " rootwait"; - }; }; &qcom_pinmux { diff --git a/target/linux/ipq806x/image/chromium.mk b/target/linux/ipq806x/image/chromium.mk index 16af6b95ba6c..f908472419d1 100644 --- a/target/linux/ipq806x/image/chromium.mk +++ b/target/linux/ipq806x/image/chromium.mk @@ -20,7 +20,9 @@ endef # (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
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. NB: it would be nice to allow this rootfs_data partition by default in fstools, but in chats with Ansuel, it sounds like it would be intractable to locate all potentially-breaking targets programmatically. Perhaps we can reconsider (and leverage DEVICE_COMPAT_VERSION for the upgrade-incompatible targets) in the future. 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> --- This patch is only useful once we commit this (and pull in new fstools): https://patchwork.ozlabs.org/project/openwrt/patch/20230125062814.2517900-1-computersforpeace@gmail.com/ [fstools] partname: Correct fstools_partname_fallback_scan comparison .../files-5.15/arch/arm/boot/dts/qcom-ipq8064-asus-onhub.dts | 4 ---- .../arch/arm/boot/dts/qcom-ipq8064-tplink-onhub.dts | 4 ---- target/linux/ipq806x/image/chromium.mk | 4 +++- 3 files changed, 3 insertions(+), 9 deletions(-)