Restore not swiotching to fallback partition

[Eeems]

Hello, I am trying to downgrade my RM2 from 3.20.0.92 $\rightarrow$ 3.3.2.1666 so that I can use toltec. I seem to be getting an error in using codexctl, and upon rebooting nothing has changed. Any ideas what is going on?

My steps:

1. downloaded firmware version 3.3.2.1666 onto my macbook. This produced a file 3.3.2.1666_reMarkable2-ihUirIf133-.signed
2. extracted 3.3.2.1666_reMarkable2-ihUirIf133-.signed to produce 3.3.2.1666.img
3. transfered the image 3.3.2.1666.img to RM2
4. output from mount on RM2:

from which I determine that mmcblk2p2 is my fallback partition. 5. now I run: dd if=/home/root/3.3.2.1666.img of=/dev/mmcblk2p2, which had the following out:

6. restore from my macbook installation of codexctl

7. Rebooted anyways - nothing has changed.

Originally posted by @alexliebmanp in #95

[Eeems]

@alexliebmanp You don't appear to be running the latest version of codexctl, could you try again with the latest version?

[plant-hedgerows]

Hello,

I downgraded a rm2 from 3.20.0.92 -> 3.3.2.1666.

I was not able to use the linux build as I am on debian 12 and it uses an older glibc version (36 instead of 38).

pip3 didn't install the pypi package because I have python 3.11 and it requires python >=3.12.

So I couldn't test the binary release or pypi package.

I downloaded the source code, created a venv, installed the dependencies and ran python3 main.py to follow the steps described above. This worked like a charm with python 3.11.

Just wanted to let y'all know in case someone has a similar problem.

[flomlo]

Another (temporary) quickhack: If you look at what the command restore does, you end up in https://github.com/Jayy001/codexctl/blob/5bb8bd431c8c8ba1719b8074b873a5b18317b5b6/codexctl/device.py#L423 to line 439, which pretty explicitly tells you what code to write into a e.g. restore.sh, push onto your remarkable, then execute.

That did the job for me, whereas running the version of codexctl distributed by pypi did not (similar/same error as above)

@Eeems side note: wouldn't it be easier to check which partition is currently used and which one is the backup by running /sbin/fw_printenv instead of using mount? I would also propose using fw_printenv to automate this manual procedure as (fixing https://github.com/Jayy001/codexctl/blob/5bb8bd431c8c8ba1719b8074b873a5b18317b5b6/codexctl/init.py#L266).

If you gimme a thumbs up I'll get to it.

[Eeems]

That only tells you what it's currently set to boot next, not what is actually mounted.

There should be no need for working around this though, as it should be fixed in codexctl. If this is not the case please let us know.

[flomlo]

root@reMarkable:~# /sbin/fw_printenv -n active_partition
3
root@reMarkable:~# /sbin/fw_printenv -n fallback_partition
2

Seems to do fine for me. As I said, I think I can write that code to replace the manual update procedure, but I don't wanna impose.

Won't be ready till in 2 weeks though (have to defend my Thesis first)

[flomlo]

Ah sorry and regarding the workaround of creating a restore.sh: I confirm that with pypi-version of codexctl downloaded yesterday ago it would still break (like with alexliebmanp).

Haven't tried current github version, was easier for me to just use above workaround.

[Eeems]

root@reMarkable:~# /sbin/fw_printenv -n active_partition
3
root@reMarkable:~# /sbin/fw_printenv -n fallback_partition
2

Seems to do fine for me. As I said, I think I can write that code to replace the manual update procedure, but I don't wanna impose.

Won't be ready till in 2 weeks though (have to defend my Thesis first)

As these are just variables, and can be changed at runtime, they do not tell you what is actually active, only what is set for the next boot. Which is why we use mount, it will always tell you what is actually in use, and avoid any issues where someone has run something else to try to switch partitions but not rebooted yet.

Ah sorry and regarding the workaround of creating a restore.sh: I confirm that with pypi-version of codexctl downloaded yesterday ago it would still break (like with alexliebmanp).

Haven't tried current github version, was easier for me to just use above workaround.

Could you try using the latest compiled version or directly from source, which are the two listed installation methods: https://github.com/Jayy001/codexctl?tab=readme-ov-file#installation

pypi doesn't get updated automatically.

@Jayy001 we should automate updating pypi so that this doesn't happen since people are using it.

[flomlo]

@Eeems ah, now I get why you use mount. Yes indeed that seems like the safer method then. Thanks for explaining :)

I'll try it from source in a couple of days, I should really finish my PhD-thesis right now :|