Fedora 35 on a Pi4

I downloaded Fedora-Workstation-35-1.2.aarch64.raw.xz and put in on a 128Gb SD with Raspberry Pi Imager and booted a Pi4 with this. No problem so far, Fedora comes up and account initialised OK. But I have a memory problem I can’t solve.

fdisk -l  =>  /dev/mmcblk1 119.08 GB
                   /dev/mmcblk1p3   size 117.5 GB
df          => /dev/mmcblk1p3  (1K blocks)
                  109189012  9093356 uused 1298484 available
                  88% used onb/ and /home
disks    =. partition 1  629 MB FAT
                 partition 2 1.1GB  ext4
                 partition 3 126 GB BTRFS  98.5% full mounted on filesystem Root
growpart /dev/mmcblk1  3    => NOCHANGE partition 3 is size 246409183
                                                        it cannot be grown
 resize2f  /dev/mmcblk1p3   =>  busy could not open /dev/mmcblk1p3
                                                        no superblock

After loading Firefox and Thunderbird i only 440 MB left

SO: somehow the Pi4 is not recognising the full size of the Fedora partion 3
I know the Pi approach of only taking up sufficent space, but within Fedora I acn’t resize using raspi-config.

How do I reclaim all the memory on the SD ?
Any and all help would be appreciated.

Ron

Sorry, looks like the tgitle is wrong Fedora 35 not fedora 35I

Hi Ron,

My guess it that you haven’t “resized” the filesystem correctly. I use arm-image-installer and there you have to use the flag “–resizefs” to let the image creating process know that you want to use the whole disk for the operating system.

I have not used the “Raspberry Pi Imager” but if you read up on how to extend the filesystem during SD-image creation I guess you can solve the problem.

Regards

It looks like your 128GB SD card is already formatted as a btrfs volume and it’s full. Keep in mind that it’s normal to have a little variance between what the storage reports and what the filesystem can actually allocate.

It doesn’t appear to be a situation where btrfs needs to grow but rather something has filled up your sd card already and you need to discover what that could be. It might be useful to start with du -sh /home/* | sort -h.

du -sh /home/* | sort -h reports I’m only using 2.7G of the 120G which
is about what i expect.
BUT thunderbird insists I have only 440 MB left and Disks insists that
partition 3 is 98.5% full.
—TRY AGAIN FROM SCRATCH
problem repeatable:
df: p3 44% p2 13% p1 5%
fdisk: p3 10.4G p2 1G p1 600M
diska p3 11G (41.1% p2 1.1G (16%) p1 629M (5.1%)
FREE SPACE 115G
du -sh /home/* | sort -h reports 15M (effectively empty)
Now I need to expand p3 with growpart and resize2fs
?? Do these sound right ??
growpart /dev/mmcblk0 3
resize2fs /dev/mmcblk0p3
I’ll try tomorrow, subject to any corrections
Thanks to both Scott and Fredrik for suggestions
Ron

growpart /dev/mmcblk0 3 seems to work fine:
CHANGED: partition =3
start=3328000
size=21837824
end=25165824
new:
size=246409183
end=249737183

this looks good, size has grown by a factor of 10 ~ 20 ->200
246409183(size) + 3328000(start) = 249737183(end)
but resize2fs fails:
Device or resource busy while trying to open /dev/mmcblk0p3.
Couldn’t find valid filesystem superblock

du -sh /home/* | sort -h
reports 16MB

Problem seems to lie with resize2fs
I found this in raspberrypi.stackexchange.com
Fedora 35 Server AArch64 Raw Image comes with XFS (Linux File System). XFS compatible with fdisk, parted but issue raised for resize2fs with message Bad magic number in super-block –
Śhāhēēd
Nov 9, 2021 at 16:03
resize2fs is for use with ext2/3/4 filesystems. the equivalent command is xfs_growfs -d /dev/…
Nov 9, 2021 at 16:17
option -d to expand to full extent of disk

I’ll try again from the start

I think the default file system on a Fedora 35 host is btrfs so if you want to try to resize the current filesystem you could use the commands on this page: How to Resize / Expand a Btrfs Volume / Filesystem – The Geek Diary

However, I can’t tell you wheter that will work or not. What will work though is to burn the card with arm-image-installer. If you get tired of troubleshooting the current install and want to do it from scratch you can do as follows:

Find a working Fedora host and install arm-image-installer with “dnf -y install arm-image-installer”.

Then run the “dmesg” command and check out the last 10-15 lines (just to be able to identify the new lines added next). After that you insert your SD-card (or USB-connected SD-card adapter) and run “dmesg” again. Somewhere in the last 10-15 lines you will see something like (your device will probably differ):

… sdc: sdc1 sdc2 sdc3
… sd 3:0:0:1: [sdc] Attached SCSI removable disk

Then you know your SD-card is at /dev/sdc. Go to folder with Fedora-Workstation image and run command:

“sudo arm-image-installer --image=Fedora-Workstation-35-1.2.aarch64.raw.xz --media=/dev/sdc --target=rpi4 --resizefs --showboot”

The “–showboot” flag is optional and just to get a little more info during boot. The above I’ve done several times so I know that it will work if your SD-card is not damaged in any way.

Good Luck

1 Like

Hi Fredrik

Tried your suggestion: it builds a 12G card the same
p1 620MB, p2 1.1GB, p3 11GB
but resize fails

ron:wahiba : Thu Mar 17 : 17:03:42
~$ sudo arm-image-installer
–image=Fedora-Workstation-35-1.2.aarch64.raw.xz --media=/dev/sde
–target=rpi4 --resizefs --showboot

Did you by chance run the arm-image-installer while the partitions on the sd card were still auto-mounted? or did you unmount those partitions first?

I have had similar problems with the arm-image-installer if I failed to unmount all the partitions on that card before I installed the image to it.

Using the example above where the card is seen as /dev/sdc I used the command sudo umount /dev/sdc[123] then used the arm image installer to write the image and it was able to resize the partition and file system properly.

NO, that didn’t do it, still got lots of free space:
p1: 629MB p2: 1.1GB p3: 11GB free: 115GB

ron:wahiba : Fri Mar 18 : 06:14:39
~$ sudo umount /dev/sdc[123]

ron:wahiba : Fri Mar 18 : 06:14:46
~$ sudo arm-image-installer
–image=Fedora-Workstation-35-1.2.aarch64.raw.xz --media=/dev/sdc
–target=rpi4 --resizefs --showboot
= Proceed? yes
= Writing:
= Fedora-Workstation-35-1.2.aarch64.raw.xz
= To: /dev/sdc …
12883361792 bytes (13 GB, 12 GiB) copied, 1366 s, 9.4 MB/s
0+945047 records in
0+945047 records out
12884901888 bytes (13 GB, 12 GiB) copied, 1366.16 s, 9.4 MB/s
= Writing image complete!
= Resizing /dev/sdc …
Checking that no-one is using this disk right now … FAILED

This disk is currently in use - repartitioning is probably a bad idea.
Umount all file systems, and swapoff all swap partitions on this disk.
Use the --no-reread flag to suppress this check.

sfdisk: Use the --force flag to overrule all checks.
Checking that no-one is using this disk right now … FAILED

This disk is currently in use - repartitioning is probably a bad idea.
Umount all file systems, and swapoff all swap partitions on this disk.
Use the --no-reread flag to suppress this check.

sfdisk: Use the --force flag to overrule all checks.
Resize device id 1 (/dev/sdc3) from 10.41GiB to max
= Raspberry Pi 4 Uboot is already in place, no changes needed.

= Installation Complete! Insert into the rpi4 and boot.

ron:wahiba : Fri Mar 18 : 06:42:24
~$

I tried a new SD card - that seems to have worked: p3 125GB 2.5% full
Many thanks to all
Ron

ron:wahiba : Fri Mar 18 : 06:42:24
~$ sudo umount /dev/sdc[123]
umount: /dev/sdc1: not mounted.
umount: /dev/sdc2: not mounted.
umount: /dev/sdc3: not mounted.

ron:wahiba : Fri Mar 18 : 06:53:22
~$ sudo arm-image-installer
–image=Fedora-Workstation-35-1.2.aarch64.raw.xz --media=/dev/sdc
–target=rpi4 --resizefs = Proceed? yes
= Writing:
= Fedora-Workstation-35-1.2.aarch64.raw.xz
= To: /dev/sdc …
12879241216 bytes (13 GB, 12 GiB) copied, 1063 s, 12.1 MB/s
0+951696 records in
0+951696 records out
12884901888 bytes (13 GB, 12 GiB) copied, 1179.59 s, 10.9 MB/s
= Writing image complete!
= Resizing /dev/sdc …
Checking that no-one is using this disk right now … OK

Disk /dev/sdc: 119.08 GiB, 127865454592 bytes, 249737216 sectors
Disk model: Storage Device
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5117a53f

Old situation:

Device Boot Start End Sectors Size Id Type
/dev/sdc1 * 2048 1230847 1228800 600M 6 FAT16
/dev/sdc2 1230848 3327999 2097152 1G 83 Linux
/dev/sdc3 3328000 25165823 21837824 10.4G 83 Linux

/dev/sdc3:
New situation:
Disklabel type: dos
Disk identifier: 0x5117a53f

Device Boot Start End Sectors Size Id Type
/dev/sdc1 * 2048 1230847 1228800 600M 6 FAT16
/dev/sdc2 1230848 3327999 2097152 1G 83 Linux
/dev/sdc3 3328000 249737215 246409216 117.5G 83 Linux

The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Device or resource busy
The kernel still uses the old table. The new table will be used at the
next reboot or after you run partprobe(8) or partx(8).
Syncing disks.
Resize device id 1 (/dev/sdc3) from 10.41GiB to max
= Raspberry Pi 4 Uboot is already in place, no changes needed.

= Installation Complete! Insert into the rpi4 and boot.

ron:wahiba : Fri Mar 18 : 07:13:40
~$

1 Like

Had you shown us the above the very first time it was seen it would have been much easier to provide an answer.

Just as a suggestion for the future.
You may want to put the failed SD card back into your reader and connect it, then do the following.
sudo dd if=/dev/zero of=/dev/sdc bs=1M count=1
Doing this will wipe out any and all data concerning the layout of the data on that card and allow it to be totally reformatted when you write the image to it.

After dd completes the above, try writing the image to that card again. It should work.
If it does not then I would think the card is bad and should be disposed of.

First time I tried the arm-image-installer I gave the fail messages. At
the start of this I was using the Rasberry Pi Installer - that did not
give the fail messages.

I just repeated it on the first disk and this time it worked OK. The
umount seems to be necessary. I’ve loaded the disks on a pi4B with 8G
memory and it all works.

But boot up is very slow (~5 min) but once up it’s usable, but rather
unsable - sometimes looses the keyboard & mouse and hangs, or fails to
boot up with failed to persist efi variables, or …

I would not recommend fedora 35 on a Pi.

Thanks for all the help and suggestions

Ron

1 Like

Unfortunately, Fedora’s support on rpi4 is still very recent. Truth be told, I’m still running different distros on my pi4s, even though I’m mostly running Fedora everywhere else. It would be very helpful if you wouldn’t mind submitting reports for issues like this on our bug tracker as this really helps best improve the experience for everyone.