You are not logged in.
I have a single disk btrfs root on a luks volume. separate /boot.
data was single. metadata was single. I was advised to change meta to DUP and did
btrfs balance start -mconvert DUP /mnt
I had 150GB free of a total of 2TB, yet the fs went r/o immediately.
a reboot asked for my luks passphrase, then dropped me into a recovery. where I was instructd to press 'ctr d' for maintenance, but no input was accepted. I use grub-btrfs, and I was able to reboot again, this time selecting an older r/o snapshot. the volume was unlocked, and I booted into a busybox environment with no btrfs-progs
I was able to mount the top level subvolume with
mkdir /ssd && mount -o rw,skip_balance /dev/mapper/cryptssd /ssd
everything looks intact
however
touch /ssd/test
gives an I/O error. in my current situation, I have no live media to boot from nor secondary storage.
Last edited by shoelesshunter (2022-06-19 14:07:39)
Offline
Run `journalctl -eb` immediately after mounting and examine any btrfs-related output in the log. This should indicate which error the kernel is encountering when attempting to mount and can help troubleshoot further.
Offline
when I boot the default kernel, I get the prompt to run journalctl but the system doesn't accept any input. when I boot into a non-existent snapshot, (grub has the entry, but they've been deleted), I find myself in busy box environment. here I am able to mount the fs, but it still mounts r/o even with
-o skip_balance,rw
Last edited by shoelesshunter (2022-06-19 14:10:00)
Offline
Try `dmesg` instead to get the log. Depending on what it says, you'll probably need to find some way to get btrfs-progs if you didn't include it in your initramfs. I'm not sure how without an archiso, perhaps someone else knows
Offline
I solved this by booting kernel 4.19. I was then able to
mount -o skip_balance,rw /dev/mapper/cryptssd /mnt
then
btrfs balance cancel /mnt
I ran a filtered balance:
btrfs balance start -musage=5 -dusage=10 /mnt
after freeing up some space I finally ran
btrfs balance start -mconvert=dup /mnt
all of this was done on kernel 4.19
I rebooted the fs and it is r/w.
the problem is that I was never truly out of free space. there is a know bug in 5.x where a balance with -mconvert=dup will do two critical things. first, the fs thinks it is out of free space and locks r/o. second,
mount -o rw,skip_balance
is ignored, and every time one attempts to remount the drive, the balance tries to resume and the fs immediately locks r/o.
https://www.reddit.com/r/btrfs/comments … cancel_no/
note: I'm not sure
btrfs balance start -musage=5 -dusage=10 /mnt
was necessary, but it was recommended.
Offline