[BUG] - alfa F/W format issue

[dorner365]

I tried updating a remote RT-AX86U running the last 3004.388.6 alfa version.

I did not capture the errors, but a check for new F/W returned no update available.

I understand that the script handles beta and release firmware. However, a message that upgrade from an alfa version is unsupported would be nice rather than no update available.

There were also some errors when running option 1 that had to do with the unrecognized alfa format.

[ExtremeFiretop]

I tried updating a remote RT-AX86U running the last 3004.388.6 alfa version.

I did not capture the errors, but a check for new F/W returned no update available.

I understand that the script handles beta and release firmware. However, a message that upgrade from an alfa version is unsupported would be nice rather than no update available.

There were also some errors when running option 1 that had to do with the unrecognized alfa format.

Can you provide us your log file? You can find it in the location identified under the advanced options (ad)

[ExtremeFiretop]

I tried updating a remote RT-AX86U running the last 3004.388.6 alfa version.

I did not capture the errors, but a check for new F/W returned no update available.

I understand that the script handles beta and release firmware. However, a message that upgrade from an alfa version is unsupported would be nice rather than no update available.

There were also some errors when running option 1 that had to do with the unrecognized alfa format.

Also can you confirm if the update ended up going through successfully in the same run or did you have to re-initiate the update due to the errors?

[dorner365]

The log as requested:

?@RT-AX86U-M:/tmp/mnt/asus/conf# cat /tmp/mnt/asus/MerlinAU.d/logs/RT-AX86U_FW_Update_2024-02-27_16_32_19.log 2024-02-27 16:32:19 No new firmware version update is found for [RT-AX86U] router model.

That's it.

The previously installed F/W was RT-AX86U_3004_388.6_alpha1-g4889cee45a_pureubi.w.

The script did not find an upgrade; I manually updated to 3004_388.6_2.

[ExtremeFiretop]

The log as requested:

?@RT-AX86U-M:/tmp/mnt/asus/conf# cat /tmp/mnt/asus/MerlinAU.d/logs/RT-AX86U_FW_Update_2024-02-27_16_32_19.log 2024-02-27 16:32:19 No new firmware version update is found for [RT-AX86U] router model.

That's it.

The previously installed F/W was RT-AX86U_3004_388.6_alpha1-g4889cee45a_pureubi.w.

The script did not find an upgrade; I manually updated to 3004_388.6_2.

More than enough for us now I think, thank you for reporting the exact version of the firmware as well!

(I had edited the question, because I realized any alpha would likely have this issue).

The alpha logic was added with the beta logic, it should in theory allow for alpha to production updates the same way as betas, but we only tested with beta to production releases

We will review the alpha logic and see if we can find the issue and report back with a PR if one is identified.

[ExtremeFiretop]

Hey @Martinski4GitHub

I can't seem to re-create this issue even if I set my nvram extendno to the following:

0_alpha1
0_beta1
0_Alpha1
0_Beta1
alpha1
beta1

However I CAN re-create the issue if I set my nvram extendno to the following:

Beta1 or Alpha1

[ExtremeFiretop]

This issue stems from the /usr/sbin/webs_update.sh script and not our script directly. @dorner365 did you ever modify your nvram variables? I think this would likely be something to modify in RMerlins script.

Would be great if the issue could be re-created on your end somehow, to confirm the output of: nvram get extendno

[dorner365]

I can confirm that I did not modify the nvram variables.

However, on a side note, I just realized now that amtm 5.1 did also show the full firmware's version as 3004_388.6_alpha1-g4889cee45a` and the whole row was misaligned.

I mention that because @tlc's change log states: "Returns exact Asuswrt-Merlin firmware version number in header. Except for alpha or test releases where it cuts down the length of the string."

[ExtremeFiretop]

I can confirm that I did not modify the nvram variables.

However, on a side note, I just realized now that amtm 5.1 did also show the full firmware's version as 3004_388.6_alpha1-g4889cee45a` and the whole row was misaligned.

I mention that because @tlc's change log states: "Returns exact Asuswrt-Merlin firmware version number in header. Except for alpha or test releases where it cuts down the length of the string."

If you didn't modify the nvram variables manually, my best guess is that alpha version wasn't following the normal standards for versioning, and so the webs_update.sh script is failing with the error your seeing.

Because our script piggy-backs on the routers built-in update checker, if this script fails, our script will never detect a newer release available. Which is what we see in your logs above, it never even tried to update since it figured no newer updates were found.

That points to the built-in update script failing to parse the version installed correctly.

I don't expect you to downgrade to confirm the issue with this alpha firmware not following standards, but what I can say is that our script can correctly identify and work with betas and alphas, but it seems the built-in update script has issues with some alpha versioning.

I wouldn't expect this to be an issue again, if it is, then it's likely because it's an alpha release and not following the standards for versioning.

Maybe something worth reporting to RMerlin though in case he wasn't aware of this issue with the built in update script being case specific.

[dorner365]

Fair enough.

Thank you

[Martinski4GitHub]

Hey @Martinski4GitHub

I can't seem to re-create this issue even if I set my nvram extendno to the following:

0_alpha1
0_beta1
0_Alpha1
0_Beta1
alpha1
beta1

However I CAN re-create the issue if I set my nvram extendno to the following:

Beta1 or Alpha1

I see where in the "webs_update.sh" script the code looks for "alpha|beta" but not "Alpha|Beta" strings. However, our script can use some tightening up in that area as well. I already have a couple of ideas to make it a bit more robust to different "alpha|beta" string formats. I'll submit a PR later this evening.

[ExtremeFiretop]

Hey @Martinski4GitHub I can't seem to re-create this issue even if I set my nvram extendno to the following:

0_alpha1
0_beta1
0_Alpha1
0_Beta1
alpha1
beta1

However I CAN re-create the issue if I set my nvram extendno to the following: Beta1 or Alpha1

I see where in the "webs_update.sh" script the code looks for "alpha|beta" but not "Alpha|Beta" strings. However, our script can use some tightening up in that area as well. I already have a couple of ideas to make it a bit more robust to different "alpha|beta" string formats. I'll submit a PR later this evening.

Take your time, I myself would of maybe submitted a PR to RMerlin as a friendly suggestion if possible. His argument and viewpoint is already known.

I can guess he may say Betas or at least Alphas, don't follow a standard for versioning. But in that case that's more of a use case to have a the webs_update.sh be more universally adaptable.

[Martinski4GitHub]

I see where in the "webs_update.sh" script the code looks for "alpha|beta" but not "Alpha|Beta" strings. However, our script can use some tightening up in that area as well. I already have a couple of ideas to make it a bit more robust to different "alpha|beta" string formats. I'll submit a PR later this evening.

Take your time, I myself would of maybe submitted a PR to RMerlin as a friendly suggestion if possible. His argument and viewpoint is already known.

I can guess he may say Betas or at least Alphas, don't follow a standard for versioning. But in that case that's more of a use case to have a the webs_update.sh be more universally adaptable.

That's the thing, Alphas & Betas can be wild cards WRT a "standard" format (perhaps Alphas more than Betas).

All we can do is best-effort attempts to catch them. My position is that going from an Alpha to a Master release is not always a safe bet, especially if the Alpha version includes any changes/bugs that can interfere with anything related to the built-in update process or related NVRAM variables. The Beta versions tend to be a bit more stable so it's a safer bet.

In any case, when a user installs a non-master release, they tacitly assume & agree that more things can & may go wrong, including automatic F/W updates, so a manual update to a Master version will be necessary from time to time.

[ExtremeFiretop]

I see where in the "webs_update.sh" script the code looks for "alpha|beta" but not "Alpha|Beta" strings. However, our script can use some tightening up in that area as well. I already have a couple of ideas to make it a bit more robust to different "alpha|beta" string formats. I'll submit a PR later this evening.

Take your time, I myself would of maybe submitted a PR to RMerlin as a friendly suggestion if possible. His argument and viewpoint is already known. I can guess he may say Betas or at least Alphas, don't follow a standard for versioning. But in that case that's more of a use case to have a the webs_update.sh be more universally adaptable.

That's the thing, Alphas & Betas can be wild cards WRT a "standard" format (perhaps Alphas more than Betas).

All we can do is best-effort attempts to catch them. My position is that going from an Alpha to a Master release is not always a safe bet, especially if the Alpha version includes any changes/bugs that can interfere with anything related to the built-in update process or related NVRAM variables. The Beta versions tend to be a bit more stable so it's a safer bet.

In any case, when a user installs a non-master release, they tacitly assume & agree that more things can & may go wrong, including automatic F/W updates, so a manual update to a Master version will be necessary from time to time.

Agreed, we discussed this once before when we added alphas, I mentioned I felt it was a sketchy thing to automate, but you made that point that some users may try (and you were right as found above).

I see really 2 routes to the problem, one is try a better attempt at catching them, second route is just flat out re-assess the support for alphas and let them be handled manually by the user in such cases.

[Martinski4GitHub]

Agreed, we discussed this once before when we added alphas, I mentioned I felt it was a sketchy thing to automate, but you made that point that some users may try (and you were right as found above).

I see really 2 routes to the problem, one is try a better attempt at catching them, second route is just flat out re-assess the support for alphas and let them be handled manually by the user in such cases.

AFAIK, we have never stated that "Alpha-to-Production" updates are supported; only "Beta-to-Production" updates are officially supported because of the toggle option available in the menu. So, AFAIC, that's our current position. OTOH, we can try to at least catch them and try the update on a best-effort basis. If it works, great; if not, then "manual update" it is since we made no promises of support.

[ExtremeFiretop]

Agreed, we discussed this once before when we added alphas, I mentioned I felt it was a sketchy thing to automate, but you made that point that some users may try (and you were right as found above). I see really 2 routes to the problem, one is try a better attempt at catching them, second route is just flat out re-assess the support for alphas and let them be handled manually by the user in such cases.

AFAIK, we have never stated that "Alpha-to-Production" updates are supported; only "Beta-to-Production" updates are officially supported because of the toggle option available in the menu. So, AFAIC, that's our current position. OTOH, we can try to at least catch them and try the update on a best-effort basis. If it works, great; if not, then "manual update" it is since we made no promises of support.

Confirmed.

No where have we publicly stated Alphas are supported. (or even work for that matter) we kinda just sneaked that logic in.

So if you want to hold this stance, I'm all for it. We can try our best to catch them, if they don't, then sorry alphas aren't officially supported. No need to actively block them then unless this becomes a reoccurring annoyance.

[Martinski4GitHub]

AFAIK, we have never stated that "Alpha-to-Production" updates are supported; only "Beta-to-Production" updates are officially supported because of the toggle option available in the menu. So, AFAIC, that's our current position. OTOH, we can try to at least catch them and try the update on a best-effort basis. If it works, great; if not, then "manual update" it is since we made no promises of support.

Confirmed.

No where have we publicly stated Alphas are supported. (or even work for that matter) we kinda just sneaked that logic in.

So if you want to hold this stance, I'm all for it. We can try our best to catch them, if they don't, then sorry alphas aren't officially supported. No need to actively block them then unless this becomes a reoccurring annoyance.

Yes, IMO, that should be our current general position WRT Alphas. The script can still be improved to catch both Betas & Alphas, but only Betas are officially supported for updates to Production versions. If at any point in the future, Alphas become a real problem then, as you said, we could potentially block them like we do for EOL models.

[ExtremeFiretop]

@dorner365

@Martinski4GitHub submitted PR 149 for this : https://github.com/ExtremeFiretop/MerlinAutoUpdate-Router/pull/149

As discussed above, this is our best attempt at catching these, if it doesn't work then unfortunately we can't do much else and it falls outside of our official support moving forwards.

So alphas may work, but the tool doesn't officially support them.