Armbian uses U-boot, and I have never seen any boot partition on them.
Isn't the whole idea with U-boot that you use MBR and U-boot puts the bootloader on the device BEFORE the partition?
IE the the "start" (seen with for example "sudo fdisk -l /dev/xxx") of the partition will be moved to leave space for the boot stuff needed, then mounts root and looks for the init stuff in /boot.
Example of an orangepi PC2 running armbian ("fork" of rpiOS) with U-boot:Do not ask me why Bookworm suddenly ALSO moved the start of the partition to 8192 (8192 x 512 = 4194304 bytes), that has never been the case before. I actually asked here on the forum but got no answer. But it also does not matter, but I find it strange anyway.
But Bullseye: Start=2048 (2048 x 512 = 1048576 bytes)
Keep in mind these are in 512 byte blocks.
Anyway, that is how I think U-boot works.
As a side note, this is very important to know if you want to back up the device.
You HAVE to dd the fist couple of blocks to cover the "start" part of the device, or it will never boot without you somehow reinstalling U-boot on the device again.
Isn't the whole idea with U-boot that you use MBR and U-boot puts the bootloader on the device BEFORE the partition?
IE the the "start" (seen with for example "sudo fdisk -l /dev/xxx") of the partition will be moved to leave space for the boot stuff needed, then mounts root and looks for the init stuff in /boot.
Example of an orangepi PC2 running armbian ("fork" of rpiOS) with U-boot:
Code:
$ sudo fdisk -l /dev/mmcblk0[sudo] password for bedna: Disk /dev/mmcblk0: 14.56 GiB, 15634268160 bytes, 30535680 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: dosDisk identifier: 0x76b6d9d6Device Boot Start End Sectors Size Id Type/dev/mmcblk0p1 8192 30212096 30203905 14.4G 83 Linux$ ls -l /boottotal 59356-rw-r--r-- 1 root root 203 Feb 22 10:05 armbianEnv.txt-rw-r--r-- 1 root root 1536 Sep 24 2022 armbian_first_run.txt.template-rw-r--r-- 1 root root 230454 Sep 24 2022 boot.bmp-rw-r--r-- 1 root root 3187 Sep 24 2022 boot.cmd-rw-rw-r-- 1 root root 3259 Sep 24 2022 boot.scr-rw-r--r-- 1 root root 208722 Nov 27 12:29 config-6.1.63-current-sunxi64lrwxrwxrwx 1 root root 26 Dec 5 20:12 dtb -> dtb-6.1.63-current-sunxi64drwxr-xr-x 3 root root 4096 Dec 5 20:10 dtb-6.1.63-current-sunxi64lrwxrwxrwx 1 root root 30 Dec 5 20:12 Image -> vmlinuz-6.1.63-current-sunxi64-rw-r--r-- 1 root root 17150064 Dec 5 20:13 initrd.img-6.1.63-current-sunxi64-rw-r--r-- 1 root root 3479642 Nov 27 12:29 System.map-6.1.63-current-sunxi64lrwxrwxrwx 1 root root 30 Dec 5 20:13 uInitrd -> uInitrd-6.1.63-current-sunxi64-rw-r--r-- 1 root root 17150128 Dec 5 20:13 uInitrd-6.1.63-current-sunxi64-rw-r--r-- 1 root root 22525960 Nov 27 12:29 vmlinuz-6.1.63-current-sunxi64But Bullseye: Start=2048 (2048 x 512 = 1048576 bytes)
Keep in mind these are in 512 byte blocks.
Anyway, that is how I think U-boot works.
As a side note, this is very important to know if you want to back up the device.
You HAVE to dd the fist couple of blocks to cover the "start" part of the device, or it will never boot without you somehow reinstalling U-boot on the device again.
Statistics: Posted by bedna — Wed May 08, 2024 5:25 am