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.
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.
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
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):
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.
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.
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.
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.
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 …
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.