going

I think I've misled you. For some reason I thought you wanted to add the whole node. But you want to replace it with the same one but without the PI16 pin. It's not in my power. I don't have this board to check. I apologize.

Everything is right. It is this partition (from a USB drive) that the script is trying to mount into the future root file system. There's something wrong here.

Simply insert the USB drive from which the installation was performed into the connector on the running device and output the command: echo "$(fdisk -l | grep 'EFI')" That's all for now.

Don't rush to a conclusion. If you check your first configuration before installation, you should see for the echo "$(fdisk -l | grep 'EFI')" command: /dev/sda1 8192 532479 524288 256M EFI System And after installation: (Or just insert the USB flash drive from which the installation was done) /dev/sda1 8192 532479 524288 256M EFI System /dev/nvme0n1p1 2048 411647 409600 200M ef EFI (FAT-12/16/32)

Can you expand on this? I have it working on another opi5+ running armbian right now: @ozacas If it doesn't bother you, could you post the output of the "fdisk -l" command under the spoiler for your device? I have a suspicion that the script does not analyze correctly if EDK2 is used.

Just stay tuned. Will be included in the kernel version v6.6.54 or later

Unfortunately, you did not write which version of the kernel you wrote the overlay for. I checked it out. For the EDGE kernel (v6.11.2), this is present. No overlay is required.

SPI flash can be a bootable block device

I'm sorry, I used the wrong terminology. In your case, the initial boot code (uefi-arm64), which was downloaded from here with this code. It was recorded in the image and is located on the USB flash drive (boot device) from which you started the OS. By the way, it contains the UBOOT code plus some additional code, but that's not important right now. As far as I understand from the build system code, we should have a separate partition on the boot block device that is mounted in the "/boot/efi" folder and it is associated with the initial boot code that reads it. In turn, the OS boot code writes information there when updating the kernel, adding a variant of another OS to boot. The first problem is that NVME cannot be a bootable block device. Another one is described here. That is, your USB flash drive will serve as a boot device and NVME will have OS partitions. This is one scenario. Another scenario is.... however, the script does not provide for analyzing and doing any different steps depending on which image was built with UEFI support and which memory devices will serve as future boot devices. I think I found a few problematic parts in the code. Correction work is in progress.

Good. I have always believed that devices can only boot from a SD card, eMMC or nand\nor flash (here I mean the initial boot code). But I read the RK3588\S Datasheets and realized that its BootRom can also load USB OTG. This changes the logic for choosing quite seriously. Download Stages: 1) the power is turned on and the hardware BootROM tries to read the initial boot code from the media in the manner prescribed by the hardware manufacturer. For RK3588 it is: 2)The initial boot code configures the RAM and loads the main part of UBOOT into it. 3) UBOOT configures the peripheral, loads the kernel directly or loads another loader and transfers control to it. In your case, I would probably want to place the initial boot code on the SD card and the entire file system on NVME. That is, insert a clean CD and a clean NVME into the connectors, boot from USB and run armbian-install, which will partition (clean) the media and record everything correctly. (This does not work in the current version.) What configuration do you want to get in the end?

The first thing I noticed is that the build system does not handle GPT correctly: [ 5.300511] GPT:Primary header thinks Alt. header is not at the end of the disk. [ 5.300513] GPT:14942207 != 120831999 [ 5.300515] GPT:Alternate GPT header not at the end of the disk. [ 5.300516] GPT:14942207 != 120831999 [ 5.300517] GPT: Use GNU Parted to correct GPT errors. @ozacas Did I understand correctly that your device booted from SATA? Was the image of the Armbians recorded on a SATA drive? Was the boot code not written into the soldered chip? Just to understand. Good. I will make changes and provide you with a new version of the script for testing. It will take a few days. And thanks for the information provided.

Unfortunately, the script does not do some actions or does them incorrectly. You describe it well. I will rely on this information.

You can describe the wrong behavior and attach pictures with the selection dialog interface. You can show the partition table status of all memory devices before and after the change. You can post suggestions for improving the functionality of the script here. I am changing his logic right now and your opinion may be useful. I see some kind of manual work here. Or is it some kind of intermediate script state?

Yes, the script analyzer does not cope with the task if the memory device is clean and at least one partition has not been created. P.S. You can post suggestions for improving the functionality of the script here. I am changing his logic right now and your opinion may be useful.

This is an old and well-known problem for that time. The SOC has a controller (ARISC architecture). The code of that time randomly started the controller at the maximum frequency, for example, when the OS was turned off with the sudo poweroff command. If you did not pull the plug out of the socket, then the processor chip began to warm up more than when the OS was running. You need to update the u-boot and kernel to the current versions.