bedna Posted January 25 Share Posted January 25 I got an issue from a user on a bash script I am sharing on github. The script is to make shrunk img backups on a running system on a lot of different sbc:s. After some testing on the users side (I did not have access to hardware to test) it turned out the script fails because of the partition table, it is GPT while in the past they have always been MBR (msdos). I downloaded the latest opi5 gnome desktop image and looped it and parted shows it is in GPT. We figured out a way to solve it but my question is: is this because rpi5 uses gpt partition table (I do not own a rpi5 either)? Will this be the future of most armbian builds? On a side note, `armbian-resize-filesystem.service` still works to autoexpand after I restore a backed up img, so thank you for providing this. ❤️ 0 Quote Link to comment Share on other sites More sharing options...
SteeMan Posted January 25 Share Posted January 25 GPT is something the Armbian build framwork supports, not currently the default, but here is a list of boards that use it: grep -i gpt * armsom-sige7.csc:IMAGE_PARTITION_TABLE="gpt" armsom-w3.csc:IMAGE_PARTITION_TABLE="gpt" bananapir2pro.csc:IMAGE_PARTITION_TABLE="gpt" fxblox-rk1.wip:IMAGE_PARTITION_TABLE="gpt" hinlink-h28k.csc:IMAGE_PARTITION_TABLE="gpt" hinlink-h88k.csc:IMAGE_PARTITION_TABLE="gpt" hinlink-ht2.csc:IMAGE_PARTITION_TABLE="gpt" indiedroid-nova.csc:declare -g IMAGE_PARTITION_TABLE="gpt" jp-tvbox-3566.tvb:IMAGE_PARTITION_TABLE="gpt" khadas-edge2.conf:declare -g IMAGE_PARTITION_TABLE="gpt" mangopi-m28k.csc:IMAGE_PARTITION_TABLE="gpt" mixtile-blade3.wip:declare -g IMAGE_PARTITION_TABLE="gpt" nanopct6.wip:IMAGE_PARTITION_TABLE="gpt" nanopi-r5c.csc:IMAGE_PARTITION_TABLE="gpt" nanopi-r5s.wip:IMAGE_PARTITION_TABLE="gpt" nanopi-r6s.conf:IMAGE_PARTITION_TABLE="gpt" odroidm1.conf:IMAGE_PARTITION_TABLE="gpt" orangepi3b.csc:IMAGE_PARTITION_TABLE="gpt" orangepi5.conf:IMAGE_PARTITION_TABLE="gpt" orangepi5-plus.conf:IMAGE_PARTITION_TABLE="gpt" panther-x2.csc:IMAGE_PARTITION_TABLE="gpt" quartz64a.csc:IMAGE_PARTITION_TABLE="gpt" quartz64b.csc:IMAGE_PARTITION_TABLE="gpt" radxa-e25.wip:IMAGE_PARTITION_TABLE="gpt" rock-3a.conf:IMAGE_PARTITION_TABLE="gpt" rock-5a.wip:IMAGE_PARTITION_TABLE="gpt" rock-5b.conf:IMAGE_PARTITION_TABLE="gpt" rock-5-cmio.csc:IMAGE_PARTITION_TABLE="gpt" station-m2.csc:IMAGE_PARTITION_TABLE="gpt" station-m3.csc:IMAGE_PARTITION_TABLE="gpt" station-p2.csc:IMAGE_PARTITION_TABLE="gpt" xiaomi-elish.conf:IMAGE_PARTITION_TABLE="gpt" 1 Quote Link to comment Share on other sites More sharing options...
bedna Posted January 25 Author Share Posted January 25 (edited) I was wrong about the rpi5 thing, they are still in mbr. Not really important, because it boots, but why is the sector before the boot partition so freakishly large (16,8MB)? Looped img of Armbian 23.11 Jammy-amazingfated GNOME for orangepi 5 $ parted /dev/loop0 print Model: Loopback device (loopback) Disk /dev/loop0: 7315MB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 16,8MB 285MB 268MB fat16 bootfs bls_boot 2 285MB 7315MB 7030MB ext4 rootfs Edited January 25 by bedna 0 Quote Link to comment Share on other sites More sharing options...
bolet75 Posted February 12 Share Posted February 12 (edited) On 1/25/2024 at 10:16 PM, bedna said: Not really important, because it boots, but why is the sector before the boot partition so freakishly large (16,8MB)? Looped img of Armbian 23.11 Jammy-amazingfated GNOME for orangepi 5 Previous images had a smaller gap before partition 1. My guess is that this space is now there to allow a future switch to UEFI boot, which as far as I understood, needs an EFI partition to be 1st on the disk, and it needs that much space. Someone here probably knows better than me. I already tried this new layout, with EFI on partition 1, and "generic arm64" kernel on partition 2. No success yet. Will dig into this again some time soon. Edited February 12 by bolet75 0 Quote Link to comment Share on other sites More sharing options...
bedna Posted March 3 Author Share Posted March 3 (edited) I think it's the other way around (MBR vs GPT). Using grub f.ex, with GPT you can have the boot partition wherever you want, as long as you define it with UUID, but it USUALLY is the first partition. With MBR this is not a choice EVEN if you use uefi, I think you MUST have the partition first (and leave 5MiB or smthn before the partition). Edited March 3 by bedna 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.