Firstly, accept my apologies if I am making this threading in the wrong place, as this is the first time I am posting to this forum.
I have been experimenting with the latest ISO images in VirtualBox, mainly attempting to make a custom LabWC-based Artix system (so that I can migrate my main system to that configuration as well). I believe in this endeavor I have triggered some form of the bug, specifically when installing:
A) From any official image with clamares installer and a graphical environment. I have tested XFCE, MATE, LXQt
B) Using full-disk auto partitioning
C) Choosing Swap (Without hibernate) and BTRFS <- this seems to be the cause.
Upon completion of the install the system is unable to boot and produces the following kernel panic. (Images attached).
I have tested this scenario also with other filesystems except for F2FS and I can assure you the system is perfectly sane and boot-able with other filesystems, thus I believe this is a bug with BTRFS in particular.
Please advice on further information needed and I will provide it as needed.
It's a known issue.
If you're able just do a base install.
Or install to ext4 then transfer the ext4 rootfs contents to a btrfs partition and adjust fstab and bootloader etc.
Ah OK then. If it's a known issue I'll just do a base install or use a simpler FS anyway. Thanks
With "artix-xfce-runit-20250623-x86_64.iso" it looks different: see Attachments
Btw:
1.
A more efficint QR-Code: https://en.wikipedia.org/wiki/QR_code#HCC2D
2.
zstd:1 is not a goot choice
zstd:2 is the best choise for btrfs: it is slightly faster than 1 and compress nearly as good as higher levels:
[ramdisk]# mount /run/media/user/Backup/ -o remount,compress=zstd:1
[ramdisk]# time rsync -axH Artix/ /run/media/user/Backup/tmp/zStd:1/;time sync
real 1m24,226s
user 0m15,022s
sys 1m19,090s
real 0m0,896s
user 0m0,000s
sys 0m0,089s
[ramdisk]# mount /run/media/user/Backup/ -o remount,compress=zstd:2
[ramdisk]# time rsync -axH Artix/ /run/media/user/Backup/tmp/zStd:2/;time sync
real 1m24,053s
user 0m14,977s
sys 1m18,832s
real 0m0,546s
user 0m0,000s
sys 0m0,064s
[ramdisk]# mount /run/media/user/Backup/ -o remount,compress=zstd:3
[ramdisk]# time rsync -axH Artix/ /run/media/user/Backup/tmp/zStd:3/;time sync
real 1m31,107s
user 0m14,815s
sys 1m19,024s
real 0m0,770s
user 0m0,001s
sys 0m0,071s
[ramdisk]# mount /run/media/user/Backup/ -o remount,compress=zstd:5
[ramdisk]# time rsync -axH Artix/ /run/media/user/Backup/tmp/zStd:5/;time sync
real 1m59,233s
user 0m15,917s
sys 1m20,486s
real 0m0,560s
user 0m0,000s
sys 0m0,068s
[ramdisk]# mount /run/media/user/Backup/ -o remount,compress=zstd:12
[ramdisk]# time rsync -axH Artix/ /run/media/user/Backup/tmp/zStd:12/;time sync
real 7m44,571s
user 0m15,948s
sys 1m19,236s
real 0m1,604s
user 0m0,000s
sys 0m0,092s
[ramdisk]# cd /run/media/user/Backup/tmp/
[tmp]# compsize zStd:1/
Processed 161609 files, 91551 regular extents (91723 refs), 86961 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 60% 3.2G 5.3G 5.3G
none 100% 2.0G 2.0G 2.0G
zstd 36% 1.1G 3.2G 3.2G
[tmp]# compsize zStd:2/
Processed 161609 files, 91507 regular extents (91675 refs), 87035 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 60% 3.2G 5.3G 5.3G
none 100% 2.0G 2.0G 2.0G
zstd 35% 1.1G 3.2G 3.2G
[tmp]# compsize zStd:3/
Processed 161609 files, 91463 regular extents (91631 refs), 87065 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 59% 3.1G 5.3G 5.3G
none 100% 2.0G 2.0G 2.0G
zstd 34% 1.1G 3.2G 3.2G
[tmp]# compsize zStd:5/
Processed 161609 files, 91369 regular extents (91526 refs), 87158 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 59% 3.1G 5.3G 5.3G
none 100% 2.0G 2.0G 2.0G
zstd 33% 1.0G 3.2G 3.2G
[tmp]# compsize zStd:12/
Processed 161609 files, 91261 regular extents (91418 refs), 87266 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 58% 3.1G 5.3G 5.3G
none 100% 2.0G 2.0G 2.0G
zstd 32% 1.0G 3.2G 3.2G
Yes that failure also happens. Also, another discovery I had is that encryption is also similarly broken.
EDIT: The default zstd level if used without specification in BTRFS is '3'. Personally, I am using :8 , :10 , :14 on three drives. Why? Because I was trying to really push it, and it worked... so it stuck
I didn't try encryption, because I you the OPAL Hardware encryption oft the Crucial MX 500:
https://github.com/Drive-Trust-Alliance/sedutil/wiki/Executable-Distributions
I know. But on my 3rd Shot you can see, that there is zstd:1 on all Entries in the fstab: That was not from me.
Did you compare that with compsize?
With compress-force the compression is better, but again are higher level than 2 a waste of cpu-time, according to my experience
Btrfs uses only 180k blocks for compression.