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?
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>.
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.
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.
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.
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.