Is it possible to set the boot flag on a partition?

[crschardt]

I am using arm-runner-action to create a modified image based on the OrangePi5 Ubuntu Server image from Joshua Riek. Using the script below, I created a new image, but the image won't boot on my OrangePi. I did some digging and found that the root partition (partition 2) on the base image is marked bootable, but after modifying the image. it is no longer marked bootable. I can fix the problem by using parted to mark the partition bootable.

Is there some some way to accomplish this as part of the workflow?

Additional detail

Since version 2.0.0 the Ubuntu Server images from Joshua Riek include two partitions, which are described as:

Ubuntu Server now uses a small 4MB partition named CIDATA for cloud-init configuration and the root partition has been renamed to cloudimg-rootfs and marked as a bootable EFI partition.

In order to boot correctly, the second partition must be marked with the boot flag.

Here is the output from sudo parted print on the base image and the modified image:

Base image (after first boot)

Number  Start   End     Size    File system  Name     Flags
 1      16.8MB  21.0MB  4194kB  fat32        primary  msftdata
 2      21.0MB  31.0GB  31.0GB  ext4         primary  boot, esp

Modified image (won't boot)

Number  Start   End     Size    File system  Name     Flags
 1      16.8MB  21.0MB  4194kB  fat32        primary  msftdata
 2      21.0MB  3240MB  3219MB  ext4         primary

Using parted I added the boot flag to partition 2 of the modified image (parted) set 2 boot on and this made the modified image bootable.

Workflow

name: Build driver
on:
  push:
    branches: [ master ]
  pull_request:
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - uses: pguyot/arm-runner-action@v2.6.5
      id: install_deps
      with:
        base_image: https://github.com/Joshua-Riek/ubuntu-rockchip/releases/download/v2.2.1/ubuntu-24.04-preinstalled-server-arm64-orangepi-5.img.xz

    - name: Compress built image
      run: |
        mv ${{ steps.install_deps.outputs.image }} testimage.img
        sudo xz -T 0 -v testimage.img

    - uses: actions/upload-artifact@v4.3.3
      with:
        name: testimage.img.xz
        path: testimage.img.xz
        if-no-files-found: error
        retention-days: 1

[crschardt]

I did more investigation and discovered that the problem occurred because cleanup_image.sh removes and then makes a new image when optimizing the image. This removes the boot flag from that partition causing the image to fail to boot. A secondary problem is that the resize doesn't leave enough space for the backup GPT partition table after the last partition.

The first problem can be fixed by replacing the rm and mkpart with:

echo y | sudo parted ---pretend-input-tty "${loopdev}" unit B resizepart "${rootfs_partnum}" "${rootfs_partend}"

which causes parted to resize the partition without destroying the partition information.

The second problem can be fixed by adding space for the backup partition table before truncating the image file and then fixing the backup partition table.

I'll submit a PR with these fixes for your consideration.

[pguyot]

Thank you for the investigation and the PR.