OpenWrt Support for Armor G5 (NBG7815)

The firstboot command does not look happy:

root@OpenWrt:/etc# firstboot -y
/dev/loop0 is mounted as /overlay, only erasing files

I managed to install fdisk, below is is the reported partition scheme. At least the space is there :slight_smile:

root@OpenWrt:/etc/opkg# fdisk /dev/mmcblk0

Welcome to fdisk (util-linux 2.39).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

This disk is currently in use - repartitioning is probably a bad idea.
It's recommended to umount all file systems, and swapoff all swap
partitions on this disk.

Command (m for help): p

Disk /dev/mmcblk0: 3.53 GiB, 3791650816 bytes, 7405568 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 98101B32-BBE2-4BF2-A06E-2BB33D000C20

Device            Start     End Sectors  Size Type
/dev/mmcblk0p1       34   16417   16384    8M unknown
/dev/mmcblk0p2    16418   18465    2048    1M unknown
/dev/mmcblk0p3    18466   30753   12288    6M unknown
/dev/mmcblk0p4    30754  153633  122880   60M unknown
/dev/mmcblk0p5   153634  161825    8192    4M unknown
/dev/mmcblk0p6   161826  163873    2048    1M unknown
/dev/mmcblk0p7   163874  176161   12288    6M unknown
/dev/mmcblk0p8   176162  299041  122880   60M unknown
/dev/mmcblk0p9   299042  307233    8192    4M unknown
/dev/mmcblk0p10  307234 1355809 1048576  512M unknown
/dev/mmcblk0p11 1355810 7122977 5767168  2.8G unknown

I can mount correctly partitions 1 (ext4 containing just two dirs, upper and work with something that looks like a linux directory structure), 10 (empty ext4 filesystem) and 11 (ext4, I suppose it's the /tmp/ApplicationData of the official firmware), the others throw Invalid argument.

/etc/fstab does not contain any mountpoint.

That looks like you did the process a 2nd time and this is wrong and does produce errors like this. You have installed OpenWrt already. The commands are not there.

What you could do is to load the sysupgrade file to /tmp and execute sysupgrade from command line like:

sysupgrade -v /path/to/filename

To see if it works flawlessly.

That is correct. This is due to how OpenWrt is built.

1 Like

Correct, but the output was exactly the same when I first run the script from the official firmware.
Same for sysupgrade command: I've just run it and had exactly the same result, a factory openwrt install without using vendor emmc partitions.

I tried to go back to the original firmware with the to repeat the install procedure, but I got this:

root@OpenWrt:/tmp# ./
OpenWrt release
1+0 records in
1+0 records out
1+0 records in
1+0 records out
Could not open mtd device: /dev/mtd2
Can't open device for writing!
Could not open mtd device: /dev/mtd3
Can't open device for writing!

It looks like these commands are failing:

  mtd write boot.bin /dev/mtd2
  mtd write boot.bin /dev/mtd3

I tried rebooting but it went back to openwrt, which makes sense since it was not able to write the boot partition.

What if I force a reset procedure via the hardware button?

If you did an sysupgrade already then you cannot go back with this method because sysupgrade is writing the other boot partition. This works only if you've flashed exactly once. This is missleading in the wiki.

Serial access is the only way I know atm to get OEM firmware back to your device.

Reset Button resets the installed system to its defaults. It does not reset to another firmware.

Ok then, I suppose the only way out I have - besides going serial - is fixing the overlay mount point.

Is it ok if I do it via extroot or there are cleaner ways?

EDIT: tried extroot method but it does not like it, it keeps falling back to loop0 :frowning:

root@OpenWrt:~# block info; uci show fstab; logread | sed -n -e "/- preinit -/,/- init -/p"
/dev/loop0: UUID="6b98b264-5fb9-42fa-ba2f-a0083007bc08" LABEL="rootfs_data" VERSION="1.0" MOUNT="/overlay" TYPE="ext4"
/dev/mmcblk0p1: UUID="6219f2d2-f042-420a-90be-f02b039de9fc" VERSION="1.0" TYPE="ext4"
/dev/mmcblk0p10: UUID="43fbd48b-10fb-4368-aa21-1310186c72ad" VERSION="1.0" TYPE="ext4"
/dev/mmcblk0p11: UUID="417be33b-a0e7-4bb4-939e-0d54c315e5c6" LABEL="extroot" VERSION="1.0" TYPE="ext4"
/dev/mmcblk0p4: UUID="94956bf8-c7b04361-f144155c-ebee7d4e" VERSION="4.0" TYPE="squashfs"
/dev/mmcblk0p5: UUID="c16c0598-b9ca654e-958daa12-10dff7a6" VERSION="4.0" TYPE="squashfs"
/dev/mmcblk0p8: UUID="94956bf8-c7b04361-f144155c-ebee7d4e" VERSION="4.0" MOUNT="/rom" TYPE="squashfs"
/dev/mmcblk0p9: UUID="d3a1b394-b47d964f-c45497fd-89ea35eb" VERSION="4.0" TYPE="squashfs"
Mon May 29 01:34:53 2023 kernel: [ 4.275203] init: - preinit -
Mon May 29 01:34:53 2023 kern.notice kernel: [ 4.449009] random: jshn: uninitialized urandom read (4 bytes read)
Mon May 29 01:34:53 2023 kern.notice kernel: [ 4.468144] random: jshn: uninitialized urandom read (4 bytes read)
Mon May 29 01:34:53 2023 kern.notice kernel: [ 4.475445] random: jshn: uninitialized urandom read (4 bytes read)
Mon May 29 01:34:53 2023 kernel: [ 6.570477] loop0: detected capacity change from 0 to 122880
Mon May 29 01:34:53 2023 kernel: [ 6.648250] loop0: detected capacity change from 122880 to 108928
Mon May 29 01:34:53 2023 kern.notice kernel: [ 6.648612] random: procd: uninitialized urandom read (4 bytes read)
Mon May 29 01:34:53 2023 kernel: [ 6.687914] EXT4-fs (loop0): recovery complete
Mon May 29 01:34:53 2023 kernel: [ 6.690004] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null). Quota mode: disabled.
Mon May 29 01:34:53 2023 kernel: [ 6.692411] mount_root: loading kmods from internal overlay
Mon May 29 01:34:53 2023 kernel: [ 6.708489] kmodloader: loading kernel modules from /tmp/overlay/upper/etc/modules-boot.d/*
Mon May 29 01:34:53 2023 kernel: [ 6.709222] kmodloader: done loading kernel modules from /tmp/overlay/upper/etc/modules-boot.d/*
Mon May 29 01:34:53 2023 kernel: [ 7.700787] block: attempting to load /etc/config/fstab
Mon May 29 01:34:53 2023 user.err kernel: [ 7.701756] block: unable to load configuration (fstab: Entry not found)
Mon May 29 01:34:53 2023 user.err kernel: [ 7.704829] block: no usable configuration
Mon May 29 01:34:53 2023 kernel: [ 7.712411] mount_root: switching to ext4 overlay
Mon May 29 01:34:53 2023 kern.warn kernel: [ 7.717899] overlayfs: null uuid detected in lower fs '/', falling back to xino=off,index=off,nfs_export=off.
Mon May 29 01:34:53 2023 user.warn kernel: [ 7.722876] urandom-seed: Seeding with /etc/urandom.seed
Mon May 29 01:34:53 2023 kernel: [ 7.750919] procd: - early -
Mon May 29 01:34:53 2023 kernel: [ 7.750999] procd: - watchdog -
Mon May 29 01:34:53 2023 kern.notice kernel: [ 8.068250] random: crng init done
Mon May 29 01:34:53 2023 kern.notice kernel: [ 8.068289] random: 2 urandom warning(s) missed due to ratelimiting
Mon May 29 01:34:53 2023 kernel: [ 8.289323] procd: - watchdog -
Mon May 29 01:34:53 2023 kernel: [ 8.289692] procd: - ubus -
Mon May 29 01:34:53 2023 kernel: [ 8.344601] procd: - init -

There's a daemon.err block: /dev/loop0 is already mounted on /overlay in logread

I just noticed that loop0 is backed by /mmcblk0p8

root@OpenWrt:~# cat /sys/class/block/loop0/loop/backing_file

I am missing which process is forcing the overlay to loop0, and/or how to change it redirecting to mmcblk0p11.

Full logread here.

That's correct, because OpenWrt is written as an image to the "partition" and then mounted as a loop device. The error about "already mounted" is not popping up on my device. But I would not weigh it heavy (it could just be a process trying it again). The log itself looks fine to me. The mtd partitions and its boundaries are all found and the same as on my device.

The output from "df -h" is telling the overlay is mounted and has free space. fdisk is looking good as well. firstboot command output is correct also. It is deleting files as it is mounted.

What do you want achive exactly now? If you are able to install fdisk the overlay should be O.K. and OpenWrt is running fine.

If you want to go back to OEM firmware then there is one option only. Serial access.
If you did an mtd/nand backup before flashing you could try to write it back to its partitions. But writing to mtd is risky because it is not bothering with faulty flash cells. Nanddump would be able to do this but it is not included within standard OpenWrt images. I don't have a backup from boot and root. I just saved the essentials like art.

Maybe another one have it and could provide it to you uploading it.

Maybe I'm looking at it in the wrong way, but my problem here is that I wasn't expecting an overlay partition of 60MB while there are two usable partitions of about 512MB and a 3GB... I basically would like to move the overlay to one of them.

I don't want to go back to the stock firmware, that was just an option to try a reinstall, expecting a different mount scheme.

Could you share your df -h output?

Rootfs is there 2 times (mmcblk0p4 and p8). Boot/Kernel 2 times (p3 and p7) also. That is dual boot.
The Application/Data partition is not used by OpenWrt itself to keep the layout for a possible revert to OEM firmware. That is a decission made by OpenWrt.

While I do not need extroot or the extra space I think you can use it as extroot. But that is out of scope here. I would recommend to follow the wiki and adopt it accordingly and if you have problems open a new thread and ask specific questions. You have propably a wider audience then here.

root@NBG7815:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                36.0M     36.0M         0 100% /rom
tmpfs                   434.3M      6.4M    427.9M   1% /tmp
/dev/loop0               21.1M    716.0K     18.7M   4% /overlay
overlayfs:/overlay       21.1M    716.0K     18.7M   4% /
tmpfs                   512.0K         0    512.0K   0% /dev

My bad then, I always misunderstood the correct configuration...

I'll let you know if I manage to find a way to make extroot working: I already followed the wiki instruction but there's probably a bug in block that needs a patch.

Yes, this makes sense here and it could explain the issues with block-mount and wifi as well. Maybe I'll give it a try and integrate this patch in my next build to see what happens.

There was an effort to use the fan as thermal device:

What i have to do? how to install Luci?

got it. next step?
I want to install openwrt in order to directly connect the wan port to the provider ont

@asvio may I use your repo as a base ? I noticed that the mac-address-ascii from @pwned patch was already merged together with fan and led control, I'd like to try to build my own image patching it with the mentioned block patch above to allow emmc extroot.

Anything to look out for? A build .config to share?

You mean a stable build instead of a snapshot release (see here: As far as I understand you have to wait until 23.XX is released.

Of course you can. It's there in case anyone wants to use it. mac-address-ascii patch is on main branch. I've not make any change about it.
EDIT: nbg7815-nss repo it's not ready to use. It's better to wait until i find a way to make wifi stable and a better comunication between client.
It's a known problem of nss version.

Hey @pwned
As i said in the previous post., mac- address modification was there, so if no one has the mac address change behavor it's must be my config what it is introducing it. I have tried also with master branch. No way for me. Next will be reset to default.

Sorry I didn't realize that. Is there a non-nss repo with all the additional patches? I noticed that the not all the ones committed in your repo are easily exportable to be integrated directly in a openwrt packages environment

All nbg7815 branches of my openwrt repository include led and fan support from @itorK and @avalentin, main branch is a original openwrt clone.
You can look to the last commits to see what extras its have.

Thanks, I didn't notice the branches inside the openwrt repo.