OpenWrt: rootfs_data is deleted after longer power outage?

Banana Pi BPI-R4/BPI-R3 Mini/BPI-R3/BPI-R64/BPI-R2
1

If you configured the BPI R64 and the config is saved in the rootfs_data on the emmc, it is deleted after a longer power outage? @dangowrt? Tested with latest OpenWrt master (self build).

2

rootfs_data is a F2FS formatted filesystem stored on the eMMC permanently and used as overlay on top of the squashfs read-only filesystem. What you are describing sounds like an unwanted reset to factory values, reasons could be

  • accidental trigger of factory reset in OpenWrt
  • filesystem corruption (maybe caused by incomplete write during brown-out?)
  • sysupgrade-related loss of configuration data in case of busy filesystems which prevented kernel partition table reload during sysupgrade (ie. this cannot happen just because of powerless if things have been working before). I have resolved this problem yesterday by the commit below
3

Is there any save way to mitigate all the describes issues? Then I can do a test again. I think I did everything correct and after removing the voltage and after 10 min put it back, everything was reset.

4

Practically this shouldn’t happen if the board is designed well for power-cut situations. If eMMC looses data on brown-out there is usually also not much which can be done about it in software. However, I never experienced any data loss with the R64 and I usually just drag out the power cable to reset it.

Hence I suspect there could be a forth option explaining your problem:

  • you have booted into initramfs/recovery image instead of production. Find out by calling and checking for rootfs_type:
ubus call system board
1 Like
5

I will do some testing again. I sshed (not newest version) now into one and it said:

root@Mesh1:~# ubus call system board
{
	"kernel": "5.10.72",
	"hostname": "Mesh1",
	"system": "ARMv8 Processor rev 4",
	"model": "Bananapi BPI-R64",
	"board_name": "bananapi,bpi-r64",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "SNAPSHOT",
		"revision": "r17781-a889dcd3f2",
		"target": "mediatek/mt7622",
		"description": "OpenWrt SNAPSHOT r17781-a889dcd3f2"
	}
}

Thats wrong? Should be jffs2 or “overlay”?

6

That looks all good. If rootfs_type is initramfs then you will loose configuration on powerloss or reboot.

Booting into initramfs can happen after Kernel crash as the bootloader checks PSTORE for crashlogs and boots into initramfs/recovery (to make sure crashlogs don’t go undetected / unreported).

So what could have happened to you earlier is that you have already been running initramfs at the time the crash happened, not being aware that you were running recovery image.

1 Like
7

Thanks I will do some tests again.

8

Just realized that there is a boot select switch? What should be the default value?

9

Bootswitch sets first device try to load. If set to 0 emmc is tried first…if there is no bootable system (bl2) the other device (sd) is tried. In position 1 it is reversed (first sdcard then emmc).last should be default to get boot from sdcard working if emmc is flashed.

1 Like
10
2 Likes