Lanchon
September 22, 2024, 12:04am
1
i can set the rootfs
partition via the kernel parameter root=/dev/mmcblk0p<n>
.
is there a similar way to set the rootfs_data
partition?
Lanchon
September 23, 2024, 12:55am
3
thanks.
strange... is the project against having it?
so the Spectrum SAX1V1K is an emmc device that has partitions:
kernel
rootfs (128 MiB)
rootfs_data (512 MiB)
and also has A/B versions of these partitions.
current port of this device does not support A/B updates and i want to add them to it. (it also has a buggy sysupgrade but that is another matter.)
here are my options:
leave it as it is (but fix the sysupgrade bug)
do A/B but leave the system using a single rootfs_data (which is a bit dangerous IMHO)
do A/B but store rootfs_data in a loop device behind rootfs, which will reduce rootfs_data from 512 MiB to around 75 MiB.
do A/B but store rootfs_data in a loop device behind rootfs, but store rootfs in the rootfs_data partition (requires uboot env changes and resetting data, and thus is an incompatible sysupgrade)
patch the fstools repo to support rootfs_data selection via kernel arg.
which would be favored by the project?
thanks again
slh
September 23, 2024, 10:28am
4
Disclaimer, this is not my call (not an OpenWrt developer/ commiter), but I would suggest
75 MB is still plenty and this poses the least risk (and there is precedence, e.g. nbg6817).
Lanchon
September 23, 2024, 11:04am
5
thanks.
regarding the device, i PR'd a fix here:
openwrt:main
← Lanchon:sax1v1k-fix-sysupgrade
opened 10:32AM - 23 Sep 24 UTC
Before this commit, sysupgrade saved the settings backup data to the area follow… ing rootfs even though the device has an actual rootfs_data partition. The backup data was completely ignored on the following boot, but since rootfs_data was not being cleared during sysupgrade, the issue was not noticed earlier.
Note that this commit changes the filesystem of rootfs_data from ext4 to F2FS (if OEM partitioning is used).
i'd consider that as being worse current affairs. (given that i already implemented a recovery OS, A/B upgrades are not that important anymore.)
i'd probably go for adding the functionality to fstools. if that's not welcomed, i'd probably not bother with any changes.
Lanchon
September 25, 2024, 3:51am
6
and i also created a PR to allow selection of overlay, let's hope it gets merged:
openwrt:master
← Lanchon:choose-overlay
opened 03:49AM - 25 Sep 24 UTC
hi @hauke @dangowrt @robimarko
Many devices support dual firmwares (`kermel`/… `kernel_1`, `rootfs`/`rootfs_1`). However openwrt only supports dual firmwares on devices for which the overlay is stoted in the trailing part of the active rootfs partition. Devices with discreet overlay partitions (`rootfs_data`/`rootfs_data_1`) are not supported.
This change allows the bootloader to choose which `rootfs_data` partition to use, just like it could always choose which `rootfs`: via a kernel command line parameter.
For example, uboot can now specify `fstools_overlay_name=rootfs_data` or `fstools_overlay_name=rootfs_data_1`. This works for block devices, UBI and MTD, as the system delegates partition name resolution to the usual fstools driver stack.
For completeness, an `fstools_overlay_fstype=ext4`/`f2fs`/`auto` parameter is also included. This selects which filesystem to use when it is time to format the overlay anew.
thank you!
-----
this change has been tested to work properly in spectrum sax1v1k.