October 21Oct 21 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 Quote BOOTPART_REQUIRED=yes BOOTSIZE=512 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... Quote update-initramfs: Generating /boot/initrd.img-7.2.8-edge-rockchip64 gzip: stdout: No space left on device Errors were encountered while processing: linux-image-edge-rockchip64 initramfs-tools Error: Sub-process /usr/bin/dpkg returned an error code (1) 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): Quote /boot = 256M Used = 191M Avail = 66M Building cpio /boot/initrd.img-7.2.8-edge-rockchip64.new initramfs gzip: stdout: No space left on device E: mkinitramfs failure cpio 141 E: mkinitramfs failure gzip 1 Removing /boot/initrd.img-7.2.8-edge-rockchip64.dpkg-bak update-initramfs: failed for /boot/initrd.img-7.2.8-edge-rockchip64 with 1. 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 Edited October 21Oct 21 by Raul
October 21Oct 21 Author UEFISIZE=512 did not do it. At this point I am now stuck... Quote Device Start End Sectors Size Type Armbian-unofficial_26.08.0-trunk_Rock-5-itx_trixie_edge_7.1.13-edk2-crypt.img1 32768 565247 532480 260M EFI System Armbian-unofficial_26.08.0-trunk_Rock-5-itx_trixie_edge_7.1.13-edk2-crypt.img2 565248 7051263 6486016 3.1G Linux root (ARM-64) Armbian-unofficial_26.08.0-trunk_Rock-5-itx_trixie_edge_7.1.13-edk2-crypt.img3 2048 18431 16384 8M Linux filesystem 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 ... Edited October 21Oct 21 by Raul
October 21Oct 21 Author 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 Quote declare -g UEFISIZE=512 and the resulting build gave me: Quote Device Start End Sectors Size Type Armbian-*_26.11.0-trunk_Rock-5-itx_trixie_current_6.18.58-edk2-crypt.img1 32768 1081343 1048576 512M EFI System Armbian-*_26.11.0-trunk_Rock-5-itx_trixie_current_6.18.58-edk2-crypt.img2 1081344 7698431 6617088 3.2G Linux root (ARM-64) Armbian-*_26.11.0-trunk_Rock-5-itx_trixie_current_6.18.58-edk2-crypt.img3 2048 18431 16384 8M Linux filesystem 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! Edited October 21Oct 21 by Raul added info
October 22Oct 22 Solution 9 hours ago, Raul said: But tell me the exact git command cd build git fetch origin pull/11072/head:pr-11072 git checkout pr-11072 ./compile.sh build BOARD=rock-5-itx BRANCH=vendor ... UEFISIZE=512 Perhaps just do a quick test to confirm even I am pretty confided it should work now. 9 hours ago, Raul said: but anyways I hope my stupidity helped improve Armbian by just a bit ... Yes, it revealed a bug. Thank you.
October 22Oct 22 Author It works. (I ran a git checkout -f pr-11072 to force overwriting my earlier local changes first). Quote fdisk -l Armbian-unofficial_26.11.0-trunk_Rock-5-itx_trixie_current_6.18.58-edk2-crypt.img Disk Armbian-unofficial_26.11.0-trunk_Rock-5-itx_trixie_current_6.18.58-edk2-crypt.img: 3.67 GiB, 3942645760 bytes, 7700480 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 153DD8B0-FB58-47EC-A833-C627B11DB54C Device Start End Sectors Size Type Armbian-unofficial_26.11.0-trunk_Rock-5-itx_trixie_current_6.18.58-edk2-crypt.img1 32768 1081343 1048576 512M EFI System Armbian-unofficial_26.11.0-trunk_Rock-5-itx_trixie_current_6.18.58-edk2-crypt.img2 1081344 7698431 6617088 3.2G Linux root (ARM-64) Armbian-unofficial_26.11.0-trunk_Rock-5-itx_trixie_current_6.18.58-edk2-crypt.img3 2048 18431 16384 8M Linux filesystem 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. Quote BOOTPART_REQUIRED=yes BOOTSIZE=512 BOOTFS_TYPE=ext4 UEFISIZE=512 I was hoping this was the switch to do it - BOOTFS_TYPE=ext4 combined with BOOTPART_REQUIRED but it does nothing. Thanks Edited October 22Oct 22 by Raul
October 22Oct 22 Thank you for testing. 1 hour ago, Raul said: I hope you can quickly answer? Sadly nothing is quickly anymore. I don't know. -> docs.armbian.com and AI will be best path.
October 22Oct 22 Author I was able to get it work by changing this around line#47 of extension/grub.sh Quote # declare -g BOOTSIZE=0 declare -g BOOTSIZE="${BOOTSIZE:-0}" and then setting the following params in the compile config: Quote BOOTPART_REQUIRED=no BOOTSIZE=512 BOOTFS_TYPE=ext4 UEFISIZE=512 The build almost finished completely with: Quote [🐳|🌱] Creating partitions [ /boot: ext4 root: ext4 ] [🐳|🔨] Checking that no-one is using this disk right now ... OK [🐳|🔨] [🐳|🔨] Disk /armbian/.tmp/rootfs-45f1fda5-e6c3-4006-9a33-169984be39f2.raw: 4.32 GiB, 4638900224 bytes, 9060352 sectors [🐳|🔨] Units: sectors of 1 * 512 = 512 bytes [🐳|🔨] Sector size (logical/physical): 512 bytes / 512 bytes [🐳|🔨] I/O size (minimum/optimal): 512 bytes / 512 bytes [🐳|🔨] [🐳|🔨] >>> Script header accepted. [🐳|🔨] >>> Created a new GPT disklabel (GUID: 068D5EA5-7DD9-48E0-9720-9ED188005160). [🐳|🔨] /armbian/.tmp/rootfs-45f1fda5-e6c3-4006-9a33-169984be39f2.raw1: Created a new partition 1 of type 'EFI System' and of size 512 MiB. [🐳|🔨] /armbian/.tmp/rootfs-45f1fda5-e6c3-4006-9a33-169984be39f2.raw2: Created a new partition 2 of type 'Linux extended boot' and of size 512 MiB. [🐳|🔨] /armbian/.tmp/rootfs-45f1fda5-e6c3-4006-9a33-169984be39f2.raw3: Created a new partition 3 of type 'Linux root (ARM-64)' and of size 3.3 GiB. [🐳|🔨] /armbian/.tmp/rootfs-45f1fda5-e6c3-4006-9a33-169984be39f2.raw4: Done. [🐳|🔨] [🐳|🔨] New situation: [🐳|🔨] Disklabel type: gpt [🐳|🔨] Disk identifier: 068D5EA5-7DD9-48E0-9720-9ED188005160 [🐳|🔨] [🐳|🔨] Device Start End Sectors Size Type [🐳|🔨] /armbian/.tmp/rootfs-45f1fda5-e6c3-4006-9a33-169984be39f2.raw1 32768 1081343 1048576 512M EFI System [🐳|🔨] /armbian/.tmp/rootfs-45f1fda5-e6c3-4006-9a33-169984be39f2.raw2 1081344 2129919 1048576 512M Linux extended boot [🐳|🔨] /armbian/.tmp/rootfs-45f1fda5-e6c3-4006-9a33-169984be39f2.raw3 2129920 9058303 6928384 3.3G Linux root (ARM-64) [🐳|🔨] [🐳|🔨] The partition table has been altered. Then unfortunately I ran into a github token expiry situation: Quote [🐳|🌱] Finding edk2 latest version [ from GitHub ] [🐳|💥] Failed to fetch the latest release of edk2-porting/edk2-rk3588 [ curl: (22) The requested URL returned error: 403 (unauthenticated - 60 requests/hour per IP) ] [🐳|💥] Error 1 occurred in main shell [ at /armbian/.tmp/extensions-45f1fda5-e6c3-4006-9a33-169984be39f2/extension_function_definition.sh:588 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? Edited October 22Oct 22 by Raul
October 22Oct 22 Author 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!
October 23Oct 23 First fix was already merged. Try with this one: https://github.com/armbian/build/pull/11084 12 hours ago, Raul said: Then unfortunately I ran into a github token expiry situation: This is a temporally problem - like error says: 60 requests/hour per IP. Authentication to GitHub helps: GITHUB_TOKEN=$(gh auth token) ./compile.sh build ...
October 23Oct 23 Author Thanks for the effort! I ran Quote git fetch origin pull/11072/head:pr-11084 git checkout pr-11084 and built the image. This works to create 3 partitions: Quote Device Start End Sectors Size Type Armbian-unofficial_26.11.0-trunk_Rock-5-itx_trixie_current_6.18.58-edk2-crypt.img1 32768 557055 524288 256M EFI System Armbian-unofficial_26.11.0-trunk_Rock-5-itx_trixie_current_6.18.58-edk2-crypt.img2 557056 1605631 1048576 512M Linux extended boot Armbian-unofficial_26.11.0-trunk_Rock-5-itx_trixie_current_6.18.58-edk2-crypt.img3 1605632 8378367 6772736 3.2G Linux root (ARM-64) Armbian-unofficial_26.11.0-trunk_Rock-5-itx_trixie_current_6.18.58-edk2-crypt.img4 2048 18431 16384 8M Linux filesystem (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. Quote /mnt$ ls -l img-boot/ total 16 drwx------ 2 root root 16384 Oct 23 19:48 lost+found /mnt$ ls -l img-efi/ total 125303 drwxr-xr-x 3 root root 512 Oct 23 19:50 EFI -rwxr-xr-x 1 root root 44235264 Oct 22 00:29 Image -rwxr-xr-x 1 root root 7025758 Oct 22 00:29 System.map-6.18.58-current-rockchip64 -rwxr-xr-x 1 root root 193953 Oct 23 19:50 armbian-dtb-6.18.58-current-rockchip64 -rwxr-xr-x 1 root root 245 Oct 23 19:48 armbianEnv.txt -rwxr-xr-x 1 root root 38518 Oct 23 19:48 boot.bmp -rwxr-xr-x 1 root root 3834 Aug 15 14:32 boot.cmd -rwxr-xr-x 1 root root 3906 Oct 23 19:48 boot.scr -rwxr-xr-x 1 root root 271104 Oct 22 00:29 config-6.18.58-current-rockchip64 drwxr-xr-x 5 root root 1024 Oct 23 19:51 grub -rwxr-xr-x 1 root root 32302307 Oct 23 19:50 initrd.img-6.18.58-current-rockchip64 -rwxr-xr-x 1 root root 44235264 Oct 22 00:29 vmlinuz-6.18.58-current-rockchip64 Let me know if you plan to fix this because the grub.sh code seems to have been designed and written around that assumption: Quote if [[ $BOOTPART_REQUIRED == "yes" ]]; then # It is important to place this into /boot to have unified boot partition, especially when CRYPTROOT is used declare -g UEFI_MOUNT_POINT=/boot ...<snip>... "grub-install --target=${UEFI_GRUB_TARGET} --efi-directory=${UEFI_MOUNT_POINT} I checked this in a hurry and not sure if simply changing the code to this will work: Quote declare -g UEFI_MOUNT_POINT=/boot/efi 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! Edited October 23Oct 23 by Raul
October 23Oct 23 Your fetch pulled PR #11072, not #11084: pull/11072/head:pr-11084. #11072 still mounts EFI at /boot. That is why the kernel files are on p1. Revert your local grub.sh edit and run: git fetch origin pull/11084/head:pr-11084 git checkout pr-11084 ./compile.sh build BOARD=rock-5-itx ... ENABLE_EXTENSIONS=uefi-edk2-rk3588 BOOTFS_TYPE=ext4 BOOTSIZE=512 UEFISIZE=256 Expected result: kernel, initrd and grub/ on p2 (/boot), EFI on p1 at /boot/efi. Please report if it boots. I tested the image layout, not a boot.
October 24Oct 24 Author Ah My bad! I can confirm that the image boots successfully and the files are correctly populated in /boot and EFI: Quote [Oct24 18:53] Booting Linux on physical CPU 0x0000000000 [0x412fd050] [ +0.000000] Linux version 6.18.58-current-rockchip64 (build@armbian) (aarch64-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #8 SMP Wed Oct 21 08:32:29 UTC 2026 [ +0.000000] Machine model: Radxa ROCK 5 ITX [ +0.000000] earlycon: uart8250 at MMIO32 0x00000000feb50000 (options '') [ +0.000000] printk: legacy bootconsole [uart8250] enabled [ +0.000000] efi: EFI v2.7 by EDK II [ +0.000000] efi: SMBIOS=0xefe80000 SMBIOS 3.0=0xefe60000 MEMATTR=0xedd9b018 ACPI 2.0=0xeed8c018 INITRD=0xedd82e98 RNG=0xeed8ce18 MEMRESERVE=0xedd82d18 [ +0.000000] random: crng init done ... rock-5-itx:~:# lsblk -oname,mountpoint,size,fstype,fsused,fsavail NAME MOUNTPOINT SIZE FSTYPE FSUSED FSAVAIL mmcblk0 7.3G ├─mmcblk0p1 /boot/efi 256M vfat 149.5K 251.9M ├─mmcblk0p2 /boot 512M ext4 93.1M 373.7M ├─mmcblk0p3 6.4G crypto_LUKS │ └─armbian-root / 6.3G ext4 2.5G 3.5G ... rock-5-itx:~:# ls -l /boot/efi/EFI/BOOT total 148 -rwxr-xr-x 1 root root 151552 Oct 24 18:27 BOOTAA64.EFI rock-5-itx:~:# ls -l /boot total 82089 -rw-r--r-- 1 root root 193953 Oct 24 18:27 armbian-dtb-6.18.58-current-rockchip64 -rw-rw-r-- 1 root root 294 Oct 24 18:16 armbianEnv.txt -rw-rw-r-- 1 root root 38518 Oct 24 18:23 boot.bmp -rw-rw-r-- 1 raul raul 3834 Aug 15 14:32 boot.cmd -rw-rw-r-- 1 root root 3906 Oct 24 18:24 boot.scr -rw-r--r-- 1 root root 271104 Oct 24 17:59 config-6.18.58-current-rockchip64 drwxr-xr-x 3 root root 512 Jan 1 1970 efi drwxr-xr-x 5 root root 4096 Oct 24 18:27 grub lrwxrwxrwx 1 root root 34 Oct 24 18:17 Image -> vmlinuz-6.18.58-current-rockchip64 -rw-r--r-- 1 root root 32313583 Oct 24 18:27 initrd.img-6.18.58-current-rockchip64 drwx------ 2 root root 16384 Oct 24 18:24 lost+found -rw-r--r-- 1 root root 7022770 Oct 24 17:59 System.map-6.18.58-current-rockchip64 -rw-r--r-- 1 root root 44169728 Oct 24 17:59 vmlinuz-6.18.58-current-rockchip64 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! Edited October 24Oct 24 by Raul
October 25Oct 25 Question to @Igor Will this be the "default" build going forward for armbian or is this something that is only achieved through extra configs during build? (BOOTFS_TYPE=ext4 BOOTSIZE=512 UEFISIZE=256) This does not look "traditional" to me, isn't traditional two partitions? Traditional to me is efi in either /boot/efi or /efi and /boot directory located on root partition. I ask because this is not going to work with the backup-script (shrink-backup) I maintain that has "support" for armbian, so if this is going to be standard, I need to rethink things. I have never seen this setup on anything, be it sbc, desktop or server. Edited October 25Oct 25 by bedna
October 25Oct 25 11 hours ago, bedna said: Will this be the "default" build going forward for armbian No worries. Nothing changes by default. The separate ext4 /boot with EFI at /boot/efi only happens if you build with BOOTFS_TYPE=ext4 BOOTSIZE=XXX yourself. It's for people who need a bigger /boot for initramfs. Standard UEFI/GRUB images keep the usual layout: EFI at /boot/efi, and /boot on the root filesystem. No board config turns this on, so your shrink-backup script won't come across it in official images. It might still be worth supporting later, since a three-partition layout (EFI + /boot + root) is what Debian and Ubuntu installers create with LVM or encryption.
October 26Oct 26 13 hours ago, Igor said: It might still be worth supporting later, since a three-partition layout (EFI + /boot + root) is what Debian and Ubuntu installers create with LVM or encryption. Thank you. Well if it's encrypted it won't be supported anyway since the backup img would not be encrypted, so it kinda beats the purpose of encryption, and the image also very likely won't boot anyway.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.