Since I ran into trouble running the arm-image-installer on my Aurora-dx laptop,
I decided to try burning a boot disk with the .raw image to a micro SD card and use that card to boot my pi 3B.
Following the instructions in the Fedora docs
After resizing the partition, I get:
(parted) print free
Model: (file)
Disk /var/home/blaisep/mmcblk0p1: 7516MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
32.3kB 1049kB 1016kB Free Space
1 1049kB 630MB 629MB primary fat32 boot
2 630MB 7516MB 6886MB primary xfs
7516MB 7516MB 193kB Free Space
But then the next step says:
Resize the LVM physical volume so it takes up all the available space. For this to work you must deactivate any logical volumes within.
and I get the error:
sudo pvresize /dev/mmcblk0p1
Failed to find physical volume "/dev/mmcblk0p1".
0 physical volume(s) resized or updated / 0 physical volume(s) not resized
I wonder if I’m supposed to do something with LVM before I extract the image onto the card ? Sorry, I don’t use LVM often enough to navigate partitions, physical and logical volumes.
I’m willing to write a PR for the docs if someone can tell me what I should do differently.
When you do, did you follow these instructions in the docs you linked?
“Resizing the main partition of the microSD card after setup (if required)
Follow these steps to resize the partitions for Fedora ARM on Raspberry Pi:”
Enlarge the 4th partition (this example uses mmcblk0).
$ growpart /dev/mmcblk0p4
Resize root partition for the server image (which uses xfs).
$ xfs_growfs -d /
My original description was incomplete. This one is better…
My first attempt was to use fedora arm installer . That didn’t work because, Aurora-DX
Next attempt was to use the general method for Linux users that is where I ran into the problem I described (incompletely) in the OP. That failed because, maybe, dd did not overwrite other partitions (?!)
I gave up on using Fedora to burn a bootable image to SD.
Instead, I used OS X running the raspi imager tool and the Fedora Server aarch64 raw downloaded from fedora.org.
I boot Fedora 41 on the raspi 3B and go through the old school Anaconda installer.
Reboot and login as root.
Problem:
growpart /dev/mmcblk0p4
... must supply partition number
but if I try growpart /dev/mmcblk0 4 it returns with failed to get start and end for /dev/mmcblk04 in /dev/mmcblk0
Trying several permutations of blk0p4 fail with various errors.
Using parted print free, I see that I have
1 partition (primary fat32 34.4GB size).
29.7GB Free Space
I suspect that the raspi imager creates different partition table than the fedora imager, and I don’t see any partitions with xfs.
So I might try using the raspi-imager on OS X to burn a NetInstall image onto the SD, boot the Pi and run the GUI installer/Blivet whatever.
I left a note on the Universal Blue discourse to warn them that the fedora arm builder doesn’t work on Aurora (because rpm-ostree install ... )
Again, I appreciate your quick response and I hope to make it all the way to the end this time.
sudo pvresize /dev/mmcblk0
Failed to find physical volume "/dev/mmcblk0".
0 physical volume(s) resized or updated / 0 physical volume(s) not resized
Anyway I will boot it and proceed because I have other storage available and this feels like premature optimization.
So the instructions are brittle in the storage management stage. It feels like the simplest approach is probably to use the fedora-arm-imager on a proper Fedora workstation instead of Atomic desktop.
TL;DR: use the arm-imager if you can. Yes, it’s complicated, but the alternatives are much worse and the instructions only work for a particular set of conditions.