Jump to content

Partition table on Orange Pi 5


Recommended Posts

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. ❤️

Link to comment
Share on other sites

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"

Link to comment
Share on other sites

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 by bedna
Link to comment
Share on other sites

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 by bolet75
Link to comment
Share on other sites

Posted (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 by bedna
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines