You are not logged in.
Pages: 1
Hi everyone,
I ran into a weird problem: I'm using btrfs for my root partition; I take snapshots before major system upgrade to be able to roll back easily. During last week's updates, I somehow broke my active btrfs subvolume, so I copied my backup snapshot and mounted it as the "new" file system. I was able to upgrade my system, but now I have one snapshot (the current one) which is upgraded and mounts properly; I have another subvolume with my old system which I can't mount writable. Since it's eating up my free disk space, I'd like to delete it. But I can't since I can't mount the FS_TREE either.
btrfs subvolume list -a /
ID 256 gen 2629 top level 5 path <FS_TREE>/__active
ID 282 gen 2626 top level 5 path <FS_TREE>/__active/__backup
ID 285 gen 5494 top level 5 path <FS_TREE>/__active/__restore#256 is broken, #282 (ro) and #285 (rw, my default) work perfectly, as I said #5 is broken too. With all the broken subvolumes, I get a segmentation fault when mounting the volume writable. (If it's necessary I can post it, I don't like killing my system too often, so I haven't tried again).
Do you have an idea how I can delete #256? Normally, I would have mounted #5, moved __active/__restore to ./__restore and the deleted __active, but now that doesn't work. Any help is appreciated ![]()
Offline
I would say that when segfaults occur; it's time to start debugging, since something is obviously broken. I also think you'll need the btrfs devs to look at this. I would also make sure to have some good backups; and migrate the filesystem (possibly with snapshots using `btrfs send`) to a new one since I wouldn't trust it anymore ![]()
Offline
Thanks for your reply and sorry I haven't answered earlier; the filesystem broke completely (again). I'm not sure what causes the crash but one of the updated packages from about two weeks ago breaks my btrfs partition. I'm starting to investigate which package it is, but since I don't want to break the system all the time, caution is necessary. It is NOT the kernel itself. Do you have any suggestions which packages might cause this?
I also sent an email to the btrfs devs but didn't get a reply.
Now, I'm running from a backup snapshot again, the root subvolume still doesn't work. I always get errors like
May 15 09:51:41 singsung kernel: btrfs: free space inode generation (0) did not match free space cache generation (195)during boot.
Offline
Pages: 1