MNT Reform System Image V3 Beta

I think the artifacts expire after a time, so I’d say unless @mntmn has any reservations, that’s the newest image.

Thank you so much for updating the system image and making maintenance easier in the long-term!

I’d be happy to test the changes in daily usage. Just wondering, is there an easy way to upgrade for anyone having installed the system on nvme already? i.e. is there any way around having to turn the switch on the SoM and booting from the SD first?

Are the updates also available in the debian repository? I would just need to switch to the new kernel but that’s fine.

1 Like

I installed the V3 system image. It still has some packages that apt cannot upgrade. After installing xfce4, I no longer get the login prompt. I can bring up the login by pressing MNT+F1 and after logging in, everything works fine. I installed xfce4 on the V2 system image and did not have this issue.

These were the steps I took to install the new system image. I am running without SD card, using NVMe for the system and eMMC for the boot loader and kernel.

Wrote the new system image to SD card

sudo su
dd if=reform-system.img of=/dev/mmcblk1

Wrote the rescue system image to the eMMC

echo 0 > /sys/class/block/mmcblk0boot0/force_ro
dd if=reform-rescue-system.img of=/dev/mmcblk0

Rebooted to rescue system and reformatted NVMe

# Format only if your data is backed up or on a separate partition
mkfs.ext4 -v -L SSD /dev/nvme0n1p1

Mounted NVMe and SD card

mount /dev/nvme0n1p1 /mnt/
mkdir /sdcard
mount /dev/mmcblk1p1 /sdcard/

Copied SD card to NVMe

# Trailing slash on source /sdcard/ is required
rsync -axHAWXS --numeric-ids --info=progress2 /sdcard/ /mnt/

Set NVMe as boot device and rebooted

echo nvme > /reform-boot-medium

I noticed that job #583 has no warnings, unlike the ones at the bottom of the build logs for #639 and #642. To the casual observer, it’s unclear how severe they are or if it would adversely affect the integrity of the build. It may be good practice to either mark successful/releasable builds such as #583 for permanent retention/archival before they expire or to deploy them as formal releases.

After a couple of days, I figured out how to get the latest v3 commit compiling and working with my eMMC+encrypted NVMe setup. In short:

  • Replaced all “mmcblk1” with “mmcblk0” in, and added “init=/usr/sbin/reform-init rdinit=/usr/bin/reform-init” to the kernel args.
  • Compiled the latest uboot from Reform / reform-boundary-uboot · GitLab and then changed to copy flash.bin from the build directory instead of downloading it from GitLab.
  • Flashed the resulting images, then booted into the rescue image on the eMMC and changed /usr/sbin/reform-init to use /sbin/cryptsetup isLuks --disable-locks "$BOOTPART" instead of grepping the output of blkid. Added the --disable-locks flag to the luksOpen call as well.
  • Edited /etc/fstab on the NVMe to remove the “/boot” mount (upgrading rendered my machine unbootable again earlier, I suspect because kernel command line args there got overwritten somehow) and to mount /dev/mapper/cryptroot at / instead of /dev/mmcblk1p2.

Edit: Looks like regulatory.db isn’t getting loaded because cfg80211 is built-in, and so tries looking for the file before the root filesystem is loaded. Noticeably slower wifi, probably because my regulatory domain is now set to “world.” Can’t seem to change it, probably because regulatory.db isn’t loading.

[    6.481327] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[    6.481337] cfg80211: failed to load regulatory.db

I managed to break my rescue system on this step. If I boot with the SD card (using the new image v3) it works as expected, but if I try to boot without the SD card the display stays blank and doesn’t boot. Any ideas how to fix/debug?

I found a copy of the v2 image and decided to use that for the rescue system and that worked as expected. :sweat_smile:

Looking at the image partitions and contents, I see quite a difference, and I’m wondering if this is the way it’s supposed to be. Mainly, I don’t see the “Image” file which is supposed to be read by eMMC (if I understand correctly how it works)

V2 image partitions

V2 image contents

V3 image partitions

V3 Image contents

1 Like

I used this build, which was the latest passing job when I posted the instructions. build (#583) · Jobs · Reform / reform-system-image · GitLab

Perhaps something is broken now? I have not tried the latest jobs. There have been some changes made since then such as moving the kernel build to reform-debian-packages repo instead of reform-system-image and changing to the debian fork of the kernel. There were a bunch of changes made to the build scripts to support this and maybe there’s a bug.

Weirdly enough, none of the most recent images have worked for me at all no matter how I flash them to an SD card. I’ve tried to build from source and it won’t complete…I also think there might be a bug.

1 Like

What is the latest working image that is currently accessible?

My usual setup is booting from SD-Card and then use the encrypted rootfs on NVMe.

I downloaded the latest “OK” build artifact from Pipelines · Reform / reform-system-image · GitLab (called #530).

But when booting this image from the SD-Card I can not see any information on the built-in display but this uboot failure on the HDMI output:

Any idea what went wrong?

1 Like

Screen Shot 2022-03-21 at 11.27.00
I also had the exact same problem with the latest builds. See attached. Seems like a pattern is emerging!!

1 Like

Hm, this “Loading Environment from MMC… OK” looks suspicious. Maybe the author (Johannes) has a different setup of Uboot and the eMMC/SD-Card content. I did not use the onboard eMMC for booting so far.
And this (loaded) environment probably does not fit to the classic SD-Card/NVMe boot process?!?

1 Like

With @mntmn and Josch’s help, we’ve come up with a temporary solution, at least until the fix is mainlined.

Grab this u-boot flash.bin file: Artifacts · build (#707) · Jobs · Reform / reform-boundary-uboot · GitLab

Write it to your SD card of the latest system image like so:
dd if=./flash.bin of=/dev/your-sd-card-device conv=notrunc bs=1k seek=33


Oh, great … it is booting again!
Will try to make a new install of the NVMe from this new image now.
Many thanks!!

I’ve now also created myself an account on this board. If you have problems with the sysimage-v3, feel free to ping me here, write me an email directly at josch [at] debian [dot] org or file an issue here: Issues · Reform / reform-system-image · GitLab


Hi Josch! Nice that you joined the board!

I directly ran into a new issue when working with this “dd-patched” SD-Card image with the alternative uboot:

After apt update and apt upgrade the upgrade process first tried to upgrade linux-image-5.17.0-rc4-arm64 to linux-image-5.17.0-rc5-arm64 which lead to full(!) /boot partition filesystem when running update-initramfs :-/

So I removed some backup files from /boot (from a second console) while update-initramfs was running. But in the end the disfunctional uboot-image was re-installed and so I started over again.

WIth apt-mark hold flash-kernel linux-image-5.17.0-rc4-arm64 linux-image-arm64 u-boot-tools the upgrade process succeeded. But I think the size of the /boot partition definitely has to be increased …

yes, I already experienced the same problem as you did. The underlying problem is, that flash-kernel keeps copies of uImage and initrd in /boot that are bit-by-bit identical but obviously take up again that much space. I have this fixed locally by just increasing the size of /boot but am waiting for the gitlab CI to be fixed again. Currently the CI at still fails with “No space left on device.”, see build (#713) · Jobs · Reform / reform-debian-packages · GitLab

Thanks that you are working on this topic! So I will just wait some more time until starting to go for the next steps (installing the encrypted rootfs on the NVMe and hopefully get the eMMC running as boot device).