ARM image in GPT format instead of MBR?

I followed the instruction here to write the Fedora ARM64 image to an SD card. Afterwards the partitioning is shown as MBR. I also flashed an Android image using gnome-disk-utility before and it also ended up being MBR.
I assume it’s because those disk images are partitioned in MBR?
If so, is there a GPT image, or some way to convert the fully written card to GPT?

Extra question:
Is every step in the instruction needed? I’m not clear on the purpose of each command and haven’t followed it through, but one says resize XFS when there is no XFS partition only Btrfs?

(parted) resizepart <partition_number> <target_size> seems incorrect (Fedora 38). It shrunk my partition… The 2nd parameter should be <target_end>.
man parted:

          resizepart partition end
                 Change the end position of partition.  Note that this does not modify any filesystem present in the partition.

Perhaps the commands are for Fedora Server, Fedora Workstation is not using LVM but Btrfs.

Which image did you download. There are two choices.

The armhfp image is a 32 bit system. The aarch64 image is (as is implied) a 64 bit system and mostly preferred.

# arm-image-installer --image=</path/to/fedora_image> --target=<RPi_Version> --media=/dev/<sd_card_device> --resizefs

Yes, all the options shown on that command line on the linked page are required.
--image is the source, --media is the destination, --resizefs enlarges the file system after install to fill the card and allow full use of space available, and --target tells the installer which board is being used and thus which boot loader to use.

If you use fedora (you indicated fedora 38) then the arm-image-installer method for fedora is best. Instructions in the following sections are not applicable when using the arm-image-installer.

If you are on a different OS it would help to know which OS so we could follow the proper section that is applicable to the one you are using.

It is really immaterial whether the device is GPT or MBR formatted since most arm boards do not use uefi anyway, and few users need enough partitions on an SBC board to ever exceed the limits of MBR formatted partition tables. It seems MBR is the default for SD cards.
Using arm-image-installer gives all the options available and a brief description.

Other methods give different results and procedures. Note that one could even use a live fedora image to download the image and follow the steps to install the image with the arm-image-installer

Thanks for the reply. However I was trying to learn to flash images manually instead of using the tools. Thus I was following the generic Linux instructions. But now after reading a bunch about LVM, I think the particular instructions are outdated for some reason.
For starters, none of the partitions (from neither my Fedora workstation nor the image flashed to SD card) are related to LVM. sudo pvs shows nothing, while sudo pvs -a lists all my partitions, suggesting they are not PVs. Thus none of the commands apply.
I think, from this (old) news, Fedora is no longer using LVM?

Fedora has LVM available and supports it, but since about the time fedora 33 (or maybe 34) was released the default file system for new installs has been btrfs. LVM is very robust and stable, but since fedora is a leading edge test bed for development they push the changes as technology and software advances.

I am old school and have used LVM for most of the time since the early 2000s, so will continue to do so. Many newer users have never seen LVM and may have no clue about using it.

Remember that ‘generic’ linux instructions may be aimed at helping those who are using debian or ubuntu users transition to the fedora world and commands may be couched in a format that does not properly work in fedora. Not all commands are universal between distros.

It is mostly standard that arm based systems do not normally install using LVM, though they can usually access external LVM file systems once installed and running.

The farthest I got is installing from aarch64 ISO using pftf UEFI, the resulting partitions are GPT.
However neither u-boot (copied from the aarch64 image) nor UEFI with DT enabled work. Only boots until basic system. u-boot boots grub but starting from there the displayed characters are corrupted.
EDIT: Actually they seem to end up at the same problem, unable to find the Btrfs partition by UUID.
UEFI with ACPI only boots to OS, but v3d doesn’t work. Also the system goes to sleep and never wakes up (I think this one is normal for ARM, yet to see how the pre-made image handles that).

Note that the RPi apparently does not boot from usb if there is an SD card installed. One would likely need to boot from one usb device and install to another usb device when using the iso. (I have never tried installing from the ISO)

I also do not think UEFI is appropriate since that depends upon a bios that supports UEFI and AFAIK the RPi does not (which also could explain the MBR vs GPT issue).

Just found that what I did was the same as this, though the difference is that I was trying to install Workstation instead of CoreOS (and pi400 instead of pi4).
Not sure why everything doesn’t work, and I can’t find any useful info.

Got it to work by overwriting the initramfs with the one from aarch64 img. Actually booted into Fedora and have V3D 4.2. This is using U-Boot, now to test UEFI.

Update1: pftf UEFI in DT/ACPI+DT mode only works (has V3D) with the firmware files from the aarch64 img, which are from the commits around March. Now to test U-Boot with master.

Update2: U-Boot works with master branch firmware for booting into local install.

Update3: Both UEFI and U-Boot black-screens & become unresponsive when booting live USB with master base rpi-400 dtb, at the point where the screen becomes native resolution & color range.

  1. Make a normal live USB from AArch64 ISO.
  2. pftf UEFI. Replace bcm2711-rpi-400.dtb with an earlier version. Last bootable eb18fe0. Replace RPI_EFI.fd with the one from v1.34.
    • Not U-Boot: “failed to set new efi boot target” during Grub install.
    • v1.35 has problem.
    • Latest base DTB doesn’t work for some reason.
    • Pre-compiled firmware (the UEFI already contains the latest at the time of release).
  3. Set the UEFI to “ACPI + Devicetree” before booting the live USB.
    • If installed under ACPI, no V3D hardware acceleration (only available with Devicetree), and the initramfs is insufficient for booting under Devicetree.
  4. Install as normal.
    • Good to first check that the live OS is running in Wayland with V3D in Settings - About.
  5. Put the UEFI and the firmware back into ESP partition.
    • Could probably swap UEFI for U-Boot at this point, haven’t tried.
    • The UEFI settings are saved within the .fd file, so if erased during install, reconfigure the UEFI again. (Disable 3GB limit, ACPI + Devicetree)
  6. Unplug any USB peripheral before booting the installed OS.
    • Else booting could get stuck (seems to be Devicetree problem). Not sure if necessary.

Fedora Workstation is not using LVM and XFS but Btrfs, Fedora Server is.
The commands in the doc apply to Server not Workstation. It’s not quite clear on that based on what it says in the prerequisite, but I guess it should be obvious, if I knew about those file systems.