Hey there,
unfortunately I got the same seg fault error within the kernel due to BTRFS raid volumes. I have the newest bullseye C4 image. Did I get you right that just using a newer btrfs-progs version wont help because the kernel itself also has the faulty version compiled?
In my situation it is very strange:
First I setup the BTRFS volumes, setup nextcloud and everything. The system runs as expected.
After couple of days e.g. I need to shutdown the odroid because of some maintenance stuff on the case. After the system boots again, every access to the raid volume freezes the whole system because of a segmentation fault.
When I
umount /mnt/volume
i get the result code
Segmentation fault
The funny thing is, I can restore all data without any loss with
Not sure, the old Odroid N2 image/kernel at least is known to have issues with USB in cases. You could check dmesg -l emerg,alert,crit,err for kernel errors but I fear we wouldn’t be able to do much about it.
If possible, I suggest to use our new mainline kernel based image. It is still in testing stage, but so far we got only positive feedback: https://github.com/MichaIng/DietPi/issues/5039
MichaIng
The connection is through SATA directly with the HC4. Perhaps this is the issue that the boot kernel of the HC4 image is the odroid N2 boot image or is this as intended?
dietpi@DietPi:~$ sudo btrfs check /dev/sda1
Opening filesystem to check...
Checking filesystem on /dev/sda1
UUID: 3071c9b1-fbd3-49cd-be54-cb6ad296fab6
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 2054799360 bytes used, no error found
total csum bytes: 2000464
total tree bytes: 5275648
total fs tree bytes: 2342912
total extent tree bytes: 311296
btree space waste bytes: 1030953
file data blocks allocated: 2049523712
referenced 2047770624
dietpi@DietPi:~$ sudo btrfs check /dev/sda2
Opening filesystem to check...
Checking filesystem on /dev/sda2
UUID: bdaf3535-0d3d-405d-9260-4bcc8aad1802
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 15825326080 bytes used, no error found
total csum bytes: 15259892
total tree bytes: 194478080
total fs tree bytes: 167526400
total extent tree bytes: 8486912
btree space waste bytes: 31531975
file data blocks allocated: 15630848000
referenced 15630843904
dietpi@DietPi:~$ sudo btrfs check /dev/sdb1
Opening filesystem to check...
Checking filesystem on /dev/sdb1
UUID: 3071c9b1-fbd3-49cd-be54-cb6ad296fab6
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 2054799360 bytes used, no error found
total csum bytes: 2000464
total tree bytes: 5275648
total fs tree bytes: 2342912
total extent tree bytes: 311296
btree space waste bytes: 1030953
file data blocks allocated: 2049523712
referenced 2047770624
dietpi@DietPi:~$ sudo btrfs check /dev/sdb2
Opening filesystem to check...
Checking filesystem on /dev/sdb2
UUID: bdaf3535-0d3d-405d-9260-4bcc8aad1802
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 15825326080 bytes used, no error found
total csum bytes: 15259892
total tree bytes: 194478080
total fs tree bytes: 167526400
total extent tree bytes: 8486912
btree space waste bytes: 31531975
file data blocks allocated: 15630848000
referenced 15630843904
MichaIng after some further analysis, I think it is still the same issue as https://github.com/MichaIng/DietPi/issues/4062. I can help in testing newer versions but for now, we should highlight that BTRFS is not working for C4 image. I also switched to LVM now until BTRFS is working.
What? The bootloader, kernel and device tree is for Odroid C4 and HC4, not for N2. I just mentioned the known issues with Odroid N2 since it could be similar with C4/HC4. But since you use SATA this shouldn’t apply.
Interesting, does this happen in general with the umount command or with this particular filesystem only? Probably the kernel indeed has some limitations regarding Btrfs, would be nasty.
No. The kernel is not the one from Debian but one from Hardkernel. The one from Debian won’t work with the bootloader and configs. We are however planning to migrate to a mainline kernel build from Armbian soon, like we just did for Odroid N2. But this requires reflashing the system since Armbian’s U-Boot build expects everything to be on a single ext4 partition without a dedicated boot FAT partition.
