Hi, I’m happy to hear the migration process worked just like that!
If you want to go SD-less, you have to switch over to the eMMC. For this, you need to switch the little DIP switch on the i.MX8M SOM. This is a bit tricky because you need to remove the heatsink to reach the switch. Putting the heatsink back on with the little plastic spacers requires a bit of patience. But yeah, all you need to do is flip the switch, boot without the SD card (you will end up in the Rescue System). There, do reform-boot-config nvme once again.
No problem with the heatsink. I am now in rescue mode. But the script reform-boot-config does not work. It always wants to mount and write the SD card. The SD card (/dev/mmcblk1p1) does not exists. The eMMC is /dev/mmcblk0p1.
Tried it manually.
echo nvme > /reform-boot-medium
But after a reboot it boots the rescue system again.
Thanks you two. This worked for me as well.
To summarize my approach:
* Format nvme using fdisk or gnome-disk
* APT install rsync
* reform-migrate from terminal
* reform-boot-config nvme
* open reform, loosen the screws on the heatsink(you don't have to remove it, just lift it a little to get to the switch) and change the dip switch to off
* flash the new u-boot version
Thanks very much guys, system is working and I’m typing from my reform
This worked perfectly for me! I wasn’t able to get it to work with some of the previous instructions, but this did the trick for whatever reason. Thanks!
Another way of doing this if you’re having issues is to manually edit the file /reform-boot-medium on the emmc, and put the desired boot medium in there, be it “sd” “nvme” or “usb” (without quotes
If I invoke this command above before trying to flash the u-boot to emmc, would I still have to physically flip the DIP switch on the i.MX8M SOM in order to write a to u-boot successfully, or can I just leave the switch in the default position and actually “unforce read-only” through toggling this sysfs flag temporarily?
Hi, these two things are unrelated. The physical switch is for telling the i.MX8M ROM bootloader to load u-boot from eMMC vs SD. The force_ro is a pure software/kernel setting to allow you to write something like u-boot to eMMC.
I followed the instructions and they worked but it uses the old version of the kernel from the eMMC. I was able to fix this by flashing a new recovery system.
I have a much more basic question than some of the other issues in this thread. What should be the partition scheme for the ssd, and what is the “correct” way to run the reform-migrate script?
I tried what I thought was a rather basic partition scheme of:
boot (250mb)
root (60GB)
home (rest)
swap (24gb)
I think I mistakenly assumed the reform-migrate script wanted to use the first partition to install some boot stuff, but the program bugged out. Now I can’t even get the system to boot from the SD card (kernel panic).
Obviously I’m still a little confused about the whole boot process on this system.
Boot partition lives on the SD or eMMC, the SSD does not need one. I created a Master Boot Record partition map with fdisk and a single partition. I formatted it as ext4 and then ran reform-migrate /dev/nvme0n1p1
Happy to report that I am now booting from the SSD! From my perspective, this is a huge speed and responsiveness improvement – ballpark 3x speedup all around, maybe more.
One question: I partitioned my drive such that there is a swap partition at the end, but I’ve noticed that when running free the system reports that there is 0 available swap space. I suppose this is some deeper-level linux thing I just don’t know, but is there some way to automatically read the swap space on boot and configure it correctly?
You need to do more than just create the partition.
First you need to set it up using mkswap /dev/whatever where whatever is your nvme partition such as nvme0p2
Then you can manually enable it with swapon /dev/whatever and it should show up. To make it permanent you can then add a line to your /etc/fstab
True, it was just easier to show it with a device name rather than UUID, on the reform it’s likely not an issue either way as you can’t attach another nvme ssd if that’s what you’re running from.
A reason for a swap partition over a swap file is speed, though I’m currently using a file myself as I forgot to make the partition. With the partition it doesn’t have to go through the filesystem layer to access data, it’s doing direct disk accesses. With a file it has to go through the translation and possible fragmentation of the swap file, which may not be contiguous.
