Hi everyone,
It finally happened and I’m not sure how to diagnose. Any help would be appreciated. Thanks.
Please read the solution at https://discussion.fedoraproject.org/t/boot-fails-btrfs-errno-17-object-already-exists/90508 and ask for clarification of anything you don’t understand before attempting the suggested rescue steps, which you can do using the terminal in a Live USB installer. Although the process should be “low risk”, you can create an image (e.g., using Gnome Disks) of the affected partition on an external drive to give yourself a chance to “redo from start” if the rescue attempt fails.
I guess the question is how big is the risk and should I assume everything needs to be backed up first?
Im going to wait until im in a better state of mind to get this done. I do IT for a living but I still find fixing my own stuff stressful.
The other question is why do you suppose this happened? Is the boot sector dead? I assume my hardware hasn’t failed (though i could be mistaken of course) and I think all I did before this moment was update via flatpak.
Sorry without messaging too much, I should also add I’m on KDE so im assuming it’ll likely be KDE partition manager for this.
I’m assuming nvme1n1p3 is your “system” partition (btrfs format with @root and @home subvolumes). I’ve been using Unix for roughly 45 years, so I’ve seen lots of filesystem problems, and only a couple of times was data lost (one where the IT group was relying on a 3rd party to migrate files from a CDC system to Unix without careful validation. I did once lose backups when I forgot to disconnect the USB backup drive before updating windows (which reformatted an XSF formatted drive to create a Windows partition).
I’m an adherent to the 5-P’s rule, so start by preserving an image of a disk or partition before attempting repairs. This gives give me redo of the first (or 2nd, or 3rd …) attempt at repair fails.
If you are comfortable working with command line tools, you can use df as described in https://www.jamescherti.com/creating-disk-image-unix-linux/. Gnome Disks doesn’t offer to compress the image, which has the advantage that you don’t have to write an uncompressed image (maybe using a newer compression tool). You may want to read up on mksquashfs. I haven’t tried it myself, but it creates compressed read-only images, so seems suitable for backing up a partition which only be used in read mode to restore a partition for another round if the first repair attempt fails.
Its nice to know I’m in good hands. It means a lot to hear. I use this thing as my main gaming computer when I come home from work so I get a little overly attached I guess to my tech.
So sorry without being obtuse or asking really silly questions do I just want to run the commands you listed on a rescue disk usb?
Hey George,
Sorry to ask but can:
sudo btrfs rescue zero-log
Be run directly from the root or will I need to spin up a fedora memory stick to get fixing this?
I realize that running sudo from root is sort of redundant but I might be a little too inexperienced to know how to mount the file system to what I assume is clear out these three error and just boot as normal.
Thanks
Nevermind ended up figuring it out. just had to figure out how to mount my two BTRFS partitions. the command ran fine. 
I just saw this thread. This looks like either a kernel bug with log tree replay (I can’t tell off hand if the bug happened during write or replay or both); or a storage device firmware bug.
Do you know what kernel version was running at the time of the problem?
The typical advice is to make sure everything is up to date, including the kernel. There’s been quite significant log tree refactoring recently that also added superior debugging information for when a problem does happen.
btrfs rescue zero-log is semi-safe. All it does is dereference the log tree root in the supers so that at mount time it appears as if there’s no log tree to replay. The consequence is whatever writes were happening at the time the log tree was being written will be dropped. The file system itself is still consistent (in theory; e.g. if it’s not a storage device firmware bug doing something like transient dropped writes).
Although the file system is OK, depending on what those write were that are now dropped due to zeroing the log, it’s possible the user space process that was doing those writes might later get confused if those writes are missing. Hard to say, since it’s user space process specific.
Uhh extra info is that the log tree only exists when there’s a bunch of fsync’s happening, and then there’s a crash or power failure. Ordinarily the log is replayed at next boot, and the file system metadata is updated based on log tree replay. If replay fails and the log tree is zero’d or ignored, a btrfs is still considered consistent (unlike other file systems that require journal replay, and without replay they need fsck). But as mentioned, the writes that were happening just before the power fail or crash will get lost.