Sd boot img? (can no longer boot)

Hi, where do I find an img to try to boot from sd? I get a 404 on
Suddenly I can no longer boot. Oled works. Turning on also starts keyb backlight but screen remains blank thereafter - I’d like to try to boot from sd

The repo for the system images is here:

Reform / reform-system-image · GitLab

Unfortunately the link in the README ( is not working at the moment so you’ll need to look for an image in in the “Build” / “Artifacts”:

Artifacts · Reform / reform-system-image · GitLab

Find the latest successful build, selected it and go to “Browse” the “Job artifacts” on the right side menu. At this moment you’ll end up at:

Artifacts · build (#4529) · Jobs · Reform / reform-system-image · GitLab

Good luck!

1 Like

Did you recently do an “apt upgrade”? This might be this issue:

We diagnosed that problem today on IRC:

1 Like

Really sorry for these issues. I overhauled the URL now so that an index.html with a redirect to the latest successful job artifacts is created every 5 minutes. This should get rid of any outdated links.


Hi all - pocket back to working state - thx for support.
To doc for other newbies like myself:

  • on other computer: download image from Artifacts · build (#4529) · Jobs · Reform / reform-system-image · GitLab
  • gzip -d pocket-reform-system-imx8mp.img.gz
  • lsblk to find your sdcard
  • sudo dd if=pocket-reform-system-imx8mp.img of=/dev/sdX bs=8M status=progress (change SdX to what you found in previous step
  • boot from this sdcard on your pocket - go through setup
  • mount boot partition from emmc (use lsblk to find)
  • copy vmlinuz from boot on sdcard to boot on emmc
  • (I didn’t need to copy any other libs)
  • reboot without sdcard should work again

Thank you, these instructions are correct. If you are using Debian, you can apt install bmap-tools and replace this:

With this:

  • bmaptool copy /dev/sdX

The advantages of using bmaptool instead of wget, gzip, dd are:

  • only one command instead of multiple
  • no need to download the image to the local disk first
  • no need to unpack it manually before flashing
  • automatically prevents you from writing the image to a disk that is in use, thus reducing the chances to break your installation
  • only copies the blocks that actually contain data, thus you only need to actually copy 3.2 GB instead of the full 4.5 GB

The issue is also present in the Debian linux kernel currently in experimental. It is tracked here:

So the Reform community just happened to notice this bug before everyone else did.

Thanks to the Reform community, a bug in binutils which results in a non-functional kernel image on arm64 was found and a workaround is now present in the Debian kernel itself:

Here is the binutils bug for anybody who is interested in the gory details:
Thanks to the users who reported this, the problem was found early and was only limited to Debian experimental. I reported the issue the same day that the Debian linux upload to unstable was scheduled, which (if it had happened) would’ve broken quite a few more systems.