Booting from LUKS-encrypted NVMe after A311D upgrade?

I finally found time to upgrade the CPU module in my Reform 2. The upgrade was straightforward, but I did have to add the solder bridge on the mPCIe adapter to get my NVMe drive (SK hynix Gold P31) to show up.

However, I can’t figure out how to boot off of the encrypted drive. I tried modifying U-Boot’s kernel parameters over the UART as specified here: Advanced Topics — MNT Reform Operator Handbook documentation

setenv bootargs noinitrd root=/dev/mmcblk0p1 rootwait
  rw console=ttymxc0,115200 console=tty1 cma=512M
  pci=nomsi init=/sbin/reform-init

But when I try to saveenv I get:

=> saveenv
Unknown command 'saveenv' - try 'help'

Proceeding with boot doesn’t succeed either. I was able to decrypt and mount the drive when booting from the SD card, so the drive is working. I downloaded the A311D system image for the SD card a couple days ago, so I should be up-to-date.

I feel like I must have missed some documentation somewhere. Thanks for any help!

Hi, there are a few things to unpack. You mention init=/sbin/reform-init. The reform-init script is from before sysimage-v3 existed. Since sysimage-v3, Debian on the Reform will boot like most other Debian installations out there via an initramfs. This has not yet been documented in the handbook.

Unknown command 'saveenv' - try 'help'

This is because u-boot on the reform has saveenv disabled. The reason for that is, that before it got disabled, it happened that a user would run saveenv with values that made their system unbootable. In that state, even inserting an sd-card with a fresh u-boot would not fix the problem because that u-boot would also load the broken environment from emmc and would keep failing in the same way. In attempt to keep the u-boot env on emmc pristine, saveenv got disabled.

Next you seem to be using root=/dev/mmcblk0p1 which would instruct the kernel to load the rootfs from sd-card but you want the rootfs from nvme. It is also not clear whether changing your u-boot environment will have any effect in the first place as we only recently modified the default boot.scr that is generated by flash-kernel to respect the parameters set by uboots $bootargs. For the longest time, it would just simply ignore whatever you set there.

As said earlier, how sysimage-v3 and the even more recent sysimage-v4 work is not yet documented in the handbook. I made an attempt to collect some information in this issue but this is mostly imx8mq specific: document boot options (#2) · Issues · Reform / reform-handbook · GitLab

It would be useful to know what setup you were running before you received your a311d upgrade. Were you already running sysimage-v3? It is possible to switch the SoM without re-creating everything from scratch (others have done it) but there is no official write-up on that yet.

Depending on the answer it might just be easier to back-up the data on your encrypted nvme (probably just your /home directory?) and then start from scratch. If you don’t like the option i can see if I can help you do the migration manually but I need more information about your setup from before. Have you always kept all packages up-to-date? How is your nvme encrypted? Is it inside a lvm2 volume?

1 Like

Hi, thanks for your response! I rarely mess around with boot-related stuff, so I have to admit, I find the topic a little confusing. I’ve only been a casual user of the Reform so far, and it can be difficult to figure out the latest process when you only poke your head in occasionally.

I don’t actually know which sysimage I had on the previous SD card. I didn’t wipe it, so I could inspect it if there is a way to tell? I’m pretty sure I followed the same steps I tried above when I first encrypted the drive, so maybe it was pre-sysimage-v3? I do remember using the UART to configure something, but it’s been a while.

On the NVME drive, I periodically ran apt update/upgrade, and did so a few days ago. I guess I had assumed that was all that was necessary to update it for the new module. There’s nothing on the NVME that isn’t synced with my other machines, so I could certainly just start from scratch. I believe I created it with the Gnome Disks tool, and it does appear to be inside a LVM2 volume.

Boot from SD-Card, mount your encrypted rootfs somewhere and chroot into it. Then run the reform-check utility. What does it report?

If you want to migrate your system instead of starting from scratch, please mail me to figure out what you have to do. Everybody has a different setup which makes coming up with instructions that work for everybody quite difficult. Since possibly a lot of messages forth and back will be needed, I much prefer to do this by mail than via this forum.

Thanks for your help josch, but I decided to start from scratch since it was easy to restore my drive state. For future reference, these were my basic steps:

  • Copy reform-system-a311d.img to SD card with dd
  • Boot from new SD image
  • Login as root
  • Create normal user account, make sudoable, and switch to that account
  • Run sudo umount /boot (see below)
  • Run sudo reform-setup-encrypted-nvme (and agree to migrate)
  • Reboot into NVME

When I first ran reform-setup-encrypted-nvme it complained that a partition was still mounted, and I got a warning about /etc/crypttab not having an entry for my LUKS partition.

I unmounted /boot before running the script again. This time there were no
obvious errors or warnings—except that it said that reform-setup-encrypted-nvme had failed. Despite the failure message, rebooting
worked as expected. I didn’t think to capture the output until it
was too late!

Yes, that was the right thing to do. The script refuses to continue with /boot mounted because it needs to modify it in a way that makes your current system unbootable. You having to manually unmount /boot is a way to make sure that you really want the current system to become unbootable. Maybe I should improve some error messages.

If it only failed in the very end and your system was still bootable, then it is likely that the problem is already fixed in the new reform-tools version:

1 Like

I now improved the error message, giving more information about what is going on. I also added some heuristic to detect that one is currently running from a rescue system sd-card (as opposed to running this from a properly installed system) and in that case, present a prompt to the user which allows them to choose to unmount automatially: