ImageBuilder; Cannot upgrade OS running on eMMC

When using ImageBuilder, might there be a way of creating an extra partition that would never get overwritten by re-flashing the device with a new image?

I'm trying to find a way to keep a persistent MAC address on devices that I have which are remote to me yet need updates now and then.

I would use the partition to keep a MAC address on it (in a file) that on bootup, the device would read and use that MAC address.

UPDATE: The problem of using static MAC is easy to solve but now I cannot write a new image to the nanopi R5C openwrt running on eMMC.

That is nothing the imagebuilder would offer you (easily).

1 Like

Sounds like the original behaviour, where the original unique hardware MAC is stored in the OEM-written serialnumber/MAC/wifipassword/wificalibrationdata partition, from which OpenWrt reads it at boot.

If you are risk-taking, you might even consider reading, modifying and re-writing that partition (with a firmware with a modified DTS that enables writing to that normally read-only mtd partition).

Otherwise, if the new MAC is stored in OpenWrt uci config, it should be preserved if you sysupgrade with settings kept.

But none of that can be done with imagebuilder, which just glues together already-compiled standard items.

1 Like

Add the MACs to a rc.local script, setting them during every boot?

1 Like

I was messing around with setting the MAC using rc.local etc but the problem is, I'd have to keep track of which devices have which MAC when writing a new fw to them.
The only way I can think of that would be permanent is to use sd card or partition.

I've been told there is no way to poke around using openwrt itself to discover what the original factory MAC would have been, is that true?
If that's not true, then that would be the best option, find the original and write that to the network file after firmware update.

Isn't the original MAC picked up correctly, or are you overriding it ?

No, that is not true for most of the "normal" router devices.

You can usually see that MAC in a mtdblock and also in devicetree.
The MAC is stored on the flash also by the OEM...

E.g. for E8450 / RT3200

root@router4:~# hexdump  -C /dev/mtd2 | tail -n 6
00005e00  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0007fff0  ff ff ff ff c4 41 1e f8  a5 1f c4 41 1e f8 a5 1e  |.....A.....A....|
00080000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

Original wan port MAC for my device is c4 41 1e f8 a5 1e at 7fffa and MAC for LAN is c4 41 1e f8 a5 1f at 7fff4

And visible in device-tree:

root@router4:~# hexdump -C  /proc/device-tree/ethernet@1b100000/mac@0/mac-address
00000000  c4 41 1e f8 a5 1f                                 |.A....|

That was one of the first things, trying to look at mtd

cat /proc/mtd
dev:    size   erasesize  name

# ls -la /proc/device-tree/ethernet@fe010000/
drwxr-xr-x    6 root     root             0 Feb 11 19:19 .
drwxr-xr-x  155 root     root             0 Feb 11 18:51 ..
-r--r--r--    1 root     root            87 Feb 11 19:21 clock-names
-r--r--r--    1 root     root            64 Feb 11 19:21 clocks
-r--r--r--    1 root     root            38 Feb 11 19:21 compatible
-r--r--r--    1 root     root            20 Feb 11 19:21 interrupt-names
-r--r--r--    1 root     root            24 Feb 11 19:21 interrupts
drwxr-xr-x    2 root     root             0 Feb 11 19:21 mdio
-r--r--r--    1 root     root             9 Feb 11 19:21 name
-r--r--r--    1 root     root            16 Feb 11 19:21 reg
-r--r--r--    1 root     root            10 Feb 11 19:21 reset-names
-r--r--r--    1 root     root             8 Feb 11 19:21 resets
-r--r--r--    1 root     root             4 Feb 11 19:21 rockchip,grf
drwxr-xr-x    3 root     root             0 Feb 11 19:21 rx-queues-config
-r--r--r--    1 root     root             4 Feb 11 19:21 snps,axi-config
-r--r--r--    1 root     root             0 Feb 11 19:21 snps,mixed-burst
-r--r--r--    1 root     root             4 Feb 11 19:21 snps,mtl-rx-config
-r--r--r--    1 root     root             4 Feb 11 19:21 snps,mtl-tx-config
-r--r--r--    1 root     root             0 Feb 11 19:21 snps,tso
-r--r--r--    1 root     root             9 Feb 11 19:21 status
drwxr-xr-x    2 root     root             0 Feb 11 19:21 stmmac-axi-config
drwxr-xr-x    3 root     root             0 Feb 11 19:21 tx-queues-config

Maybe I have to load something on boot?

What device is this ?

NanoPi 5rc router.
From what I'm reading, there is no point in using hexdump after the router is up and running because that's only showing runtime info.

I need to find a way to get deeper into the hardware but from the openwrt command line so I could dig that MAC's out and set those in the network file and do this automatically if I re-flash the device.

Who's great idea is it to constantly change MAC? Is this the future? What a mess it causes.

Does that have a permanent flash at all, or is it just memory card based?

With memory cards, things are naturally different, as the device itself has no permanent storage, so there is no original MAC stored anywhere.

Some devices can be bought without "unique" MAC, it's probably cheaper, since they only have to pay the NIC vendor once, instead of every time they sell a new device.


Apparently the Mac is generated by OpenWrt by hashing a a device ID or something like that.

The behavior of constantly changing MAC devices is extremely frustrating.
I use the MAC to identify all devices on my networks but this one keeps changing, repeatedly even once the router is up and running.

I decided to hard code MAC addresses into the network file but now I found a new problem. I re-built my firmware using ImageBuilder which I transfer to /tmp. Openwrt is running on the eMMC now, not an sd card.

However, as mentioned in another post, I just found another weird thing about this router or something I'm not aware of.

When running sysupgrade -n myfile.bin.gz, the console implies that it's doing the upgrade but when I log back into the router, it's the same as it was. In fact, even on reboots, the things I left in /tmp are still there.

I'm wondering if perhaps it's not possible to upgrade the firmware using sysupgrade when the OS is on eMMC.

# sysupgrade -n ID58-nanopi-r5c-2024-02-13.bin.gz
Tue Feb 13 22:55:45 UTC 2024 upgrade: Reading partition table from bootdisk...
Tue Feb 13 22:55:45 UTC 2024 upgrade: Reading partition table from image...
Tue Feb 13 22:55:45 UTC 2024 upgrade: Commencing upgrade. Closing all shell sessions.
Command failed: Connection failed

What's interesting is the router has a 32GB eMMC but it looks like only 8G of it was used when I originally flashed it. Maybe that's why sysupgrade is failing, not enough space?

Disk /dev/mmcblk1: 28.91 GiB, 31037849600 bytes, 60620800 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: dos
Disk identifier: 0x5452574f

Device         Boot  Start    End Sectors  Size Id Type
/dev/mmcblk1p1 *     65536  98303   32768   16M 83 Linux
/dev/mmcblk1p2      131072 344063  212992  104M 83 Linux

# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 7.5M      7.5M         0 100% /rom
tmpfs                   995.6M     13.9M    981.6M   1% /tmp
/dev/loop0               84.4M      1.0M     76.7M   1% /overlay
overlayfs:/overlay       84.4M      1.0M     76.7M   1% /
tmpfs                   512.0K         0    512.0K   0% /dev

In terms of the MAC, It seems these routers are sold as regular and enterprise. Regular have dynamic MAC while enterprise ones have static MAC.

Because of this, I suspect there will be no original MAC to be found on the hardware.

Is there a way to specify the size of the storage when building an image?
I'm guessing not.

I flashed a FriendlyWrt eflesher onto an sd card then used that to auto flash the eMMC with friendlyWrt.

What's interesting is the default partitioning that I now see.

root@FriendlyWrt:~# fdisk -l /dev/mmcblk2
Disk /dev/mmcblk2: 28.91 GiB, 31037849600 bytes, 60620800 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: 73987B6B-4974-4C94-A3E8-58AB2EB7A946

Device           Start      End  Sectors  Size Type
/dev/mmcblk2p1   16384    24575     8192    4M unknown
/dev/mmcblk2p2   24576    32767     8192    4M unknown
/dev/mmcblk2p3   32768    40959     8192    4M unknown
/dev/mmcblk2p4   40960    73727    32768   16M unknown
/dev/mmcblk2p5   73728   155647    81920   40M unknown
/dev/mmcblk2p6  155648   221183    65536   32M unknown
/dev/mmcblk2p7  221184   286719    65536   32M unknown
/dev/mmcblk2p8  286720  1466367  1179648  576M unknown
/dev/mmcblk2p9 1466368 60620766 59154399 28.2G unknown

root@FriendlyWrt:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           512K     0  512K   0% /dev
tmpfs           196M  152K  196M   1% /run
overlay          28G  744K   27G   1% /
tmpfs           982M   21M  961M   3% /tmp

If I were to use sysupgrade to flash my own image, assuming it would work, would it end up being installed on partition9?
And if it were, would that mean I would end up with partition9 becoming a couple of partitions and openwrt would not see any more storage than 8GB again? I don't know how it picked 8GB but the only thing I can think of is that perhaps the original sd card I used was an 8GB one?

I really don't know, I'm just guessing at this point and no idea how to move forward.

There is, if you use your own image builder, not the online one.

As for the MAC issue, is there a boot loader, like u-boot, where you could set a MAC address variable, then pick it up in OpenWRT ?
This would survive upgrades.

Yes, I can set the MAC addresses but what I was after was finding the factory ones so they would be truly unique and not my own. Now I know these devices do not come with a fixed MAC so it's unlikely there is any info in the hardware.

My real problem at this point is not being able to use the full eMMC which is likely why I cannot upgrade the OS using sysupgrade.

I've yet to find information on how I can fix this. I was wondering if maybe I need to boot from sd card, wipe the partition from the eMMC, then run eflasher to flash back to eMMC then upgrade. Maybe at that point, I get more space or it's the eflasher that's partitioning the eMMC as it is and it means I need to put my own openwrt image for eflasher to flash.

Bit confusing all this.

The MAC issue is solved;

Is there a bug in the ImageBuilder?
I just found this out. I'm using files/ to store my own custom settings etc and I've noticed that when I build, a new file I put there gets removed if I run make clean and make dirclean before building a profile.

I don't recall any files in files/ being removed when running those commands first and I've used IB hundreds of times.