I have a dualboot fedora and windows system on a 256gb ssd. I bought a new 1tb drive, and cloned the old one to it with clonezilla without any trouble, the 1tb drive booted fine.
I want to move the btrfs and the boot partitions to the right, so I can enlarge the windows partition. Looking for the errors online turns a bunch of reddit posts, some solved similar issues with a “btrfs check --repair” that is deemed dangerous and a last resource option. I know nothing about btrfs, I think it was a default option in the installer and I made a seperate boot partition because I read somewhere that it was a good practice.
I want to know how to repair those errors, if possible, and if not, what caused them, to avoid them in a new install. Otherwise, I’ll reinstall and not bother with btrfs and go back to ext4 partitions.
You changed the partition size but gparted is not able to resize a btrfs file system as it does for ext4. You need to use the btrfs tools to resize the file system to fit the new partition size. This must be done before you can attempt to relocate the partition.
I do not use btrfs much (only in a vm with a fixed size and I have not worked with the btrfs file system tools) so cannot provide the steps. Posts here have given me the general info.
From the redhat docs, I should do something like “btrfs filesystem resize amount /mount-point”. From the output of "btrfs filesystem show " I think I only have one btrfs device, with device id = 1. But I don’t know what should I use as mount point in the resize command. In Gparted, both / and /home are listed as mount points for the btrfs partition. Which should I use? Or do I have to resize both? I’d gues not both, otherwise there would be 2 btrfs devices, but I’m really not sure.
I did the same thing (but using btrfs resize) and did not encounter problems. I did make sure the btrfs filesystem was healthy first. Btrfs is relatively new, so there have been bugs that are now fixed. Many older reports of problems are no longer valid. Btrfs does, however, report problems that legacy filesystems ignore. As a result, periodic maintenance can identify and hopefully repair issues before they grow into major problems.
If you are getting errors you need to consider whether they were caused by hardware issues (RAM, failing storage media). See: How to recover from BTRFS errors (SUSE).
I’m not sure I understand the SUSE article. They are checking some sort of logs, it seems, but where are they exactly? It just says, “if you see a message/trace” but not where or how to access them. Sorry if it’s really obvious, but I’m a linux user with zero sysadmin knowledge.
Fedora has journalctl, which collects a massive amount of detail, so you need “filters” to select messages relevant to btrfs. It is a command-line tool, so you run it using “Terminal” in the Gnome Desktop. For starters, try journalctl --no-hostname -b -g btrfs (use man journalctl to see what the options do).
A nice discussion of btrfs is Btrfs and Lessons Learned. It has some examples of commands to monitor btrfs status.
Moving partitions (irespective of their underlying filesystem) is possible AFAIK when the unallocated space is bigger than the partition being moved.
So instead of enlarging, the moving, in my opinion the operation should be performed in a different order:
make sure the partition to be moved is smaller than the unallocated space (shrink if necessary and possible)
then move the partition (to the left of the unallocated space or in between the margins, depending on the size needed to be added to Windows)
finally, increase the Windows and Fedora partitions to the margins of the unallocated space.
Afterwards, the btrfs filesystem should be resized in accordance to the new partition size. This is from the btrfs filesystem man page:
The resize command does not manipulate the size of underlying partition. If
you wish to enlarge/reduce a filesystem, you must make sure you expand the
partition before enlarging the filesystem and shrink the partition after re‐
ducing the size of the filesystem. This can be done using fdisk(8) or
parted(8) to delete the existing partition and recreate it with the new de‐
sired size. When recreating the partition make sure to use the same starting
partition offset as before.
If you have a current backup, these look safe to repair.
Btrfs errors reported by btrfs check are not normal, and are uncommon. Therefore it’s best to ask everytime - which I know is tedious for a repair utility but fortunately rare.
For Fedora and Btrfs issues, I recommend asking cmurf in https://matrix.to/#/#fedora:fedoraproject.org or if you prefer libera.chat you can ask someone to ping cmurf on matrix and I’ll pop over to IRC. Those are better forums for the back and forth typically required.
As for moving partitions with gparted: you must have backups if you care at all about the data.
If you don’t care about the data, just delete the partition and start over with the partitioning you want. Really, it’s faster and easier. In most cases it’s probably faster and easier to backup your data, delete the Fedora partitions, reinstall, and restore from backup.
Why? Moving the partition requires block copying the partition contents. Once it begins, until it successfully completes, the file system is broken into two parts: moved and not yet moved. If the process is interrupted, which could take hours, it’s left in a broken and unrepairable state.
