Bug Fixes for Fresh Installs

[ExtremeFiretop]

@Martinski4GitHub

Bug Fixes for fresh installs of 1.4.0

We should probably advise @decoderman to update AMTM to use the new "install" parameter.
In the meantime, I worked around it by manually downloading the .asp file if it's missing.

[Copilot]

Copilot wasn't able to review any files in this pull request.

Files not reviewed (1)

• MerlinAU.sh: Language not supported

[ExtremeFiretop]

Tested to confirm it resolved the mentioned issues.
Merging to dev directly, will request the user test and advise.

[ExtremeFiretop]

There might be something outstanding with the update process as well:

[ExtremeFiretop]

I fixed the update issue with the install parameter.
But still can't figure out the latest report

[Martinski4GitHub]

@Martinski4GitHub

Bug Fixes for fresh installs of 1.4.0

We should probably advise @decoderman to update AMTM to use the new "install" parameter. In the meantime, I worked around it by manually downloading the .asp file if it's missing.

I've already submitted a PR to the AMTM repo on GitHub, so the lonelycoder should be able to see the change request.

[Martinski4GitHub]

Copilot wasn't able to review any files in this pull request.
Files not reviewed (1)

What is this about ????

[Martinski4GitHub]

There might be something outstanding with the update process as well:

The above scenario is most likely the result of installing the development version (1.4.1) of the shell script on top of the production release 1.4.0 version without switching to the development branch by typing:

/jffs/scripts/MelinsAU.sh develop

If the user only replaces the shell script without switching branches, they end up with the version.txt file from the production release branch while running the shell script from the development branch.

[ExtremeFiretop]

@Martinski4GitHub
Bug Fixes for fresh installs of 1.4.0
We should probably advise @decoderman to update AMTM to use the new "install" parameter. In the meantime, I worked around it by manually downloading the .asp file if it's missing.

I've already submitted a PR to the AMTM repo on GitHub, so the lonelycoder should be able to see the change request.

Thank you :)
This should help smooth things over!

[ExtremeFiretop]

Copilot wasn't able to review any files in this pull request.
Files not reviewed (1)

What is this about ????

I noticed Copilot was added to Github as a new reviewer so I tried it... It didn't work xD
If you expand the "files not reviewed" it says Shell is not a supported language.... Useless. Was worth a try!

[ExtremeFiretop]

There might be something outstanding with the update process as well:

The above scenario is most likely the result of installing the development version (1.4.1) of the shell script on top of the production release 1.4.0 version without switching to the development branch by typing:

/jffs/scripts/MelinsAU.sh develop

If the user only replaces the shell script without switching branches, they end up with the version.txt file from the production release branch while running the shell script from the development branch.

To what I could tell; it was never installing the version.txt file when installing the script since we weren't using the "install" parameter. As soon as I added the install parameter lines, the version.txt was populate at install and the issue went away :)

[ExtremeFiretop]

To what I could tell; it was never installing the version.txt file when installing the script since we weren't using the "install" parameter. As soon as I added the install parameter lines, the version.txt was populate at install and the issue went away :)

For example below is a fresh install with the old version of the dev branch before my PRs were merged:

As you can see; it has the reported issues with the Cron job being added, also has the issues with the WebUI trying to be mounted, and detects an update (when one isn't available since I manually incremented the version in the script)

This is the contents of the settings directory after that install:

It is very clearly missing the version.text (as the new source of truth) of the current version installed. (It used to be the source of truth for available updates but I see this changed)

Next if I add the install parameter to the shell script, the issues go away:

And the version.txt file is clearly there for comparison:

[Martinski4GitHub]

Copilot wasn't able to review any files in this pull request.
Files not reviewed (1)

What is this about ????

I noticed Copilot was added to Github as a new reviewer so I tried it... It didn't work xD If you expand the "files not reviewed" it says Shell is not a supported language.... Useless. Was worth a try!

Ah, OK. Got it.

[Martinski4GitHub]

There might be something outstanding with the update process as well:

The above scenario is most likely the result of installing the development version (1.4.1) of the shell script on top of the production release 1.4.0 version without switching to the development branch by typing:

/jffs/scripts/MelinsAU.sh develop

If the user only replaces the shell script without switching branches, they end up with the version.txt file from the production release branch while running the shell script from the development branch.

To what I could tell; it was never installing the version.txt file when installing the script since we weren't using the "install" parameter.

We need to be very clear when describing the installation scenario. That's the key to understanding what happens. For example, how was the shell script installed? You don't specify the method used, so we're left to assume, which can lead to wrong assumptions or misunderstandings.

Was the script installed manually using the curl command on an SSH terminal window?
Was it installed by switching to the 'development' branch first using the 'develop' call parameter?
How are users installing the 1.4.1 develop branch version?
Context is crucial. As you well know, "The devil is in the details."

As soon as I added the install parameter lines, the version.txt was populate at install and the issue went away :)

Yes, because the full installation routine is executed, which downloads the version.txt file as well.

[ExtremeFiretop]

There might be something outstanding with the update process as well:

The above scenario is most likely the result of installing the development version (1.4.1) of the shell script on top of the production release 1.4.0 version without switching to the development branch by typing:

/jffs/scripts/MelinsAU.sh develop

If the user only replaces the shell script without switching branches, they end up with the version.txt file from the production release branch while running the shell script from the development branch.

To what I could tell; it was never installing the version.txt file when installing the script since we weren't using the "install" parameter.

We need to be very clear when describing the installation scenario. That's the key to understanding what happens. For example, how was the shell script installed? You don't specify the method used, so we're left to assume, which can lead to wrong assumptions or misunderstandings.

Was the script installed manually using the curl command on an SSH terminal window? Was it installed by switching to the 'development' branch first using the 'develop' call parameter? How are users installing the 1.4.1 develop branch version? Context is crucial. As you well know, "The devil is in the details."

As soon as I added the install parameter lines, the version.txt was populate at install and the issue went away :)

Yes, because the full installation routine is executed, which downloads the version.txt file as well.

Installed with the curl command from a base of nothing.
Same as AMTM does it now.

When I say I add the install parameter, I meant in the script, and not run as a CLI command.
It can't be installed using the develop command from zero or from a "fresh" install. That would always be an "upgrade" scenario since the script is already there, and not a fresh install as described.

[Martinski4GitHub]

There might be something outstanding with the update process as well:

The above scenario is most likely the result of installing the development version (1.4.1) of the shell script on top of the production release 1.4.0 version without switching to the development branch by typing:

/jffs/scripts/MelinsAU.sh develop

If the user only replaces the shell script without switching branches, they end up with the version.txt file from the production release branch while running the shell script from the development branch.

To what I could tell; it was never installing the version.txt file when installing the script since we weren't using the "install" parameter.

We need to be very clear when describing the installation scenario. That's the key to understanding what happens. For example, how was the shell script installed? You don't specify the method used, so we're left to assume, which can lead to wrong assumptions or misunderstandings.
Was the script installed manually using the curl command on an SSH terminal window? Was it installed by switching to the 'development' branch first using the 'develop' call parameter? How are users installing the 1.4.1 develop branch version? Context is crucial. As you well know, "The devil is in the details."

As soon as I added the install parameter lines, the version.txt was populate at install and the issue went away :)

Yes, because the full installation routine is executed, which downloads the version.txt file as well.

Installed with the curl command from a base of nothing. Same as AMTM does it now.

Well, in that case, the version.txt file is not "installed" as part of the manual download which explains why it was missing.

When I say I add the install parameter, I meant in the script, and not run as a CLI command. It can't be installed using the develop command from zero or from a "fresh" install. That would always be an "upgrade" scenario since the script is already there, and not a fresh install as described.

Installing a 'develop' branch version from scratch is not a valid scenario. The develop version is meant to be installed on top of an existing installation: either a previous develop version, or an existing production master branch version, by switching branches.

When calling a manual curl command, all bets are off.

[ExtremeFiretop]

There might be something outstanding with the update process as well:

The above scenario is most likely the result of installing the development version (1.4.1) of the shell script on top of the production release 1.4.0 version without switching to the development branch by typing:

/jffs/scripts/MelinsAU.sh develop

If the user only replaces the shell script without switching branches, they end up with the version.txt file from the production release branch while running the shell script from the development branch.

To what I could tell; it was never installing the version.txt file when installing the script since we weren't using the "install" parameter.

We need to be very clear when describing the installation scenario. That's the key to understanding what happens. For example, how was the shell script installed? You don't specify the method used, so we're left to assume, which can lead to wrong assumptions or misunderstandings.
Was the script installed manually using the curl command on an SSH terminal window? Was it installed by switching to the 'development' branch first using the 'develop' call parameter? How are users installing the 1.4.1 develop branch version? Context is crucial. As you well know, "The devil is in the details."

As soon as I added the install parameter lines, the version.txt was populate at install and the issue went away :)

Yes, because the full installation routine is executed, which downloads the version.txt file as well.

Installed with the curl command from a base of nothing. Same as AMTM does it now.

Well, in that case, the version.txt file is not "installed" as part of the manual download which explains why it was missing.

Exactly. As i touched on below:

To what I could tell; it was never installing the version.txt file when installing the script since we weren't using the "install" parameter. As soon as I added the install parameter lines, the version.txt was populate at install and the issue went away :)

Sounds like we went full circle and both in understanding. But that's why I said that it was likely not related to installing dev on top of production without issuing the develop command as you initially expected. It was always done as a clean slate and explained my findings. Happy we both are in agreement on the cause.

When I say I add the install parameter, I meant in the script, and not run as a CLI command. It can't be installed using the develop command from zero or from a "fresh" install. That would always be an "upgrade" scenario since the script is already there, and not a fresh install as described.

Installing a 'develop' branch version from scratch is not a valid scenario. The develop version is meant to be installed on top of an existing installation: either a previous develop version, or an existing production master branch version, by switching branches.

When calling a manual curl command, all bets are of.

It should be a valid scenario considering that's often how we test though. There is at the end of the day, no difference between production and dev other than a single tag in the code, and calling the curl manually is equivalent how AMTM was doing to install, which does make it a valid test scenario to test the missing install parameters in this case.

[Martinski4GitHub]

There might be something outstanding with the update process as well:

The above scenario is most likely the result of installing the development version (1.4.1) of the shell script on top of the production release 1.4.0 version without switching to the development branch by typing:

/jffs/scripts/MelinsAU.sh develop

If the user only replaces the shell script without switching branches, they end up with the version.txt file from the production release branch while running the shell script from the development branch.

To what I could tell; it was never installing the version.txt file when installing the script since we weren't using the "install" parameter.

We need to be very clear when describing the installation scenario. That's the key to understanding what happens. For example, how was the shell script installed? You don't specify the method used, so we're left to assume, which can lead to wrong assumptions or misunderstandings.
Was the script installed manually using the curl command on an SSH terminal window? Was it installed by switching to the 'development' branch first using the 'develop' call parameter? How are users installing the 1.4.1 develop branch version? Context is crucial. As you well know, "The devil is in the details."

As soon as I added the install parameter lines, the version.txt was populate at install and the issue went away :)

Yes, because the full installation routine is executed, which downloads the version.txt file as well.

Installed with the curl command from a base of nothing. Same as AMTM does it now.

Well, in that case, the version.txt file is not "installed" as part of the manual download which explains why it was missing.

Exactly. As i touched on below:

To what I could tell; it was never installing the version.txt file when installing the script since we weren't using the "install" parameter. As soon as I added the install parameter lines, the version.txt was populate at install and the issue went away :)

Sounds like we went full circle and both in understanding. But that's why I said that it was likely not related to installing dev on top of production without issuing the develop command as you initially expected. It was always done as a clean slate and explained my findings. Happy we both are in agreement on the cause.

When I say I add the install parameter, I meant in the script, and not run as a CLI command. It can't be installed using the develop command from zero or from a "fresh" install. That would always be an "upgrade" scenario since the script is already there, and not a fresh install as described.

Installing a 'develop' branch version from scratch is not a valid scenario. The develop version is meant to be installed on top of an existing installation: either a previous develop version, or an existing production master branch version, by switching branches.
When calling a manual curl command, all bets are of.

It should be a valid scenario considering that's often how we test though. There is at the end of the day, no difference between production and dev other than a single tag in the code, and calling the curl manually is equivalent how AMTM was doing to install, which does make it a valid test scenario to test the missing install parameters in this case.

We're the developers so we have inside knowledge of how things work and how they are supposed to work. But the scenario is not valid for regular users, especially now, where other pieces must be installed (ASP, version.txt file) in addition to the shell script, so they may see some "weird" behavior that would not be present if a true "installation" is performed.

[ExtremeFiretop]

There might be something outstanding with the update process as well:

The above scenario is most likely the result of installing the development version (1.4.1) of the shell script on top of the production release 1.4.0 version without switching to the development branch by typing:

/jffs/scripts/MelinsAU.sh develop

If the user only replaces the shell script without switching branches, they end up with the version.txt file from the production release branch while running the shell script from the development branch.

To what I could tell; it was never installing the version.txt file when installing the script since we weren't using the "install" parameter.

We need to be very clear when describing the installation scenario. That's the key to understanding what happens. For example, how was the shell script installed? You don't specify the method used, so we're left to assume, which can lead to wrong assumptions or misunderstandings.
Was the script installed manually using the curl command on an SSH terminal window? Was it installed by switching to the 'development' branch first using the 'develop' call parameter? How are users installing the 1.4.1 develop branch version? Context is crucial. As you well know, "The devil is in the details."

As soon as I added the install parameter lines, the version.txt was populate at install and the issue went away :)

Yes, because the full installation routine is executed, which downloads the version.txt file as well.

Installed with the curl command from a base of nothing. Same as AMTM does it now.

Well, in that case, the version.txt file is not "installed" as part of the manual download which explains why it was missing.

Exactly. As i touched on below:

To what I could tell; it was never installing the version.txt file when installing the script since we weren't using the "install" parameter. As soon as I added the install parameter lines, the version.txt was populate at install and the issue went away :)

Sounds like we went full circle and both in understanding. But that's why I said that it was likely not related to installing dev on top of production without issuing the develop command as you initially expected. It was always done as a clean slate and explained my findings. Happy we both are in agreement on the cause.

When I say I add the install parameter, I meant in the script, and not run as a CLI command. It can't be installed using the develop command from zero or from a "fresh" install. That would always be an "upgrade" scenario since the script is already there, and not a fresh install as described.

Installing a 'develop' branch version from scratch is not a valid scenario. The develop version is meant to be installed on top of an existing installation: either a previous develop version, or an existing production master branch version, by switching branches.
When calling a manual curl command, all bets are of.

It should be a valid scenario considering that's often how we test though. There is at the end of the day, no difference between production and dev other than a single tag in the code, and calling the curl manually is equivalent how AMTM was doing to install, which does make it a valid test scenario to test the missing install parameters in this case.

We're the developers so we have inside knowledge of how things work and how they are supposed to work. But the scenario is not valid for regular users, especially now, where other pieces must be installed (ASP, version.txt file) in addition to the shell script, so they may see some "weird" behavior that would not be present if a true "installation" is performed.

Yes fair point.

I was originally thinking / talking in the dev mentality when I was having the user test and also when running my tests in comparison, but I can see why you would say it's not a valid scenario usually.

It's a good reason why we don't provide the curl commands to do updates like many other add-ons might.

[Martinski4GitHub]

There might be something outstanding with the update process as well:

The above scenario is most likely the result of installing the development version (1.4.1) of the shell script on top of the production release 1.4.0 version without switching to the development branch by typing:

/jffs/scripts/MelinsAU.sh develop

If the user only replaces the shell script without switching branches, they end up with the version.txt file from the production release branch while running the shell script from the development branch.

To what I could tell; it was never installing the version.txt file when installing the script since we weren't using the "install" parameter.

We need to be very clear when describing the installation scenario. That's the key to understanding what happens. For example, how was the shell script installed? You don't specify the method used, so we're left to assume, which can lead to wrong assumptions or misunderstandings.
Was the script installed manually using the curl command on an SSH terminal window? Was it installed by switching to the 'development' branch first using the 'develop' call parameter? How are users installing the 1.4.1 develop branch version? Context is crucial. As you well know, "The devil is in the details."

As soon as I added the install parameter lines, the version.txt was populate at install and the issue went away :)

Yes, because the full installation routine is executed, which downloads the version.txt file as well.

Installed with the curl command from a base of nothing. Same as AMTM does it now.

Well, in that case, the version.txt file is not "installed" as part of the manual download which explains why it was missing.

Exactly. As i touched on below:

To what I could tell; it was never installing the version.txt file when installing the script since we weren't using the "install" parameter. As soon as I added the install parameter lines, the version.txt was populate at install and the issue went away :)

Sounds like we went full circle and both in understanding. But that's why I said that it was likely not related to installing dev on top of production without issuing the develop command as you initially expected. It was always done as a clean slate and explained my findings. Happy we both are in agreement on the cause.

When I say I add the install parameter, I meant in the script, and not run as a CLI command. It can't be installed using the develop command from zero or from a "fresh" install. That would always be an "upgrade" scenario since the script is already there, and not a fresh install as described.

Installing a 'develop' branch version from scratch is not a valid scenario. The develop version is meant to be installed on top of an existing installation: either a previous develop version, or an existing production master branch version, by switching branches.
When calling a manual curl command, all bets are of.

It should be a valid scenario considering that's often how we test though. There is at the end of the day, no difference between production and dev other than a single tag in the code, and calling the curl manually is equivalent how AMTM was doing to install, which does make it a valid test scenario to test the missing install parameters in this case.

We're the developers so we have inside knowledge of how things work and how they are supposed to work. But the scenario is not valid for regular users, especially now, where other pieces must be installed (ASP, version.txt file) in addition to the shell script, so they may see some "weird" behavior that would not be present if a true "installation" is performed.

Yes fair point.

I was originally thinking / talking in the dev mentality when I was having the user test and also when running my tests in comparison, but I can see why you would say it's not a valid scenario usually.

It's a good reason why we don't provide the curl commands to do updates like many other add-ons might.

That's correct. If I can help it, I always prefer to avoid asking regular users to call the raw curl command to install the add-on from scratch, especially starting with the 1.4.0 release, and especially with non-techy users, or non-Linux users.

[ExtremeFiretop]

@Martinski4GitHub

We should issue a 1.4.1 release considering this would impact any new installs until AMTM is updated. I would say it's fairly important. I'm willing to prep a PR now

[Martinski4GitHub]

@Martinski4GitHub

We should issue a 1.4.1 release considering this would impact any new installs until AMTM is updated. I would say it's fairly important. I'm willing to prep a PR now

Fully agreed. I tested a fresh install on another router that I have access to, and it worked well. The "install" parameter call is made automatically by the script when the WebGUI is not found mounted and the ASP file is not found installed. The key was also doing a full initialization of the configuration file and some specific user settings.

[Martinski4GitHub]

@ExtremeFiretop,

BTW, have you had a chance to test the latest script on your AiMesh node?
I don't have one of those, so I can validate that scenario.

[ExtremeFiretop]

@ExtremeFiretop,

BTW, have you had a chance to test the latest script on your AiMesh node? I don't have one of those, so I can validate that scenario.

I just finished testing and by just running the curl command to test the latest dev version on my AiMesh node I get the following:

The configuration file is being populated:

But the version.txt is missing.