Reform Migrate Fails with Reform Boot Config Errors

When trying to do a reform-migrate --emmc /dev/mmcblk0p2 with the latest Pocket Reform RK3588 image to reinstall the OS on my system after an aborted attempt to install the unofficial Debian 12 image fails for… exactly the same reason, it fails with this message:

Running reform-boot-config...
This script selects your preferred boot medium. It writes your choice to the fi

commenting original /etc/fstab contents
update-initramfs: Generating /boot/initrd.img-6.11.10-mnt-reform-arm64
W: missing /lib/modules/6.11.10-mnt-reform-arm64
W: Ensure all necessary drivers are built into the linux image!
depmod: ERROR: could not open directory /lib/modules/6.11.10-mnt-reform-arm64: 
depmod: FATAL: could not search modules: No such file or directory
W: Can't find modules.builtin.modinfo (for locating built-in drivers' firmware,
WARNING: Unknown X keysym "dead_greek"
WARNING: Unknown X keysym "dead_greek"
WARNING: Unknown X keysym "dead_greek"
WARNING: Unknown X keysym "dead_greek"
cat: /var/tmp/mkinitramfs_cBVlPU/lib/modules/6.11.10-mnt-reform-arm64/modules.b
depmod: WARNING: could not open modules.order at /var/tmp/mkinitramfs_cBVlPU/li
depmod: WARNING: could not open modules.builtin at /var/tmp/mkinitramfs_cBVlPU/
depmod: WARNING: could not open modules.builtin.modinfo at /var/tmp/mkinitramfs
Using DTB: rockchip/rk3588-mnt-pocket-reform.dtb
Couldn't find DTB rk3588-mnt-pocket-reform.dtb in /usr/lib/linux-image-6.11.10-
Installing  into /boot/dtbs/6.11.10-mnt-reform-arm64/rockchip/rk3588-mnt-pocket
cp: cannot stat '': No such file or directory
run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 1
cleaning up /tmp/reform-boot-config.Bcqq8e681y/proc
cleaning up /tmp/reform-boot-config.Bcqq8e681y/sys
cleaning up /tmp/reform-boot-config.Bcqq8e681y/dev
cleaning up /dev/mmcblk0p1
cleaning up /dev/mmcblk0p2
cleaning up /tmp/reform-boot-config.Bcqq8e681y
reform-boot-config FAILED to run

After which, the system fails to boot off internal storage. The same issue occurs with the NVMe drive. Any ideas?

These messages come from /usr/share/flash-kernel/functions and it claims that rockchip/rk3588-mnt-pocket-reform.dtb is missing from /usr/lib/linux-image-6.11.10-mnt-reform-arm64/. At least that’s what I hope the path is. Somehow your lines are all truncated.

So lets investigate. I downloaded the latest pocket-reform-system-rk3588.img.gz which should be https://source.mnt.re/reform/reform-system-image/-/jobs/6881/artifacts/raw/pocket-reform-system-rk3588.img.gz Can you confirm that this is the one you downloaded as well? That image does contain rockchip/rk3588-mnt-pocket-reform.dtb but the kernel is a tad older:

/usr/lib/linux-image-6.11.9-mnt-reform-arm64/rockchip/rk3588-mnt-pocket-reform.dtb

Two days ago there indeed was a new upload of kernel 6.11.10 to unstable, so maybe that broke things. Lets investigate that as well. The MNT Debian repos already carry that kernel here: Index of /reform-debian-repo/pool/main/l/linux/ But it seems even that kernel does contain rockchip/rk3588-mnt-pocket-reform.dtb as evident by running:

curl https://mntre.com/reform-debian-repo/pool/main/l/linux/linux-image-6.11.10-mnt-reform-arm64_6.11.10-1%2Breform20241116T152555Z_arm64.deb | dpkg-deb --fsys-tarfile - | tar tv | grep rockchip/rk3588-mnt-pocket-reform.dtb

So I’m at a bit of a loss. Could you do a bit more debugging and investigate your /usr/lib/linux-image-6.11.10-mnt-reform-arm64/ and check whether it contains rockchip/rk3588-mnt-pocket-reform.dtb or not? One way to find out is to run:

find /usr/lib/linux-image-6.11.10-mnt-reform-arm64/ | grep rockchip/rk3588-mnt-pocket-reform.dtb

Maybe somebody else has an idea?

The image I used matches that one hash-wise.

Trying to copy text out of UXTerm was… a mess. I’ll install a better terminal app next time.

Could I need to clean out /dev/mmcblk0p1?

“/usr/lib/linux-image-6.11.10-mnt-reform-arm64/” doesn’t exist on the image at all. It does have “/usr/lib/linux-image-6.11.9-mnt-reform-arm64/”

However, it is a kernel on /dev/mmcblk0p1 with leftover files from a previous Linux install on this device. So I need to clean that out somehow.

Deleting all of the files on /dev/mmcblk0p1 for other kernels allowed the migration to succeed.

1 Like

Hi, I’m glad that you fixed this problem for yourself. Could we maybe try getting to the bottom of this so that the next person does not run into the same problem?

Which files was it that your /boot contained? I hope you took a record of the output of ls from that directory before you wiped it so that we can find out what went wrong?

Which kernel was it you were running at the time when things broke for you? Did you maybe record the uname -a output?

Leftover files in /dev/mmcblk0p1 should not influence flash-kernel unless those files are the ones that your running system used to boot. Was it?

I hope we can still get to the bottom of this…

1 Like

The /boot contained “config-X-mnt-reform-arm64”, “dtb-X-mnt-reform-arm64”, “initrd.img-X-mnt-reform-arm64”, “System.map-X-mnt-reform-arm64”, “vmlinuz-X-mnt-reform-arm64” files, and a “dtbs/X-mnt-reform-arm64” folder for 6.11.2, 6.11.7, 6.11.9, 6.11.10, and 6.11.5+bpo (from the Debian 12 build).

I deleted all of these except for the one being used by the OS I was installing (first the official image, then Debian 12) to get it to work.

I was running 6.11.9 off the microSD when things failed to install for the official image, but it also affected 6.11.5+bpo for the Debian Stable image.

Aha, then I have an idea. Flash kernel obtains the kernel version it should be working on from the command line. reform-boot-config does not run flash-kernel directly but it runs update-initramfs -u and flash-kernel is run as by the hook in /etc/initramfs/post-update.d/flash-kernel with the version supplied by update-initramfs. Since we ran update-initramfs with -u it might’ve attempted to update one of the stray initramfs in your /boot for which no equivalent in your rootfs existed and that obviously cannot work.

What I’m puzzled by is, that if that is the problem then why has this not happened to somebody before. Could it be that it is related to the ordering and that your /boot just contained a newer kernel version (6.11.10) than on your system which only had 6.11.9?