wwortel

Let me answer my last question. The init script at the top of the ramdisk tree stems from the initramfs-tools package and can be changed from customize-image.sh by writing an edited version from /tmp/overlay/ (build/userpatches/overlay/) into /usr/share/initramfs-tools/

Thanks for all suggestions so far. Have been experimenting and actually managed to get the behavior wanted by editing the init file inside the uInitrd ramdisk. A test is done now whether the root_partition equals /dev/mmcblk1p1 , where the blk1 indicates boot from sdcard, and if indeed it booted from the SDcard dd is used to copy the /dev/mmcblk1 to /dev/mmcbkl0 , latter being the eMMC memory, followed by reboot. Upon reboot this copy is skipped because u-boot prefers to boot now from eMMC and one ends up with the normal first run interaction about passwords and locale. Remaining question: I did the edit by decompressing and unpacking the uInitrd from the SDcard, and after edit repacking and recompressing it and writing it back. How can I make the Armbian build system, when it does update-initramfs, make it include a modified init file in the /boot/uInitrd<uname -r> ?

Thanks for all the answers, that certainly go beyond 'not a viable option'. The hardware is a very dedicated motherboard with a Radxa CM5 compute module (RK3588s2 SoC) and some non-standard peripherals for software defined radio reception and transmission purpose, and an Armbian OS for the CM5 in which extensive use has been made of user patches and customize-image. A large part of the end users though are not into software, and an even larger part not into Linux based software. And, as with any product, a large part of the users will not read a manual. Rather than explaining how to use 'rkdeveloptool' or equivalents to put the Armbian into eMMC, it would be much simpler to have a one time SD card insertion, wait, power off, remove SD card, and power-on with boot from eMMC. Certainly normal use of the system has to be from eMMC as it boots faster than SD. Hope this explains the motives for my question that also aimed at not re-inventing the wheel. But a ready to go solution seems not yet available. Was looking into the one-time script 'armbian-resize-filesystem'. Perhaps that would be a good place to add the functionality I am looking for and, in case booted from SDcard, do a OS copy into eMMC before the OS on the SDcard is resized to memory size. I've read that when the copy is made one must make sure that no writing goes on into the source image that is being copied, to ensure integrity of the root file system that is landing on the eMMC. Ideas welcome how and where to do a copy into eMMC from SDcard in Armbian of the yet unexpanded OS! Igor's point taken that preferably it should be as simple as possible and minimally disruptive to current standard Armbian. Basically a switch in configuration that, when set, makes the first boot process detect whether it starts from SD, whether eMMC is present, whether the switch has been set, and only then does the dd copy and ends with the invitation to remove the SD card and reboot.

@going What makes you think this is not viable? After all u-boot is able to start Armbian from either SD or eMMC, so why could it not be made to copy an image from one to the other?

Well, apparently my question was not clear. No, the purpose is to have the option of creating a .img Armbian OS for a rk3588s based system that when written onto a SDcard and inserted in the rk3588s hardware, that also has eMMC on board, writes a working Armbian image to eMMC, such that the SD card slot is only used once to get the image into the eMMC. Reason being that not so experienced users find it a lot easier to write and insert a SD card, than to write into eMMC. Latter requires either access to serial console, or the use of Rockchip helper programs. Thinking about it it would be like the original .img as binary file inside a .img that can be written to the SD card, with the effect that just enough u-boot and perhaps kernel start is done from the SD card to get the .img file, also on that card, into eMMC.

Certainly not a new item but havn't found an Armbian how-to. Hardware: Rockchip rk3588 based hardware with both SDcard slot and eMMC memory. Wish: make a SD card image that, when inserted in the SDcard slot, causes a bootable Armbian OS image to be written to eMMC from that SDcard, followed by boot from eMMC. The bootable image should remain in its most compact form, to limit copy time, and only upon first boot from eMMC be made to use the entire eMMC. Has this been explored already? Ideas on how-to?

Built an Edge/Jammy firmware for a rk3588s2 based system(Radxa CM5). Panthor firmware for GPU G610 is not the right version though in this image. So after boot changed the firmware file, in the /lib/firmware/arm/mali/arch10.8/ folder, to the right version. Reboot produces the same problem though. It does not see the modified file, but still the original, wrong, one. With boot complete and going to the firmware folder the changed firmware is there. I presume that the changes I make end up in an overlay that only is mounted after the boot process. Rewriting the whole 6 GB image, just to change one file, is a bit cumbersome. Is there a way to change the underlying file so that it is used during boot?

Had to add some 60 packages for an embedded Rpi CM4 project and this thread in the forum proved very valuable since the documentation is completely outdated in the aspect of adding packages. Added the packages that needed to be included to the variable EXTRA_PACKAGES_ROOTFS. This differs from using EXTRA_PACKAGES_IMAGE in that the extra packages are cached. The first compile of course takes time to download and install all the extra packages, but having the packages in cache saves a lot of time in repeated compilations with the same EXTRA packages definition. Defined the extra packages in the config-<PROJECTNAME>.conf in the userpatches folder. Also the EXTRA_PACKAGES_ROOTFS_REFS variable must be defined there. Did latter in a loop: for i in {1..60} do EXTRA_PACKAGES_ROOTFS_REFS+="build:compile.sh:0 " done Would welcome some explanation about these REFS definitions. The package-lists.sh code, in /lib/functions/configuration, hints at it being a function name, source, and line no. of the calling function, but what one can achieve with these REFS lines remains unclear to me. Anybody here that can give some background that could be added to an updated documentation?

Tried: Armbian_22.05.3_Rock-3a_jammy_edge_5.18.0_cinnamon_desktop.img and Armbian_22.08.0-trunk_Rock-3a_jammy_edge_5.18.11_gnome_desktop.img Both start but do not see or recognize the SPI NOR memory. From dmesg: [ 6.256659] spi-nor spi4.0: unrecognized JEDEC id bytes: 00 00 00 00 00 00 [ 6.256695] spi-nor: probe of spi4.0 failed with error -2