Zyxel nbg6817 - password not saving and config defaulted after reboot

What about these 2 entries in the dmesg:

[    9.992896] mount_root: overlay filesystem in /dev/mmcblk0p1 has not been formatted yet
[   10.010861] mount_root: no usable overlay filesystem found, using tmpfs overlay

Flashed with an older image that used to work - now dmesg and df looks ok:

dmesg | grep overlay
[    9.886471] mount_root: loading kmods from internal overlay
[   12.792230] mount_root: overlay filesystem has not been fully initialized yet
[   12.797904] mount_root: switching to ext4 overlay
df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                20992     20992         0 100% /rom
tmpfs                   238960     10796    228164   5% /tmp
/dev/loop0               39221      1665     34426   5% /overlay
overlayfs:/overlay       39221      1665     34426   5% /
tmpfs                      512         0       512   0% /dev

Hi,
Have you found any solution? I have your exact same problem. As I have dual boot I returned to the old partition. Then I decided to test not my newest own binary but the daily trunk, and it's the same problem you described: it boots but nothing is stored either. Back to my own older binary. Investigating.... r15695 worked and still works if reflashed. r16xxx, mine or "official" don't.

Thanks

Haven't found a solution yet - latest stable image is ok, self compiled trunk version doesn't work(think official trunk doesn't either - have to check again) - also have to check if it's depending on the partition used - hope to check that today evening.
Seems that sometihng has changed in the meantime that is causing that problem - but how to find out when using a "faulty" image what is wrong? Don't have the time to read release notes of the last x months :see_no_evil:

Thanks,
Just tried the official trunk today to no avail. And I would say that I also flashed both partitions in previous days with the same result, including the dmesg lines that you mentioned.

This is one of the last builds that still works:

cat /etc/openwrt_version
r15995-a1735fe73c
root@TTSherpa:~# uname -a
Linux TTSherpa 5.4.101 #0 SMP Sat Feb 27 15:51:52 2021 armv7l GNU/Linux

All The builds with kernel 5.4.102+ don't work. They show the described behaviour.

Finally re-flashed both partitions with working stable images(had problems flashing one partition - whenever trying to flash it it flashed the other one and rebooted it - finally managed to flash this partition with tftp) - both working with latest stable image - now compiling r15995 since my r15995 doesn't work correctly - would like to use trunk builds that are up-to-date - what can be done to find the reason for this issue ?

The "culprit" commit must be one of these (from bottom, r15995, to top):

b77f21c98a libpcap: update to 1.10.0
d0d5fcada9 kernel/zram: remove obsolete symbol
e12fcf0fe5 busybox: sysntpd: option to bind server to iface
6fe6b631ef mvebu/omnia: fix the device tree
547a932ee9 uboot-envtools: adjust compile patch to version v2021.01
5662f5b114 lantiq: vr9: set the usb led trigger via devicetree
348e098054 lantiq: ltq-tapi: disable KPI and QOS
e410fb159d ltq-vdsl-app: fix -Wundef warnings
23dd786734 lantiq: set maximum kernel size
7995a93744 lantiq: ARV752DPW22: set the usb led trigger via devicetree
cfd1a40583 octeon: re-enable CONFIG_CAVIUM_CN63XXP1 and EdgeRouter image
5ad49ca029 octeon: refresh config for kernel 5.4
c4dd2441e7 tools: add xxd (from vim)
3ffc30f05a selinux-policy: update to version 0.7
024c81adb8 mediatek: add missing 5.10 patches
dfa0a38d1f mediatek: rework support for BananaPi BPi-R64
b102e281a4 uboot-envtools: add defaults for Bananapi BPi-R64
0246e48434 mt7623n-preloader: remove mt7622-preloader
03948995ab uboot-mediatek: rework support for Bananapi BPi-R64 board
049ac36b2f firmware-utils/ptgen: set GPT partition attributes and name
0235186182 mediatek: add alternative UBI NAND layout for Linksys E8450
42f3efec96 uboot-envtools: add defaults for linksys-e8450-ubi
ed50004319 uboot-mediatek: add support for Linksys E8450
c16958e194 arm-trusted-firmware-mediatek: add patch for Fidelix SPI NAND
aa94e34c1d mediatek: add Linksys E8450 support
7a6d074824 kernel: add support for enabling fit firmware partition parser via cmdline
e230345bbc mediatek: add support for configuring BMT table size via device tree
c46ccb69d1 mediatek: mt7622: add Linux 5.10 support
11425c9de2 mediatek: implement bad-block management table support
f439e29130 build: use config.site generated by autoconf-lean, drop hardcoded sitefiles
32c664ff02 toolchain: add autoconf-lean
84a339f015 base-files: add support for restoring config from tmpfs
b7d125f455 fstools: update to git HEAD
6b0295a47d image: extend FIT partition parser for use on eMMC/SDcard
dc5328e7e9 include: use cpio from staging dir
ad54e32651 tools: add cpio
2a27f6f90a kernel: backport pending fix to select CPU_MIPS64
a1735fe73c kernel: bump 5.4 to 5.4.101

Thanks Hiroshi on your next post. I cannot post more than "thrice".

Not probably, that is it.
I thought it should be that or the next one. But I just checked it's the one you mentioned.
So the last good one is r15999
BUILD_ID="r15999-6b0295a47d"

Now I don't know how to proceed, for me it's already uncharted territory.

1 Like

Probably this is the cause:

https://git.openwrt.org/?p=project/fstools.git;a=commit;h=bad1835f27ec31dbc30060b03cc714212275168a

This commit in fstools was pulled into OpenWrt by this commit:

On NBG6817, fstools tries to mount "rootfs_data" (p1) partition in eMMC while booting instead of the loop device in "rootfs" (p5) or "rootfs_1" (p8), after the commit.
But fstools fails to initialize "rootfs_data" partition by any reasons and tmpfs is used instead, I think.

3 Likes

I've noticed this issue when I'm working to add support for Sony NCP-HG100/Cellular (4GB eMMC).
The change in fstools is good for the large rootfs_data (about 1.6GB) of NCP-HG100/Cellular, but not good for NBG6817 with 4MB rootfs_data...

@daniel Do you have any ideas?

3 Likes

Yes, this looks indeed like the culprit.

Just for reference, this is the partitioning on the nbg6817

/dev/mmcblk0p1 aka rootfs_data is only 4 MB in size and shouldn't be used or touched by OpenWrt, it's reserved for the OEM firmware's overlay. OpenWrt should split rootfs or rootfs_1 into squashs (actual rootfs) and overlay (ext4 backed).

3 Likes

The fstools partname driver detects rootfs_data based on the partition name (not to be confused with the filesystem label).
On this device there is this on the eMMC:

   1              34            8225   4.0 MiB     FFFF  rootfs_data

So this is obviously a problem, because there actually is a GPT partition rootfs_data which is very small.
I guess we will have patch fstools to ensure minmum size of rootfs_data partition and skip it otherwise (to handle this special case of a vendor shipping a device with a GPT partition having the name rootfs_data which is too small to be used as that).

diff --git a/libfstools/partname.c b/libfstools/partname.c
index 4560125..72a02c5 100644
--- a/libfstools/partname.c
+++ b/libfstools/partname.c
@@ -54,6 +54,9 @@ static int partname_volume_init(struct volume *v)
 	if (read_uint_from_file(voldir, "size", &volsize))
 		return -1;
 
+	if (volsize < (8*1024*1024))
+		return -1;
+
 	v->type = BLOCKDEV;
 	v->size = volsize << 9; /* size is returned in sectors of 512 bytes */
 	v->blk = p->dev.devpathstr;

Is it possible to allow it to be specified manually by bootargs etc.? Even if rootfs_data exists with the enough size, we may not want it to be used for switching between the images on OpenWrt. Or for other reason, such as not wanting to change the contents of "rootfs_data".

Right now this is hardcoded as fstools is requesting a volume called rootfs_data (as it has always been for MTD and UBI, the new functionality merely adds logic to acquire a volume by name on block partitions as well).
Changing that name would require quite a lot of changes affecting literally ALL devices OpenWrt is running on. We could of course introduce additional hacks and I'd rather have those hacks be target/device specific instead of changing the default for all devices just to cope with the weirdness of a single one.
The solution of adding a cmdline parameter sounds good to me, I'm already parsing cmdline parameters there and it wouldn't be hard to do.

1 Like

Oops, I didn't have enough words, sorry. If any parameter is specified in bootargs, skip searching rootfs_data partition, I think. ("ignore_datapart" ?)

Could be like this:

diff --git a/libfstools/partname.c b/libfstools/partname.c
index 4560125..79e8d1f 100644
--- a/libfstools/partname.c
+++ b/libfstools/partname.c
@@ -120,6 +120,11 @@ static struct volume *partname_volume_find(char *name)
        bool found = false;
        glob_t gl;
 
+       if (get_cmdline_val("ignore_gpt_rootfs_data", rootparam, sizeof(rootparam))) {
+               if (!strcmp("1", rootparam))
+                       return 0;
+       }
+
        if (get_cmdline_val("root", rootparam, sizeof(rootparam))) {
                rootdev = rootdevname(rootparam);
                /* find partition on same device as rootfs */

You will have to set ignore_gpt_rootfs_data=1 (in that way I can reuse the existing parser).

1 Like

Should be fixed by commits

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=2b1aebc0b6e9089ec8e38c2135be76b6af1884b7

and

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=d0d63162b6fab566c0e2eced26773b935c637e46

Please test and report back.

4 Likes

Thanks Daniel.
Thanks everyone. Now working flawlessly

|__| W I R E L E S S F R E E D O M

OpenWrt SNAPSHOT, r16266-d0d63162b6

| Machine: ZyXEL NBG6817 |
| Uptime: 0d, 00:04:37 |
| Load: 0.19 0.53 0.28 |
| Flash: total: 28.5MB, free: 24.6MB, used: 7% |
| Memory: total: 467.2MB, free: 349.2MB, used: 25% |
| WAN: 192.168.0.2, proto: static |
| LAN: 192.168.2.1, leases: 6

1 Like

Can confirm that - new trunk build works for me too.
Thanks a lot to all who helped finding/resolving the issue :+1:

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.