Tablet won't talk to fake server after downgrade #7
Comments
|
after switch.sh you have to reboot also when you set the server ip, did you remove the # from the line? |
Well that was embarrassing because no I just assumed the default update.conf parameters were being used so I didn't even spot the # Have corrected that now and RM2 is finally talking to the host server. However I am getting an error Looks like I'm having an HTTPS/SSL issue? Here are the full logs: RM2 Host server |
|
you should set the url to: http:// |
|
Thanks, that did the trick. I understand it shouldn't be necessary, but it would probably a good idea to make it clearer that one needs to remove the I think I'm going to give up on this though because even though all the logs confirmed the update to 2.5.1.47 took place as expected and the device was Going back to the Software update menu, the 2.8 version was offered, so I proceeded with that before making a new attempt with the downgrade. The modified update.conf and hosts files had been recovered to their stock version so I had to modify them again (taking care with the # and http), but strangely the RM2 is still quering https://remarkable-staging.auto-up.date/service/update2 instead of my host server. I double checked the host is reachable and that update.conf on the RM2 is modified as required. If that doesn't make the RM2 look for my server then I wonder what would. |
|
the switch.sh is just for changing parition, and is to be used separately (just to go to the other version) you are on the beta channel and i suppose there is a different config or line for the update server |
So do you see any reason why the device didn't reboot into the downgraded firmware even though both server and device reported it had been successfully performed?
I never enrolled for the beta releases. In fact I was never offered this release until after I rebooted following the 'successful' downgrade. Is it possible that the process allowed the device to query remarkable servers for beta releases even though it hadn't been configured to do so? Even now that I'm on 2.8.0.86, I can still press the button "Read more and enroll" and accept the user agreement, which I assume would no longer offer me to enroll had I already done that in the past. Besides, the update.conf file still follows the exact same structure as the last stable 2.7, like so: So yeah I don't really see why it still queries the official repo when looking for an update. |
|
The address being queried is I still can't figure how did the remarkable suddenly decide to query the beta server right after I had 'successfully' downgraded and rebooted, thus allowing me to perform the beta update and now locking me out of using the fake server. |
|
try uncommenting the REMARKABLE_RELEASE_APPID |
|
Thank you, though that didn't seem to change anything. I noticed that when turning the update engine on, whether from the terminal or the UI, it seems to already know about the latest beta release and the URL to get it from, as well as the payload size and hash. Does it mean I have to trick it into forgetting about this information it seems to have memorised? |
|
I have this same issue, more or less (though I have an RM1). I was on 2.7.0.51 and wanted to downgrade to 2.5.1.47. In my case, the downgrade was successful. But I forgot to immediately shut off automatic updates, and without realizing it, it auto-updated to 2.8.0.86 right after I booted into 2.5.1.47. It prompted for a reboot, and when I did, it was back and running 2.8.0.86. I successfully used switch.sh to go back to 2.5.1.47, and that works fine. But the fallback partition still contains 2.8.0.86. I tried updating (using I don't want to clutter this issue if mine turns out to be subtly different, but I hope it's helpful to have a second case where I also have the same result as @jebediah2 where the update engine already seems to know about the latest release--that does seem to be a possible source of this issue. |
|
I noticed all the information displayed when turning the update engine on is contained in I also naively tried redirecting |
|
Posting my experiments to get out of this deadlock. When editing The 2.2.0.57 update process is later denied after failing to verify the payload using the public key at I did this after enrolling then de-enrolling from the beta, hoping it would no longer query the beta server, but that has yet to change. EDIT: Turns out, if you delete both public keys at |
|
I tried deleting the public keys (there was a third copy in / for me) and setting to version 1.0.0.0. But it still grabbed the 2.8.0.86 version and went ahead with the update. I looked at I think that was similar behavior to what you were seeing: as soon as "Starting Update Engine..." appears in the logs, it immediately prints out the URL with the 2.8.0.86 update. Incidentally, that did not happen after I deleted the public keys--but only that once. After another update, the public keys are still gone, but it again prints out the URL to the 2.8.0.86 version as soon as the update engine starts, before it ever queries the remarkable-staging.auto-up.date server. I also wondered whether 2.5.1.47 is a beta release? That was just a 2.5.x version I found by changing the URLs on the Remarkable update server. It seems like 2.5.1.45 was more widely deployed (e.g., it has a ddvk-hacks patch available while 2.5.1.47 does not). I wonder if |
|
I solved my problem the old-fashioned way: by wiping everything and starting fresh. I used ddvk's uuuflash tool (https://github.com/ddvk/remarkable-uuuflash) to wipe the device and put 2.1.1.3 back on both partitions. It's quick--just get the tablet into recovery mode and then After reflashing, I used My best guess continues to be that there's something weird about 2.5.1.47, so perhaps it should be avoided. (I found some people complaining about problems with the updater in 2.5.1.45, so perhaps .47 changed something about the updater.) |
|
I'm really glad you could get your case sorted. I never realised there was a way to flash the remarkable, but that's because I'm looking at things with a RM2 filter, where all the tools haven't been developed yet. Putting the RM2 into recovery mode requires hardware (and Linux) and I'm not seeing the uuuflash tool as confirmed for the RM2 so I'll have to stay away for now. I thought all this weird behaviour was coming from using the fake server more than from 2.5.1.47 itself, but you might be right. I now have 2 beta partitions, one on 2.8.0.86 and one on 2.2.0.57. I would expect 2.2 to query the right server but it still hangs on to the beta server, but it's hard to believe 2.5.1.47 left some persistent change to update-engine. But what do I know. More weirdness, neither of my partitions offer updates anymore. I was expecting 2.2 to offer 2.8, but it doesn't and merely tells me I'm up to date. Thinking I'll just live with 2.2 for now, I re-installed Toltec on that partition and it instantly bricked the tablet. I later managed to re-apply the 2.2 update and not going to try to install much until I find a fix to move on to a newer, stable release. Firmware URLs always use the same format and someone compiled a good deal of them in a reddit post. When I try to get 2.5.1.45 (for RM1 or RM2) it doesn't seem available. Maybe 2.5.1.47 was beta and that's why it wants to use the beta server just like those 2.2 and 2.8. That's how I thought of enrolling and de-enrolling from the beta (though no button for that on 2.2) Maybe comparing the update-engine binaries and other related files between 2.5.0.27 and 2.5.1.47 could tell us. My only thought currently is to use the host file to redirect remarkable-staging.auto-up.date to the fake server. This usually leads to a no response error, but it might be different if I manage to perform what you suggested earlier by editing |
jebediah2
changed the title
|
With help from @danschrage, I finally found the problem, and the fix. Both very simple. It was probably correct to speculate that the 2.5.1.47 update was the problem. Whether it's really the case, downgrading to that version will make changes to So all you have to do is edit Once you've prepared all this, the fake server can be run normally and perform the downgrade as expected. I was coming from 2.8.0.86. Once done and rebooted, xochitl.conf was unchanged this time, so it's probably a good idea to revert the SERVER setting to remarkable's genuine, stable release server: @ddvk I suggest you mention this fix in the readme in case people get stuck with querying the beta server after updating to a bad version. Also, as mentionned in the beginning, it would probably a good idea to make it clearer that one needs to remove the |
|
ah, good catch |
Running the hack from a Mac's Terminal on a RM2 with the latest firmware 2.7.1.53, but all it does is it keeps saying I'm up to date. I think I've done all the steps as required but there seems to be no desired effect when running
update_engine_client -check_for_updateor pressing the "Check for updates" box in the UI.SERVER=http://my-host-name:8000and also tried with my IPSERVER=http://my.ip.address:8000python3 serve.pywith and without changing line 46 tohost = "my.ip.address"Output:
Device should use: http://my.ip.address:8000/orDevice should use: http://my-host-name:8000/on the first lineupdate_engine_client -check_for_updateOutput:
I20210607 12:31:08.343346 384 update_engine_client.cc:271] Initiating update check and install.So all looks like the RM2 is talking to the legit remarkable's server and reports that the installed version is the latest.
Looking at the logs:
Out of curiosity I tried running switch.sh on the RM2 and I get this:
Is there something I'm missing or is it just not going to work with this specific downgrade?
The text was updated successfully, but these errors were encountered: