going

@Meestor_X Please check the following: on a running device. It seems that we have a more reliable way to determine the block device SD or eMMC

PR for these changes: https://github.com/armbian/build/pull/8734

Sorry, I don't have this device. Try inserting a USB flash drive into the USB connector and installing the OS from the SD card on it. Try the available options. And choose focusing on your own real logic. Of particular interest and attention if you install the OS on eMMC. Then boot from the eMMC without an SD card connected. And then insert the card into the SD connector and run $HOME/bin/armbian-install. What do you see in the selection window?

see: /usr/bin/armbian-install The create_armbian function takes different arguments depending on the selection number. Everything looks right on this selection screen. But it seems to me that we see an excessive selection offer in the next selection step and this is misleading. But on other platforms where loading is possible only from a soldered chip, which is defined by the kernel as /dev/mtd, the selection screen will look logical. Try installing the OS on an eMMC or on an SSD connected to the device via a USB-SATA adapter using various options. Experiment. If you find illogical options, then feel free to write your opinion here.

Copy armbian-install to bin home directory Please replace line 839 as indicated here: Run the corrected version of the script. If everything works correctly for you, confirm it here. I will add a correction to the next pull request.

Please show screenshots of the selection menu step by step when you are trying to install the OS on eMMC. Show me what you see that I cannot see.

On 99% of the devices I know, eMMC is initialized in the OS as /dev/mmcblk0, but there are cases when this is not the case. # find real mmcblk device numbered 0, 1, 2 for eMMC, SD for ret in $(find /dev -name 'mmcblk[0-2]' -and -type b) do if [ -b ${ret}boot0 ];then emmc_dev=$ret else sd_dev=$ret fi done This part of the code was implemented due to the fact that on some eMCC platforms there can be both /dev/mmsblk0 and /dev/mmcblk1(2) This works for chips that provide boot0\boot1 partitions to write the bootloader. I think we can add more sophisticated logic to handle this exception for these chips. You can add here the name of the chip on your device. The translation may not be accurate. Please specify if something is not clear.

Is this your SD card? This is your eMMC just 3.6G in size. This is the first time I have met this variant. We need to think about whether it is possible to add an exception for this case.

Please post the output of the df -h and lsblk commands here. Which image are you using and which version of u-boot is running on your board? (this can be seen in the UART console)

Please tell me the source of this patch.

I'm not sure what this adds? I saw a user struggling to get it working, I managed to get it working, so thought I would give my steps that they may help other people. I apologize. I have not read what you wrote earlier. Please write whatever you see fit your work can be very useful. Success to you in your endeavor.

dmesg | grep -E 'hdmi|gpu|drm' ?

What can be said about this (help)? Answer: nothing. Please show the output of the UART download, show the source code of the overlay you are using. By reading specific data, users will be able to give you advice.

Please specify which OS and kernel version. By the way, I recommend building EDGE yourself.

Each attached memory disk must have its own unique UUID. This is its essence. This depends on the platform (BROM bootloader flashed into the chip) and possibly the switch soldered to the board.