ipq807x: change 3 devices to use the standard eMMC sysupgrade code

[Lanchon]

Settings were lost because target-specific mmc_do_upgrade does not align backup data to 64 KiB boundaries.

This changes the device to use the generic emmc_do_upgrade and emmc_copy_config.

---

i don't have this device, but it seems all devices using mmc_do_upgrade should be affected.

@pwned-pixel did the testing and reportedly this change fixes sysupgrade: settings are preserved while random files in the overlay (files not explicitly backed up) are deleted.

---

@dangowrt @robimarko

thank you!

[Lanchon]

after this change only two ipq807x devices remain with the supposedly faulty mmc_do_upgrade:

• prpl haze
• qnap 301w

i could move them to emmc_do_upgrade / emmc_copy_config but i can't test them.

[robimarko]

Qnap 301W is not broken, I have it and it preserves settings just fine.

That being said, If it can be moved to a generic sysupgrade EMMC function instead of the custom one I am all for it (Though I am not a fan of F2FS)

[Lanchon]

@robimarko

Qnap 301W is not broken

ok. but how is it not broken? AFAICT, fstools creates the loop device rounding up the start address to 64 KiB, and mmc_do_upgrade does not:

openwrt/target/linux/qualcommax/ipq807x/base-files/lib/upgrade/mmc.sh

Lines 53 to 59 in 38bb47c

	# a padded rootfs is needed for overlay fs creation
	local offset=$(tar xf $tar_file ${board_dir}/root -O | wc -c)
	[ $offset -lt 65536 ] && {
	echo Wrong size for rootfs: $offset
	sleep 10
	reboot -f
	}

so unless the rootfs itself is somehow padded to 64 KiB for this device, i don't understand how this could be working.

[Lanchon]

(Though I am not a fan of F2FS)

me neither, but the powers that be have chosen F2FS for overlay.

(i don't think that replacing the generic emmc upgrade code with a custom one for each device is a rational way of dealing with this.)

btw, here is a PR related to this: openwrt/fstools#9

[Lanchon]

@robimarko

Qnap 301W is not broken, I have it and it preserves settings just fine.

after looking into it a bit more, i'm willing to bet you are wrong.

the device has a rootfs_data partition:

  9     0x00322022      0x0073d821      "rootfs_data"
        attrs:  0x0000000000000000
        type:   ab1760da-a8bb-4d6f-98d2-9ad3ab9009cd
        guid:   d1402149-3e8e-0709-99d9-170bfab2f66c

but mmc_do_upgrade does not support that. instead it writes to rootfs loop, in the wrong location, but it doesn't matter because openwrt mounts rootfs_data anyway after boot. this is the same issue the spectrum had.

so these are symptoms of sysupgrade failing:

• write a random file in /, sysupgrade, and verify that the file DIDN'T go away
• sysupgrade wiping settings, and verify that settings are conserved

this happens because rootfs_data isn't touched at all during sysupgrade.

[Lanchon]

@robimarko

given that i understood why sysupgrade appeared to work until now, i added a commit here fixing the problem.

since you own the device, please verify that there is a discreet rootfs_data data partition and that sysupgrade was not touching it before this change.

thanks!

[Lanchon]

ok, and i pushed a commit for the haze, the last device using mmc.sh, given there is evidence that this last one does not use a discreet rootfs_data: ba415af

so mmc.sh is still broken but now it's unused, AFAICT.

i want to delete it but i don't know who is referencing it at runtime!

EDIT:

oh well i suppose the .sh files are sourced with a glob. i nuked the file in the last commit.

[kirdesde]

I already wrote in #16452 (comment) that sysupgrade + preserving config is working fine (at least for 301w and the nbg7815)

The only thing that might not work is sysupgrade and not preserving config since mmc_do_flash is always calling cp backup config.

openwrt/target/linux/qualcommax/ipq807x/base-files/lib/upgrade/mmc.sh

Line 74 in 676a2ab

cp -v "$UPGRADE_BACKUP" "/tmp/new_root/$BACKUP_FILE"

BTW IMHO your change for the prpl,haze would break the sysupgrade since this device doesn't have a mmc rootfs_data partition and therefore needs the roofs_data loop.

[Lanchon]

@kirdesde

I already wrote in #16452 (comment) that sysupgrade + preserving config is working fine (at least for 301w and the nbg7815)

The only thing that might not work is sysupgrade and not preserving config since mmc_do_flash is always calling cp backup config.

openwrt/target/linux/qualcommax/ipq807x/base-files/lib/upgrade/mmc.sh

Line 74 in 676a2ab

cp -v "$UPGRADE_BACKUP" "/tmp/new_root/$BACKUP_FILE"

i already wrote a detailed reply to your comment here, which you seem to have completely ignored. in it i explain how sysupgrade is supposed to work.

i also explained why "sysupgrade + preserving config is working fine" is not proof that sysupgrade is working. in the case of 301w and nbg7815, sysupgrade is not even touching rootfs_data, which is a big bug: config is "preserved", but not in the correct way.

also, "The only thing that might not work" is very probably not the only thing not working. again, see my reply for more info.

BTW IMHO your change for the prpl,haze would break the sysupgrade since this device doesn't have a mmc rootfs_data partition and therefore needs the roofs_data loop.

with all due respect, you don't seem to undertand how sysupgrade works. no, you do not need a loop device during sysugrade. you do need it after booting though, which is the responsibility of fstools to create.

and note that any loop device you might create during sysupgrade will cease to exist on reboot, as loop devices exist in kernel ram and are not persistent.

again, refer to my previous reply to you, especially the section mentioning the WHW03 v1.

---

EDIT:

@kirdesde i noticed that i didn't specifically mentioned you in my previous reply to you.

sorry if that caused you to miss the reply.

[Lanchon]

@dangowrt was that an intention to merge?

[sppmasterspp]

@dangowrt was that an intention to merge?

I have 301w.
Can I help with anything resolving this?

[Lanchon]

@sppmasterspp

I have 301w.
Can I help with anything resolving this?

thank you! yes, please.

you can confirm that the current 301w sysupgrade code does not work by running these tests with the current official openwrt firmware:

1. create any random file in the root / directory of the router, then do a sysupgrade preserving settings. next check if the the random file you created still exists or is gone:

   • if the file still exists, sysupgrade is broken.

2. make some config changes, then do a sysupgrade resetting settings. next check if router settings were actually reset:

   • if settings were not reset, sysupgrade is broken.

thanks again.

[sppmasterspp]

you can confirm that the current 301w sysupgrade code does not work by running these tests with the current official openwrt firmware:

1. create any random file in the root / directory of the router, then do a sysupgrade preserving settings. next check if the the random file you created still exists or is gone:

   • if the file still exists, sysupgrade is broken.

For now I've been able to test only the first one because I had a newly compiled build form 2 hours ago.
A big notice here is that I use NSS build (not officially supported by OpenWrt upstream). My build is based on @qosmio NSS-wifi branch (that is up to date with OpenWrt upstream + NSS support commits on top of it).
I created a file PR16505 in root / with content 301w but after sysupgrade preserving the settings the file was gone after reboot.
I have made several resets/restores of the settings back in time and never noticed anything wrong with it.
Currently I don't have a possibility to test with official OpenWrt but thanks a lot for your work.
Anything else I can do? Or you need a test only with official OpenWrt?

[Lanchon]

@sppmasterspp

please only test running official openwrt both before and after the test.

forks are not supported.

[Lanchon]

@robimarko

i haven't heard back from you regarding:
#16505 (comment)

qnap 301W sysupgrade in the current official builds is very probably broken and should be tested like this:
#16505 (comment)

there is a commit here to fix it.

thanks!

[ynezz]

test on prpl,haze

1. I did flashed in U-Boot latest sysupgrade image r27934-ff18576f84
2. I've set uci set system.@system[0].hostname='OpenWrtuned' ; uci commit system to see, that the config can be preserved after boot
3. I've added cookie echo foo > /bar
4. I did sysupgrade https://downloads.openwrt.org/snapshots/targets/qualcommax/ipq807x/openwrt-qualcommax-ipq807x-prpl_haze-squashfs-sysupgrade.bin

root@OpenWrtuned:~# ubus call system board
{
        "kernel": "6.6.58",
        "hostname": "OpenWrtuned",
        "system": "ARMv8 Processor rev 4",
        "model": "prpl Foundation Haze",
        "board_name": "prpl,haze",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "SNAPSHOT",
                "description": "OpenWrt SNAPSHOT",
                "revision": "r27934-ff18576f84",
                "target": "qualcommax/ipq807x",
                "builddate": "1730108090"
        }
}

write a random file in /, sysupgrade, and verify that the file DIDN'T go away

The /bar cookie went away ✅ This is expected behavior as its not defined in /lib/upgrade/keep.d ?

sysupgrade wiping settings, and verify that settings are conserved

5. sysupgrade -n https://downloads.openwrt.org/snapshots/target s/qualcommax/ipq807x/openwrt-qualcommax-ipq807x-prpl_haze-squashfs-sysupgrade.bin

root@OpenWrt:~# ubus call system board
{
        "kernel": "6.6.58",
        "hostname": "OpenWrt",
        "system": "ARMv8 Processor rev 4",
        "model": "prpl Foundation Haze",
        "board_name": "prpl,haze",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "SNAPSHOT",
                "description": "OpenWrt SNAPSHOT",
                "revision": "r27934-ff18576f84",
                "target": "qualcommax/ipq807x",
                "builddate": "1730108090"
        }
}

sysupgrade wiped settings ✅

[Lanchon]

@ynezz

test on prpl,haze

thanks! unfortunately these tests were intended for qnap 301w, which uses a discrete rootfs_data partition for the overlay. these tests never applied to haze.

haze is different and uses the trailing part of rootfs for the overlay. on haze the expectation was that sysupgrade would possibly always clear settings even if you wanted to keep them, because the update code does not align the loop device to 64KB boundaries. however your test shows that settings are kept. i suspect this means that rootfs is generated in such a way that causes it to always be a multiple of 64KB in size? idk

whatever the reason, even if it worked, this is brittle. and haze should be migrated to the standard way of doing things anyway, which this commit does, even if it is currently working. my point is that i'm pretty sure qnap 301w does not work, and the others need to be migrated to the standard code even if they work. @robimarko has a qnap 301w but unfortunately he hasn't tested it.

EDIT:

spectrum sax1v1k was in exactly the same boat as qnap 301w, and sure as hell did not work before 3b221ba; i tested it on my sax1v1k.

[ynezz]

I miss description/reasoning about this change in the commit. If its unrelated, move it into separate commit with proper description.

[Lanchon]

description/reasoning: mkf2fs, f2fsck are part of metapackage f2fs-tools. f2fs-tools will be extended/adapted as f2fs devels see fit, instead of stagnating in the past. including the metapackage is the standard practice on other devices in openwrt, AFAICT.

If its unrelated, move it into separate commit with proper description

i fixed the device i own. i don't have this device, i just wanted to help when i identified issues in other devices. you are more than welcome to take over these changes if you favor particular styles. in any case, thanks for the comment.

[ynezz]

This should go into separate commit as well.

[Lanchon]

this change was lumped in this commit because it was the last device using this non-standard code, assuming the previous 2 commits were merged.

[ynezz]

whatever the reason, even if it worked, this is brittle. and haze should be migrated to the standard way of doing things anyway

I agree and I actually like it, but I'm only able to test this on Haze, but if it works, I'm going to merge only Haze relevant commits, unless you're willing to split this into Haze only pull request. I'm not going to merge the other bits as I don't want to cause any regressions as I wont be able to handle them in timely manner.

[Lanchon]

@ynezz

i thought these 3 commits would be an easy merge, especially after 3b221ba was merged. i was wrong.

please go ahead and do your fix for Haze. one device fixed is better than none.

thanks for the help!

[Lanchon]

@ynezz

a bit of history:

this PR was about the first commit only, affecting only nbg7815, as you can see in the original PR message. later i saw that there were 2 other similar devices with issues and added commits 2 and 3.

but nbg7815 was already tested and the issue confirmed when i created the fix and this PR (again see OP, it details who tested).

so you can definitely merge the first commit, and with your own fix to Haze, only qnap 301w would remain broken.

[sppmasterspp]

@sppmasterspp

I have 301w.
Can I help with anything resolving this?

thank you! yes, please.

you can confirm that the current 301w sysupgrade code does not work by running these tests with the current official openwrt firmware:

1. create any random file in the root `/` directory of the router, then do a sysupgrade **preserving** settings. next check if the the random file you created still exists or is gone:
   
   * if the file still exists, sysupgrade is broken.

2. make some config changes, then do a sysupgrade **resetting** settings. next check if router settings were actually reset:
   
   * if settings were not reset, sysupgrade is broken.

thanks again.

@robimarko is probably very busy.
Tests on QNAP 301w.
Previously I've tested this with my custom forked NSS build. With it none of the two (point 1 and 2) can be observed.
I've just tested all of this with latest official Vanilla OpenWrt build.
First I flashed the official OpenWrt twice not keeping the settings with reboots of course.
Then I created a file in root / with content 301w.
Next I followed point 1 - I did a sysupgrade keeping the settings - after reboot the file I created in root / wasn't there.
Point 2 - I made changes to some settings and saved them. I rebooted manually and checked that the settings were preserved - they were preserved.
I did a sysupgrade with resetting the setting. After reboot all the settings were reset to default.
I don't know if all of this helps. I may try another tests if necessary.

[Lanchon]

@sppmasterspp

I don't know if all of this helps.

it helps a lot, thank you for testing. i was wrong!

i don't have the 301w, and when researching it, i came across what i now think might have been false info. as stated here, i was under the assumption that the 301w had a discrete rootfs_data partition. i don't know exactly where i got that snippet of a supposed dump of the 301w partition table, most likely the 301w forum.

now i doubt that that info is true. if the 301w had a rootfs_data, it would be failing in the same way as the spectrum sax1v1k did before i fixed it. your tests clearly show sysupgrade works, and make me think there is no discreet rootfs_data.

i sincerely apologize for the mistake.

under the new assumption, 301w would still benefit from a change to the new way of doing things. but my proposed commit is wrong and will break sysupgrade if merged.

@sppmasterspp could you please install package gdisk and use it to print the partition table of your device? you could do this on any build you want. this would confirm that GPT snippet i found earlier was red hearing, and i could at least provide a equivalent change for what @ynezz is requesting for haze here (along with haze).

[sppmasterspp]

@sppmasterspp could you please install package gdisk and use it to print the partition table of your device? you could do this on any build you want. this would confirm that GPT snippet i found earlier was red hearing, and i could at least provide a equivalent change for what @ynezz is requesting for haze here (along with haze).

Is this info enough?

root@QNAP:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00050000 00010000 "0:sbl1"
mtd1: 00010000 00010000 "0:mibib"
mtd2: 00180000 00010000 "0:qsee"
mtd3: 00010000 00010000 "0:devcfg"
mtd4: 00010000 00010000 "0:apdp"
mtd5: 00040000 00010000 "0:rpm"
mtd6: 00010000 00010000 "0:cdt"
mtd7: 00020000 00010000 "0:appsblenv"
mtd8: 00100000 00010000 "0:appsbl"
mtd9: 00040000 00010000 "0:art"
mtd10: 00080000 00010000 "0:ethphyfw1"
mtd11: 00080000 00010000 "0:ethphyfw2"
mtd12: 00350000 00010000 "reserved"
root@QNAP:~# gdisk /dev/mmcblk0
GPT fdisk (gdisk) version 1.0.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/mmcblk0: 7634944 sectors, 3.6 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxx
Partition table holds up to 12 entries
Main partition table begins at sector 2 and ends at sector 4
First usable sector is 34, last usable sector is 7634910
Partitions will be aligned on 2-sector boundaries
Total free space is 42941 sectors (21.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34           32801   16.0 MiB    FFFF  0:HLOS
   2           32802           65569   16.0 MiB    FFFF  0:HLOS_1
   3           65570           98337   16.0 MiB    FFFF  0:HLOS_2
   4           98338         1146913   512.0 MiB   FFFF  rootfs
   5         1146914         2195489   512.0 MiB   FFFF  rootfs_1
   6         2195490         3244065   512.0 MiB   FFFF  rootfs_2
   7         3244066         3252257   4.0 MiB     FFFF  0:WIFIFW
   8         3252258         3285025   16.0 MiB    8301  reserved
   9         3285026         7591969   2.1 GiB     FFFF  rootfs_data

Command (? for help):q

I've added this info to the QNAP 301w wiki.
https://openwrt.org/toh/qnap/301w#flash_layout_emmc
I don't know what partition 9 is reserved for. Reserved for something specific?
There is a question for all the devices that have eMMC flash memory about those reserved partitions if this 2.1GiB can be used for anything useful at all anytime.

[robimarko]

Thanks! Rebased on top of main and merged!

[robimarko]

Thanks for digging in and fixing these issues

[Lanchon]

thank you!!

[sppmasterspp]

if you want to back up the partition as a binary image, and the partition is mostly empty: mount it, run fstrim -v /path/to/device/mount/point/ to wipe unused space, unmount it, gzip -c /dev/<emmc-dev>p9 > /tmp/p9.img.gz to back it up, and then use scp to pull the image backup to your PC.

or you can just backup the files in an archive, which should be enough: tar --acls --xattrs --selinux -cpvzf /tmp/p9.tgz /path/to/device/mount/point. options --acls --xattrs and --selinux may be too much for busybox tar, you can leave them out then. or if you want an uncompressed backup (faster) you can use: tar --acls --xattrs --selinux -cpvf /tmp/p9.tar /path/to/device/mount/point.

@Lanchon Can you give here for reference the commands to restore the original files from the archives to partition 9 using gzip and tar.

[Lanchon]

@Lanchon Can you give here for reference the commands to restore the original files from the archives to partition 9 using gzip and tar.

gzip -dc /tmp/p9.img.gz > /dev/<emmc-dev>p9 should work.

or else gzip -dc /tmp/p9.img.gz | dd of=/dev/<emmc-dev>p9

but before you must make sure that partition p9 is unmounted!!! use mount to check, umount to unmount.

---

restoring the tar backup requires formatting and mounting partition p9 beforehand. as backups go, it is less useful. but it allows easier access to the file contents from the backup file, if ever needed. the tar backup, strictly speaking, is redundant.