going

These three packages must be installed. Then reboot.

Just this command. You have already install the headers.

@JOHAN VAN DER MERWE Today, when I reread what I wrote for you, I realized that I was wrong. I did not understand your level of knowledge of Linux commands and the ability to use the system help. I apologize. Now again and in order: filename.gz - The gzip archive and the command of the same name for operations with files of this archiver. Team Help: gzip --help Extract files from the archive: gzip -dk filename.img.gz Unzip, that is, the files will be extracted from the archive and the archive will be deleted: gzip -d filename.img.gz zcat - Uncompress FILEs to standard output. The output of this command is used as the input for another command: zcat filename.img.gz | another-program For some reason, I thought that's what you need. filename.img.gz - This always implies the path to the file. You seem to have figured out the dpkg command. You don't have to install this file: linux-libc-dev-edge-rockchip_24.11.0-trunk_armhf__6.11.4-S1736-D29ea-P86b9-C85f2H5c21-HK01ba-V014b-Ba3b7-R448a.deb For you, the difference between the system package and this one doesn't matter. With respect

NOT sudo

The download commands are executed on behalf of a regular user. wget -r -l 1 --accept=deb -np https://fi.mirror.armbian.de/.testing/rk322x-box mkdir debs mv fi.mirror.armbian.de/.testing/rk322x-box/* debs/ rm -rf fi.mirror.armbian.de ls debs Execute sequentially line by line.

And you try to do it and see the result !!! Download packages directly on the board: wget -r -l 1 --accept=deb -np https://fi.mirror.armbian.de/.testing/rk322x-box .... mkdir debs mv fi.mirror.armbian.de/.testing/rk322x-box/* debs/ rm -rf fi.mirror.armbian.de ls debs There will be 4 files in the directory: linux-dtb-edge-rockchip_24.11.0-trunk_armhf__6.11.4-S1736-D29ea-P86b9-C85f2H5c21-HK01ba-V014b-Ba3b7-R448a.deb linux-headers-edge-rockchip_24.11.0-trunk_armhf__6.11.4-S1736-D29ea-P86b9-C85f2H5c21-HK01ba-V014b-Ba3b7-R448a.deb linux-image-edge-rockchip_24.11.0-trunk_armhf__6.11.4-S1736-D29ea-P86b9-C85f2H5c21-HK01ba-V014b-Ba3b7-R448a.deb linux-libc-dev-edge-rockchip_24.11.0-trunk_armhf__6.11.4-S1736-D29ea-P86b9-C85f2H5c21-HK01ba-V014b-Ba3b7-R448a.deb sudo dpkg -i filename.deb

Yes of course! You can also redirect the output of a command to the input of another command.

zcat --help zcat file-name.img.gz

This is an incorrect package name. Valid: linux-image-${BRANCH}-${LINUXFAMALY} BRANCH -> legacy,current or edge LINUXFAMALY -> sunxi,sunxi64,rockcip-rk3588 ... Example: leo@bananapif3:~$ echo "$(LC_ALL=C apt search linux-image | grep install)" ... linux-image-legacy-spacemit/now 24.11.0-trunk riscv64 [installed,local] And search headers: leo@bananapif3:~$ echo "$(LC_ALL=C apt search linux-headers-legacy-spacemit)" ... linux-headers-legacy-spacemit/noble 24.8.2 riscv64 Armbian Linux legacy headers 6.1.15-legacy-spacemit Please note that the version of the installed kernel and the version of the headers available from the repository do not match. That's because I built the core myself. And now the headlines are my problem.

This trace is intended mainly for developers of the build system itself. There is no information about the compilation error itself. Use the command to view: grep -Ei 'warn|err|\|' output/logs/log*.log.ans | batcat Or a black and white version for printing: grep -Ei 'warn|err|\|' output/logs/log*.log And publish only the lines that relate to the error.

I have a similar situation with bananapi-m3. When I connect the hdd using a USB-SATA adapter, the disk is first detected, and when accessing it, it suddenly disappears. But I know exactly the reason for this behavior, since I worked with a soldering iron with this device. The disk consumes 2.5 amps, and USB can give much less. I do not know if this message of mine can help you.

If you do on this device: fdisk -l Will the kernel see a block device for SPI flash? Do I understand correctly that the OS is running a common core from the OS vendor?

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?