Raul

Ah My bad! I can confirm that the image boots successfully and the files are correctly populated in /boot and EFI: Thanks for fixing this! I am sure a lot of people are going to appreciate seeing the traditional Linux boot folder structure and layout - esp the folks with the ITX boards... Cheers and have a Great weekend ahead!

Thanks for the effort! I ran and built the image. This works to create 3 partitions: (Yes I changed UEFI SIZE to 256 above hoping that kernel files would go into p2 /boot) ... However the change does not fix the kernel files appearing in EFI partition p1 rather than a p2 /boot partition. Let me know if you plan to fix this because the grub.sh code seems to have been designed and written around that assumption: I checked this in a hurry and not sure if simply changing the code to this will work: If you don't plan to fix that - then I am planning to boot with the /boot files in p1 then copy the kernel files over to p2 and then run an edit fstab and an update-grub sequence with os_prober to create a new grub entry and try booting from it before I delete the files in p1... Thanks!

I created the new image - while the partitions were correctly created all the kernel files meant for /boot landed in the EFI partition. A lot of things need to be changed in the code like fstab and grub entries to correctly point to initrd and vmlinuz in /boot on p2 instead of the combined efi+boot ... too fatigued to do this now. Will just settle for the default architecture with everything in UEFI_MOUNT_POINT ... sigh!

I was able to get it work by changing this around line#47 of extension/grub.sh and then setting the following params in the compile config: The build almost finished completely with: Then unfortunately I ran into a github token expiry situation: But I think I get the partition layout I wanted originally now - will need to wait for the token expiration thing to get over before I can dd it to my emmc and test. Need to verify if the kernel files correctly get populated in p2 mounted at /boot and EFI at /boot/efi ... @Igor Would you like to consider the change I tried - if it can be made a part of Armbian just like pr-11072 that you did?

It works. (I ran a git checkout -f pr-11072 to force overwriting my earlier local changes first). I have some additional questions that I hope you can quickly answer? I really want a separate EXT4 /boot and the FAT32 EFI mounted under /boot/efi ... preferably encrypted /boot (I hear modern grub can read encrypted /boot - does armbian version grub do that?). I am kinda uncomfortable with my core kernel files on a FAT32 filesystem without any permission features. How do I make that happen with a custom build? The following set of parameters dont seem to do it (esp BOOTFS_TYPE=ext4) as you can see in the fdisk output of the image I just created. I was hoping this was the switch to do it - BOOTFS_TYPE=ext4 combined with BOOTPART_REQUIRED but it does nothing. Thanks

Thank you for the prompt fix! However I was already tinkering in the meantime without checking for updates here and managed to create a 512M /boot by editing extensions/grub.sh directly and the resulting build gave me: Now its installed and running. But tell me the exact git command (I am not a dev) to pull your specific change and I will ensure I test it by creating a new image and report back tomorrow with the output of fdisk -l on the img file. PS: When I tried the lvm extension without the grub.sh hack it still created a 260M /boot and a single LV for rootfs (I was hoping there would be a EFI paritition, and a PV partition with boot and root LVs [giving ample space for new kernel upgrade/build]but that did not happen). EDIT: And I just read your comments and it makes sense - FAT32 cannot symlink hence the issue... In any case I just realized that since I built a custom kernel (with custom kernel parameters) I cannot apt upgrade it but need to do a kernel-only build on my amd64 host and copy it over... but anyways I hope my stupidity helped improve Armbian by just a bit ... Cheers and Thanks!

UEFISIZE=512 did not do it. At this point I am now stuck... Every apt upgrade one does on a system from Armbian Build environment is going fail requiring manual intervention ... Unless I move to an LVM based build ... trying that now ...

Hello, I noticed this during my previous build as well. I just built a new Armbian image for my rock-5-itx and booted it after installing to emmc. I used the following build commands However the built image has only a 256MB partition. The net result was that the very first apt upgrade failed to build and install the new kernel... The pristine image when booted first time has only 66MB free out of the 256MB while in the midst of the upgrade likely because apt upgrade is doing write of bak file before delete.. /boot after the failed upgrade (output is from 2nd manual run of update-initramfs): How can I get the BOOTSIZE=512 parameter to work with compile.sh? I reviewed the Armbian build documentation in its entirety before this build and nothing caught my eye about any potential gotchas that might cause this parameter to fail. Lastly I think a default of 256M is too miserly. Besides requesting the quick cmdline/config fix for the build, I hope the Armbian build developers will take note and bump the default to 512... EDIT: I forget the crucial but minor details - there is no boot partition when I build for UEFI. so the /boot and EFI is a combined 256GB FAT32. So either I set UEFISIZE to 512... Or how to force seperate EFI/Boot/RootFS? Looks like BOOTPART_REQUIRED=yes and BOOTSIZE=512 are only honored when LVM is selected for build? PS: Trying a build with UEFISIZE=512 now ... Thanks

Ok I need bootpart separate because I will be encrypting my emmc rootfs and all disks on my NAS system. "I do not know if BOOTPART_REQUIRED=yes implies FAT32 formatted and tagged type ESP (0xEF00)." - Yes it does that. The BOOTFS_TYPE=ext4 also works (but my current sdcard image boot is fat32) and both options create a combo Boot+EFI partition with EXT4 and not a separate EFI(FAT32), /boot(EXT4) and / partition - I suppose the Armbian version can read EFI from ext4 as they would not support it otherwise. "The DTB included in EDK2 UEFI v1.1 is kernel 6.10 based AFAIR, that is good enough for all-round Linux" - I was wondering about the difference between the regular dtb and full-dtb - its on my research items list after I am done booting an encrypted rootfs from emmc tomorrow. Cheers!

Thanks for your suggestions so far. I built an image using the following parameters (see end of post) and now it boots pure uefi: This seems to have created an sdcard image without the u-boot after dd command, because now I got a grub menu and still booted the old EMMC system but without the system finding any traces of u-boot to kick-in. Not sure about =uefi-arm64 as it seems to be too generic: vs rock-5-itx seems more accurate: https://github.com/armbian/build/blob/main/config/boards/rock-5-itx.conf I used the following in my compile command : This is a sample command that worked for me. Now I am running from sdcard with a pure uefi boot using my custom Armbian build.

Thanks. So if I switch to BOARD=uefi-arm64 then the armbian build will create an image without the u-boot components and it will boot purely in uefi mode? My doubts are around what happens in the pre-boot stage before the kernel itself loads - uefi needs to read the EFI partition and present the grub menu - so how does the custom image stop this process? What do I need to do so that entire boot chain is limited to EDK2/UEFI from the pre-boot stage itself?

Hello I flashed EDK2 to SPI and I am able to enter the UEFI menu and change things, but it seems that u-boot takes over the boot process to actually boot the kernel. I also built a custom resolute image using the command below which I flashed to SDCard: Then I added a Grub entry for the SDCard image with this custom build but when I boot it it shows that u-boot is being used not UEFI. The default Grub boot is from emmc with an EFI FAT32, /boot EXT4, and / F2FS which is armbian trixie, and it works well - but with u-boot so I am trying to test how booting via pure UEFI will work so I can migrate to a pure UEFI setup on EMMC as the default - but the custom image is not preventing u-boot from taking over the boot sequence. I am not sure I need to flash something to emmc first to prevent u-boot because u-boot takes over before grub and then the custom image starts to boot. Q: What do I need to do to switch to a pure UEFI boot sequence?

Hello Everytime I reboot I have to wait many minutes before the NIC auto-negotiates and connects. The problem seems to be at the PHY layer as the LED does not light up at all ... see time span between 23:22:20 and 23:23:52 : Why is this happening? Only enP3p49s0 is plugged in and NetworkManager-wait-online.service is disabled. Thanks

Hello I built the core minimal image successfully a few times while I was experimenting with kernel config options and then finally when I enabled all the settings I wanted somehow a different component of the build process started failing repeatedly since last few days: Why is this happening. All I did was edit linux-rockchip-rk3588-edge.config and symlink linux-rockchip-rk3588-current.config -> linux-rockchip-rk3588-edge.config

On my Rock5 ITX I am currently manually setting fan speed using commands like : ``` echo 32 | tee /sys/devices/platform/pwm-fan/hwmon/hwmon12/pwm1 ``` bump numbers to 64/128/256 for higher speeds. Change the hwmon/hwmon* number to match what your OS uses ... Sometimes the machine boots with 100% fan speed that does now slow down after full boot and I have to manually set it like this. At other times it boots up normally with low fan speed. Not sure why Armbian does not use sensors by default to scale fan speeds automatically based upon temperature. But later this week I will add the script before I start applying more load/apps to my system.