calinb

I posted here with several other relevant posts preceding it: https://forum.pine64.org/showthread.php?tid=17084&pid=112226#pid112226

I too encounter the error on my Pinebook Pro when attempting to run Armbian / on eMMC (/boot files on SD card). The machine locks after this screen: https://www.dropbox.com/s/4x7u5si8ifmw9en/Armbian_UUID_Does_Not_Exist.jpg?dl=0 Also, even though Armbian will boot off an SD card exclusively, it will not boot when eMMC is disabled (via hardware switch on the PBP). This indicates that the U-boot on the SD card image does not work. After flashing PCM720's U-boot files to the SD card, the SD card WILL boot with my eMMC memory disabled but still encounters the above initramfs error (can't find UUID). When run from the SD card (/boot and / files on SD card), Armbian works with both my eMMC and NVMe memory so memory support is obviously in the kernel.

My strategy to boot from SD with / on the eMMC didn't work. All I get is a spinning Armbian pinwheel. All the other distros I've run on the PBP use a separate boot partition and a different file structure than Armbian. A reply to one post that I found here on the forums requesting information about armbianENV.txt documentation seems to imply that the entire system must be rebuilt and there's no documentation (it's too simple to benefit form it ) I really like Armbian but we should not have to run / off of an SD card.

NVMe cannot be booted. (It cannot contain u-boot or tow-boot or ANY boot code.) It's not in the boot path. See the Pine64 wiki at https://wiki.pine64.org/index.php/Pinebook_Pro#Using_as_OS_root_drive The SoC does not include the NVMe boot code, so the NVMe is not in the SoC's boot order. However, using the U-Boot update script from the mrfixit2001 Debian or Arglebargle's modified script, and the modified u-boot images provided by forum user pcm720, you can now add support to boot from an NVMe drive. and quoted from https://wiki.pine64.org/index.php/Pinebook_Pro#Boot_devices Please note that PCIe, the interface used for NVMe SSD on the Pinebook Pro, is not bootable on the RK3399 and therefore is not a part of the boot hierarchy. It is possible to run the desired OS from NVMe by pointing extlinux on the eMMC to rootfs on the SSD. This requires uboot, the Kernel image, DTB, and extlinux.conf in a /boot partition on the eMMC. Also, wherever you put this boot code, the target kernel and /boot files must support it too and the subsequent boot priority that it provides is at the whim and discretion of its author! So, if you want to ditch both eMMC and SD memory as part of the boot chain and boot a system on NVMe (/ and boot), you must use SPI. Sadly, it might not work for all operating systems due to bugs or lack of kernel support: https://wiki.pine64.org/index.php/Pinebook_Pro#Using_the_SPI_flash_device Here is some information on using the SPI flash device: You need the kernel built with SPI flash device support, which will supply a device similar to: code>/dev/mtd0 Unfortunately, at this time, Armbian seems to have problems when the Armbian system resides on media other than the SD card! I don't know if the problem occurs when Armbian relies on a non-Armbian u-boot (eMMC u-boot) and/or even if the Armbian supplied u-boot doesn't work when it and the Armbian system are flashed to eMMC. I also don't know if Armbian would work with u-boot or tow-boot or something else flashed to the SPI NOR memory. My guess is it's a poor wager! I think I might try to copy the Armbian / system (copy files--not an image) from my Armbian SD card to my eMMC (or maybe try using my NVMe SSD too, which has been proven to be accessible when booting Armbian from the SD card). The Armbian /boot files don't look anything like the /boot files I've seen in other distros. I have "armbianENV.txt": verbosity=1 bootlogo=true extraargs=systemd.unified_cgroup_hierarchy=0 overlay_prefix=rockchip fdtfile=rockchip/rk3399-pinebook-pro.dtb rootdev=UUID=f57dd6bf-3737-40f9-95b0-376895bc2055 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u I wonder if it (the Armbian SD card /boot code) would load and run the system from eMMC or NVMe, if I simply change the rootdev=UUID entry to match the desired target. (and also change the fstab entry in the target). Again, I don't know how this file works. What does "usbstoragequirks" do? That's a scary label! The Slackware PBP aarch64 distro only supports booting a system on NVMe from an SD card. (Slackware devs don't even officially support eMMC, which they freely admit they don't trust as reliable hardware, because it's cheap NAND memory.) This usage model would be fine with me with my Armbian system! Once booted, the SD card can be unmounted and removed.

I just recalled that my PBP was as dead as dead can be when I first received it, despite having a fully charged battery. I had to hold the power button down for at least 15 seconds before releasing it and then giving it another normal press to get it to boot. It has done this to me several times--most often after I attempt to use suspend mode, which sadly doesn't work reliably or well enough to use. Sometimes I get a fully dead machine (well not fully dead once I discovered the very long power key press recovery trick) after a normal shutdown too, but that is rare.

I might find time to work on this. I'm loving my latest SD install of Armbian Jammy KDE Fusion and I'd like to copy it from my SD card to on my PBP NVMe drive (or at least my eMMC). I've done this sort of thing with my PBP in the past and even had Manjaro running with / and /boot on my NVMe drive. I also wrote a crude dual boot script to toggle the boot between systems on NVMe and eMMC. I installed PCM720's Uboot code but stopped short of risking its install to SPI. I've always had strange boot problems from time to time with my PBP though. When I had Manjaro installed to NVMe (/boot and /), I had two occasions when a Manjaro apt-get upgrade killed the boot with the system entirely on NVMe. Luckily I had backups. I think both boot failures happened when a kernel update was included in the upgrade. Stritt (Manjaro forum mod) and I never got to the bottom of it though. Once I recovered the system by building a new kernel package from source and installing it to the broken system. Then it worked from NVMe again so I came to the conclusion that it wasn't actually a kernel change that caused it but, rather, something else associated with it. Here's the PCM720 thread and one of my posts. PCM720 provides links to his code earlier in the thread. It's difficult to find his most recent code so I'll try to find it and provide a link here. https://forum.pine64.org/showthread.php?tid=8439&page=13 I don't post on the Pine64 forum anymore though. Pine64 forum mod, Arwen, was far too aggressive in the censorship of posts right after COVID broke. Geesh--II was a DivX forum mod for years back when it was a nearly unique and very popular forum (as was doom9 :)) and, I never needed to censored anyone--especially for a general off-hand comment that wasn't even directly associated with an event like COVID.