No space left on device when trying to manually downgrade from 3.11.2.5 on RM1

[tproulund]

Hallo

I tried to follow #95 (comment) to downgrade from 3.11.2.5 to 3.3.2.1666 to install Toltec - I am on a RM1

I am on linux and downloaded and extracted with codexctl

./codexctl download --hardware rm1 3.3.2.1666
./codexctl extract --out 3.3.2.1666.img 3.3.2.1666_reMarkable-Ak1sdSSGWD-.signed 

Mount shows

/dev/mmcblk1p2 on / type ext4 (rw,relatime)

but when I do the dd command, I get the error there is no space left with 1 byte difference

root@reMarkable:~# dd if=/home/root/3.3.2.1666.img of=/dev/mmcblk2p3
dd: error writing '/dev/mmcblk2p3': No space left on device
214337+0 records in
214336+0 records out

I was only able to find this mentioned one other place, which was related to wrong hardware, but this is not my case unless i missed something obvious

thanks in advance

[Eeems]

How did you download the update file, this would lead me to believe that it's the rM2 update file and not the rM2 one, as the instructions in the linked comment are for downloading a rM2 update file.

[tproulund]

I used the download feature of codexctl with the argument --hardware rm1 but I also tried to manually download the file from https://archive.org/download/rm110/RM110/ with same issue

is this "manual" process applicable for rm1 or did i miss something

oh also, i used latest release of codexctl

[Eeems]

Yes it's applicable to the rM1.

What does sha256sum 3.3.2.1666.img 3.3.2.1666_reMarkable-Ak1sdSSGWD-.signed return for you?

I would expect the following results:

280051a3177d87bf27b415adba8afeaf9af6381dd3e9ed2b77a879886c9c31a2  3.3.2.1666.img
9f1ed453241901ecbbae9bc62a567b5cea1df10cc69d9be38ebb1e56a88f8d68  3.3.2.1666_reMarkable-Ak1sdSSGWD-.signed

[tproulund]

it looks to be identical

280051a3177d87bf27b415adba8afeaf9af6381dd3e9ed2b77a879886c9c31a2  3.3.2.1666.img
9f1ed453241901ecbbae9bc62a567b5cea1df10cc69d9be38ebb1e56a88f8d68  3.3.2.1666_reMarkable-Ak1sdSSGWD-.signed

[Eeems]

What does fdisk -l (run on your reMarkable) output for you?

[tproulund]

here you go

root@reMarkable:~# fdisk -l
Disk /dev/mmcblk1: 7457 MB, 7820083200 bytes, 15273600 sectors
238650 cylinders, 4 heads, 16 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device       Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/mmcblk1p1 *  0,1,1       610,3,16            16      39103      39088 19.0M 83 Linux
/dev/mmcblk1p2    611,0,1     1023,3,16        39104     527423     488320  238M 83 Linux
/dev/mmcblk1p3    1023,3,16   1023,3,16       527424    1015743     488320  238M 83 Linux
/dev/mmcblk1p4    1023,3,16   1023,3,16      1015744   15273599   14257856 6961M  5 Extended
/dev/mmcblk1p5    1023,3,16   1023,3,16      1015760    1054847      39088 19.0M 83 Linux
/dev/mmcblk1p6    1023,3,16   1023,3,16      1054864    1093951      39088 19.0M 83 Linux
/dev/mmcblk1p7    1023,3,16   1023,3,16      1093968   15273599   14179632 6923M 83 Linux
root@reMarkable:~# 

[Eeems]

The two root partition sizes do seem to match up with the size of the image file I have, which you indicated matches the file you have. To confirm, when you ran sha256sum did you run it against the file on your reMarkable, or against the file on your computer?

[tproulund]

edit: sorry missing formatting

That was from my file on my computer

here is from the remarkable:

root@reMarkable:~# sha256sum 3.3.2.1666.img 
280051a3177d87bf27b415adba8afeaf9af6381dd3e9ed2b77a879886c9c31a2  3.3.2.1666.img

[Eeems]

Okay, so the file you have on your device does match what is expected as well. I'll have to do some checking on my rM1 when I'm home and able to use it later tonight.

As an aside, when wrapping multi-line code blocks, instead of using a single ` character, please use three, I've been updating your comments so they are formatted properly.

[tproulund]

alright no problem and thanks for the quick responses !

haha and thanks for the formatting, I havent (luckily maybe) done much bug report on gitlab ! :)

[Eeems]

My fdisk output matches yours, both of which are what I expect.

Upon reviewing the size of the image file, it's smaller than the partition we are writing to. Upon attempting to dd it, it's working with no issue.

When I looked closer at your issue, I see you are trying to write to /dev/mmcblk2p3, but you are on a rM1, so you should writing to /dev/mmcblk1p3 instead.

[tproulund]

omg thank you ! such a silly mistake upon closer review

I corrected now and then everything worked and I was able to complete the restore part and get down to 3.3.2

thanks for the help !!