SOLVED: How do I get root fs on NVMe?

VIM4
1

Which system do you use? Android, Ubuntu, OOWOW or others?

Ubuntu Gnome Raw`

Which version of system do you use? Khadas official images, self built images, or others?

Official Image

Please describe your issue below:

Issue is in subject:
I can’t get an NVMe root fs with various combinations of edit to boot.ini and fstab. I can chroot to the NVMe (nvmen1p1) and I rsync’ed the EMMC filesystem in place. I can’t trick a boot into this filesystem, even hard-coding the storage location over the variables in boot.ini.

This worked on VIM3 Pro. Is it possible on VIM4 yet? What am I missing? Do I need to change values in the kvim4.dtb?

–– Jeremiah

2

Additional efforts here have been rebuilding initramfs from my nvmen1p1 chroot, and changing values for root device in env.txt - INCLUDING the block which warns “DO NOT TOUCH THIS OPTION” and user_kernel_args. :wink:

Interestingly, this option and use splash stanza occur TWICE in my env.ini. A bug?

3

SOLVED!

I may not fully understand the interaction of VIM4 uBoot and various configuration files, but now have a 1TB Ubuntu rootfs on btrfs, with EMMC supplying /boot files and the rootfs kernel arguments.

The kernel and other boot arguments from env.ini and boot.ini were correct in my configuration, but these are not picked up by /boot/extlinux/extlinux.conf, which starts the kernel using defaults. My solution was to supply my rootfs UUID in extlinux.conf, and comment-out the supplied environment variables.

My clue that boot.ini and env.ini weren’t supplying these came when I couldn’t change splash and plymouth options with these files.

I hope this helps somebody else. Maybe I’m the only one planning on using the VIM4 as an Audio Workstation? :wink:

— Jeremiah

2 Likes
4

Could you provide step-by-step instructions for future devs looking to accomplish the same thing (like me)?

1 Like
5

Hi, Tyler. Welcome!

If you are familar/adept with Linux, it’s not the hardest thing.

  1. Prerequisite working EMMC installation.
  2. Partition and format the NVMe
  3. Mount the NVMe (/mnt)
  4. rsync the EMMc to NVMe, excluding /dev /sys /proc /tmp /media and /mnt
  5. chroot to /mnt with a correct binding of /dev etc.
  6. Edit fstab for new root UUID (verified with blkid)
  7. Optional stuff like renaming with hostnamctl, etc.
  8. exit chroot
  9. Edit /boot/extlinux/extlinux.conf - comment out existing lines that reference variables. Replace with new lines that reference:
    linux /boot/zImage
    initrd /boot/uInitrd
    append root=UUID=(your fs UUID goes here) rootfstype=ext4 (etc.)
  10. Reboot and enjoy.
  11. If boot fails, there’s the rescue system in OOWOW, which has a shell to fix things on the EMMc. Again, this is made complex because the EMMc doesn’t have a partition map! Then you might find it easier to re-image the EMMc, and try fixing /boot/extlinux/extlinux.conf again.

NOTE: The current EMMc RAW images do not contain a partition map, and mounting them is difficult, requiring use of offset calculations, etc. This means that /boot will be used by uBoot - because of its UUID reference in /boot/uEnv.txt. HOWEVER after the initrd starts and mounts the NVMe root, /boot will not be found and udev will not create device nodes. There’s ways around this, but they require first building an SD image with fenix, booting this, and transferring it to EMMc.

If any of this seems unfamiliar or daunting, I suggest waiting until official support is provided by Khadas images with NVMe capability, OR to give oneself a lot of time and forgiveness in a learning exercise!

As it is, booting on NVMe is very inconsistent with the current fenix kernel. What does “inconsistent” mean? Random lockups and reboots. Stable boots where the filesystem will drop to read-only, or simply start throwing block errors on writes.

This is definitely a work in progress. I did it because it was said not to work, but I was sure it could be done. LOL

— Jeremiah