MNT Reform System Image V3 Beta

Finally got to install sysimage-v3 today, had to fiddle around with crypttab to get my LUKS+LVM on NVMe setup working but otherwise everything went smoothly.

Everything seems to be working fine, except for the HDMI output. My monitor that worked with v2 now doesn’t, even if I put imx8mq-mnt-reform2-hdmi.dtb into /etc/flash-kernel/dtbs/ (and update-initramfs)

Here’s the dmesg log when plugging the monitor in:

[ 3151.570988] cdns-hdmi-core: HDMI Cable Plug Out
[ 3151.839441] cdns-mhdp-hdmi: get block[0] edid failed: -22
[ 3151.845038] cdns-hdmi-core: Invalid edid
[ 3151.850015] imx-dcss 32e00000.display-controller: [drm] Cannot find any crtc or sizes
[ 3151.854440] cdns-mhdp-hdmi: get block[0] edid failed: -22
[ 3151.863419] cdns-hdmi-core: Invalid edid
[ 3151.873923] cdns-mhdp-hdmi: get block[0] edid failed: -22
[ 3151.879509] cdns-hdmi-core: Invalid edid
[ 3151.883663] imx-dcss 32e00000.display-controller: [drm] Cannot find any crtc or sizes
[ 3151.891663] cdns-hdmi-core: HDMI Cable Plug In

EDIT: weirdly enough, the first kernel messages at boot appear on the HDMI output and then it shuts off and the rest of the logs appear on the laptop display.

Yeah, manual twiddling is expected there. Since everybody’s setup is different I wonder if we can ever supply a script to do that conversion automatically without loosing any data.

That’s not how you switch to HDMI. You either use reform-display-config dual or you manually run:

$ "MNT Reform 2 HDMI" > /etc/flash-kernel/machine
$ update-initramfs -u

Though the plan of the person handling the upstream of our Linux kernel patches also plans to do away with having two different dtbs and wants to support dual display support with a single dtb in the future once they get around doing the necessary work.

Ooops, sorry about that, I forgot about this command ^^’

I gave it a bit more tries and it sometimes works, I don’t know what’s up with that. Looks like it has to be plugged in at boot, but sometimes I get no screen, sometimes I get HDMI.

Thanks a lot for all the work! :3

I’m seeing the following error with the latest apt upgrade…not sure if it’s just a me thing or not.

Setting up initramfs-tools (0.141) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.141) ...
update-initramfs: Generating /boot/initrd.img-5.18.0-reform2-arm64
W: No zstd in /usr/bin:/sbin:/bin, using gzip
E: /usr/share/initramfs-tools/hooks/lvm2 failed with return 1.
update-initramfs: failed for /boot/initrd.img-5.18.0-reform2-arm64 
with 1.
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subproc
ess returned error exit status 1
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)

It is not you. This is a problem of using Debian unstable: if you update at the wrong time, you get all the bugs. In this case, it’s this bug:

You can make upgrades a bit safer by installing the apt-listbugs package. With that package installed, you will get a prompt that shows you all release critical bugs in the package versions you are about to upgrade to and which will then allow you to abort the upgrade. That package is also part of the latest sysimage-v3 since this commit: install apt-listbugs to prevent installing packages from unstable with RC bugs (3c702f0e) · Commits · Reform / reform-system-image · GitLab


Great, thanks for the clarification and apt-listbugs tip!

Seems https (443) is down for
“HTTPS version of is not available”

E: Failed to fetch  404  Not Found [IP: 443]
E: Failed to fetch  404  Not Found [IP: 443]

The server is fine, we deleted this package yesterday because the display wouldn’t come up in 5.19 and we didn’t want people to run into trouble. We identified a fix today and will update shortly. Sorry for the inconvenience!

Ran into this by skipping the MNT repo and still obtaining a kernel update via Debian.
If you’ve end up with a system that is not displaying anything, copy boot.scr.bak to boot.scr on the boot partition to revert to attempting to boot the old kernel and try to boot your Reform again.

After a bunch of debugging, we finally fixed the 5.19 kernel and released the packages again. You should be able to apt update and apt upgrade now.


Installed and running :+1:

1 Like

Working great, Danke! :floppy_disk:

1 Like

Running smoooooooooooth :star_struck:

To provide a little more useful feedback, I used to have display problems in KDE and some problems in Sway, where parts of the windows or taskbar (KDE) would not render at all. For sway, this happened mostly with the Falkon Browser.

I have not seen any of that so far. Also KDE seems to run much more fluid.


Looks like an apt update from a few days ago killed Sway. :dotted_line_face:
Errors out with missing config files / display issues (kHz mismatch).

Tried reform-display-config single and rebooted but that unfortunately did not resolve the issue.

@mntmm provided the fix -

Josch, I downloaded the latest sysimage-v3. I’m installing to a USB device LUKS/LVM with reformvg-root and reformvg-swap partitions (ext4, swap).

TL;DR - The installation fails to update-initramfs, and fails dependency check that it ought to pass. Full details below, and I apologize for the length. My time to work on this comes in spurts where I can get a lot done, then have to go do “paid work” for a while… so I try to get as much in at a time. Thank you for all you do for the project, the code, the upstream distro, and for your advice to me here.

Error snippet follows from # ./

Processing triggers for initramfs-tools (0.142) ...
update-initramfs: Generating /boot/initrd.img-5.19.0-reform2-arm64
W: No zstd in /usr/bin:/sbin:/bin, using gzip
cryptsetup: WARNING: Couldn't determine root device
cryptsetup: ERROR: Couldn't resolve device /dev/dm-1
Warning: root device /dev/mmcblk1p2 does not exist
W: Couldn't identify type of root file system for fsck hook
grep: warning: stray \ before #

Note: this is fixed after anapt-get update && apt-get upgrade

The grep warning is due to the use of egrep instead of grep -e. This occurs also many times in a subsequent apt-get upgrade following the apt-get update.

The cryptsetup I haven’t looked at the code.
The zstd warning could be fixed by adding the zstd package to any of the many apt-get install being called, or so I thought, but after adding it and verifying it’s at /usr/bin/zstd the same warning appears on run #2.

Number 2 (fatal): Note: Extra lines up top so you can easily tell where this happened:

+ ./
I: automatically chosen mode: root
I: chroot architecture arm64 is equal to the host's architecture
I: automatically chosen format: tar
I: using /usr/local/bin/reform-system-image-sysimage-v3-20220830/reform2-imx8mq/mmdebstrap.jMMrPJdRC9 as tempdir
I: running --setup-hook in shell: sh -c 'mmtarfilter "--path-exclude=/dev/*" < target-userland.tar | tar -C "$1" -x' exec /usr/local/bin/reform-system-image-sysimage-v3-20220830/reform2-imx8mq/mmdebstrap.jMMrPJdRC9
tar: Ignoring unknown extended header keyword 'hdrcharset'
I: running apt-get update...
I: nothing to download -- skipping...
I: nothing to extract -- skipping...
I: no essential packages -- skipping...
I: running --customize-hook in shell: sh -c 'rm -f "$1"/etc/motd' exec /usr/local/bin/reform-system-image-sysimage-v3-20220830/reform2-imx8mq/mmdebstrap.jMMrPJdRC9
I: running --customize-hook in shell: sh -c 'ln -s motd-full "$1"/etc/motd' exec /usr/local/bin/reform-system-image-sysimage-v3-20220830/reform2-imx8mq/mmdebstrap.jMMrPJdRC9
I: running --customize-hook in shell: sh -c 'mv "$1"/etc/apt/apt.conf.d/10apt-listbugs "$1"/etc/apt/apt.conf.d/10apt-listbugs.bak' exec /usr/local/bin/reform-system-image-sysimage-v3-20220830/reform2-imx8mq/mmdebstrap.jMMrPJdRC9
I: running --customize-hook in shell: sh -c 'chroot "$1" apt-get install --yes git libreoffice libreoffice-gtk3 inkscape firefox-esr chromium emacs gimp wmaker x11-utils imagemagick-6.q16' exec /usr/local/bin/reform-system-image-sysimage-v3-20220830/reform2-imx8mq/mmdebstrap.jMMrPJdRC9
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 inkscape : Depends: libpoppler118 (>= 22.02.0) but it is not installable
E: Unable to correct problems, you have held broken packages.
E: run_chroot failed: E: command failed: chroot "$1" apt-get install --yes git libreoffice libreoffice-gtk3 inkscape firefox-esr chromium emacs gimp wmaker x11-utils imagemagick-6.q16
W: listening on child socket failed: 
I: removing tempdir /usr/local/bin/reform-system-image-sysimage-v3-20220830/reform2-imx8mq/mmdebstrap.jMMrPJdRC9...
E: mmdebstrap failed to run

So after all that,

apt-get update
apt-get upgrade

Comment: it once again downloads hundreds packages. I’d like to set up a build environment that downloads them once and keeps them. Is there an easy way to do that?

So, run #2 ended the same way, despite having adding zstd and doing the update and upgrade.

Run #3:

apt-get install -f
apt-get update
apt-get upgrade

170 packages held back, everything else good.

apt-get dist-upgrade

170 new, 24 upgrades, and we try again.  
Fyi before this libpoppler was 22.0-3 which the upgrade said was not >=22.0


Same failure. Wishful thinking on my part that installing zstd and updating the packages would fix something :wink:

I’m confused. You say you downloaded the latest sysimage-v3 but the rest of the post is about you building it yourself?

Both are warnings. You do not need to do anything here. Nothing is failing.

This is a known bug in inkscape:

The fundamental problem is, that we are using Debian “unstable” for sysimage-v3 and (as the name suggests) that often breaks. For example just three days ago we had the Perl 5.36 transition which made half the archive uninstallable for two days. Had you tried to run the script then it would’ve certainly failed.

Apart from the build tools themselves (mmdebstrap, genext2fs, e2fsprogs, binfmt-support, git, mount, arch-test, qemu-user-static and parted) the packages on the outside have no influence on what gets installed into your system image. Everything is done in a chroot environment which is independent on your outside system.

Yes, the easiest way to do that is to use apt-cacher or apt-cacher-ng and then modify to use as the mirror instead of

You mean you installed zstd on the outside? That will have no influence on zstd being available inside the chroot.

What does this have to do with sysimage-v3?

Currently, inkscape is broken on arm64. Nothing you do on the outside can fix this. This can only be fixed in inkscape on Debian. Until that is done, you can either manually remove inkscape from the list of installed packages in or you can just build the rescue image which probably works fine for your purposes:

diff --git a/reform2-imx8mq/ b/reform2-imx8mq/
index 946ac41..7d2add4 100755
--- a/reform2-imx8mq/
+++ b/reform2-imx8mq/
@@ -75,6 +75,7 @@ printf mntr | dd of=reform-rescue-system.img seek=440 bs=1 conv=notrunc
 dd if=./flash.bin of=reform-rescue-system.img conv=notrunc bs=1k seek=33
 echo Reform Rescue System Image created: reform-rescue-system.img
+exit 0
 # Full System -----------------------------------------------------------
 # chroot into the userland and add extra applications

Above patch makes exit successfully right after having created the rescue system. This will work (I did it myself yesterday).

But why are you still building it yourself instead of downloading the latest known good pre-built image from the CI? Are you making modifications to the scripts building the image?

I wish I knew how to quote you and reply inline… until then…

  • Thank you again for taking the time.

  • I did not use the prebuilt sysimage-v3. I download the tarball and built it figuring that would be “better”. No, I don’t know what “better” I was thinking that would be.

  • I thought the chroot’d environment got a copy of root via dd, and that somehow that would magically include what I’d installed on the outside. Clearly not. As you say, warnings can be ignored.

  • Will at next opportunity download fresh sysimage-v3 (image, not tarball) and reformat the SD card, and go from there.

  • At this point I’m not sure where I am going with this. My original desire was to be able to boot multiple systems (e.g. Mint, etc.) as a modification of the MNTRE Debian. Now it seems like either wishful thinking or trying to use a horse to get across the ocean when a ship or a plane is a better tool…

Thanks again. I’ll try not to waste anyone else’s time unless going “from scratch” with the image doesn’t yield a useful result. The last time I did an image dump to the SDcard I ended up with a system pre-logged-into root with no gnome no “MNT” additions, no colored menus, but the hardware was just fine.

Tucson, AZ US (UTC-0700)

Thank you!!

TL;DR - That all works perfectly, moving back and forth SD->USB->SD->USB.


I ended up using this link to the sysimage-v3 Beta and it worked great.

Using my previously (mangled on posting) script I was able to automatically create the encrypted USB drive with two partitions and then switch over to it. (I used reform-boot-config for that.)

After verifying everything works, I used reform-boot-config sd to switch back to the SD card. That too worked.

After that I used reform-boot-config /dev/reformvg/root to move back to encrypted USB second time, this time with no rsync, just swap the end device.

---time to rest---
1 Like

I’m having trouble waking from suspend using the latest V3 image. as @bnys reported, my system also just hangs after running systemctl suspend then attempting to wake it. The screen backlight comes onI have the reform-sleep service enabled.

This might be a bit stupid question - but why /boot partition is set to 488MB?
Comment in line 48 of says “debian-installer chooses 999424 sectors (= 488MB) by default” - is this the only reason? I was thinking more along the lines of starting main partition at 512MB, but it would require /boot to be 508MB. In any case - I’ll try both variants, but want to see if there is something to look out for.