btrfs_allocation is not grepped correctly on Jolla 1 v 1.0.8.19.

[Okxa]

On Jolla 1 version 1.0.8.19 the default (on line 364) in sfos-upgrade

btrfs_allocation="$(btrfs filesystem df / | grep '^Data, ' | cut -s -f 2 -d ':' | tr ',' '\n' | tr -d ' ' | rev | grep '^Bi*G[0-9][0-9]\.[0-9][0-9]*=' | sed 's/^Bi*G//g' | tr -d '.' | rev)"

gives incorrect results.

But if used (grep '^Data' instead of grep '^Data, '):

btrfs_allocation="$(btrfs filesystem df / | grep '^Data' | cut -s -f 2 -d ':' | tr ',' '\n' | tr -d ' ' | rev | grep '^Bi*G[0-9][0-9]\.[0-9][0-9]*=' | sed 's/^Bi*G//g' | tr -d '.' | rev)"

It gives correct results

[root@Jolla nemo]# btrfs filesystem df / | grep '^Data' | cut -s -f 2 -d ':' | tr ',' '\n' | tr -d ' ' | rev | grep '^Bi*G[0-9][0-9]\.[0-9][0-9]*=' | sed 's/^Bi*G//g' | tr -d '.' | rev
total=964
used=287

I don't have other devices to test the btrfs command with, so I dont know how these differ in different versions, and what is a universal fix.

[Olf0]

Oh, how I hate commands, which change their output format over time! 😞

Do you still have SFOS 1.0.8 installed? If so, please provide the output of btrfs filesystem df / here. Thanks!

[Okxa]

Sorry, already upgraded.

It was probably something similiar as seen here:

[root@localhost ~]# btrfs filesystem df /
Data: total=13.08GB, used=13.04GB
System, DUP: total=8.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=330.00MB, used=116.95MB
Metadata: total=8.00MB, used=0.00

this is from my now upgraded device:

[root@Sailfish nemo]# btrfs filesystem df /
Data, single: total=10.64GiB, used=4.00GiB
System, DUP: total=40.00MiB, used=4.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=330.00MiB, used=135.02MiB
Metadata, single: total=8.00MiB, used=0.00

If it's any help after modifying the script it worked all the way through 3.1.0.11, and both commands in the original issue return valid on current version:

total=1064
used=395

[Olf0]

Thanks for looking up the output of old versions of btrfs filesystem df / at TJC.

Yes, I assumed this change would let sfos-upgrade work "all the way through [to] 3.1.0.11" even before your confirmation that it does, but "working" is not my only criterion. The code being "reasonable", "understandable", "written in a safe style" and "solid against external changes" are other relevant criteria. Furthermore, I will never integrate suggestions, which I do not fully understand.

Thanks to your research and explanations, all this is archived now. Thus I ultimately followed your suggestion for fixing this 1:1 in commit 316fd81, as I currently see no better way to resolve this.

[Olf0]

Released as v3.2-1 and uploaded a built RPM for testing.