what could possibly go wrong?
the disk storage on my arch install is regularly hitting 100% and i cant be arsed to purge my packages
/usr is a hefty 10GB and /home is reaching 28GB
(no thanks to steam which is eating up 18GB)
btrfs has compression which can reduce my install size with 0 effort, and more importantly in-place reformatting! which is pretty handy as i don't have a spare backup drive
healthy amount of warnings on the arch wiki page !!WHICH YOU SHOULD DEFINITELY HEED!!
in my case this install isn't too important, it's just for gaming and running misc glibc stuff
we can't modify the mounted rootfs in-place, need a liveusb
got my handy EndeavourOS install iso from 2023 yes this "arch" install is technically EndeavourOS but i ripped everything out so now its essentially arch with an EndeavourOS boot message , fire that up
cryptsetup unlock the luks partition and run btrfs-convert on the decrypted block device
why's it trying to handle as ext2... meh probably harmless
great, it's aborting
btrfs-convert is giving some arcane Unable to find block group for 0 error,
looked it up and found this github issue
the error is due to insufficient space (btrfs-convert reports something like 0.1% free)
wiped ~2GB from /var/cache but still fails, maybe it needs more?
that issue mentioned defragging as a potential solution, so let's try defragging my ext4 partition first
took an awfully long time but btrfs-convert now reports a grand whopping total of
0% free
yippee...
saw a stackoverflow comment saying to resize it smaller in gparted, that would probably free up enough contiguous blocks at the tail end but
i decided i was too lazy for that and instead nuked most of my 5GB rainworld install (2GB from MSC alone!), steam can re-sync the files anyway
and btrfs-convert succeeds!!! surprised the backup image managed to fit but maybe btrfs is just that much more space-efficient!
i immediately reboot, excited to take my new btrfs root for a spin
after unlocking the luks partition, systemd tries to boot from remote disk
same error as https://bbs.archlinux.org/viewtopic.php?id=273889 with stuck start job for /dev/mapper device
saw some other people with the same issue who let it sit for 2 minutes and it fixed itself
... 2 hours later...
nope that's not happening
my heart drops as i reboot into the iso, expecting the worst
... it mounts fine as btrfs?? and the backup image is there too, looks like btrfs-convert worked fine. huh.
maybe something's wrong with the initramfs? can't be the uuid, i checked gparted and it looks the same as in the boot config
i mount the EFI partition and check my rEFInd boot entries in case there's some btrfs flag. no dice. there's no mention of arch anywhere
after some grepping it turns out the boot configs are in the loader/ directory
# Boot Loader Specification type#1 entry
# File created by /etc/kernel/install.d/90-loaderentry.install (systemd 254.1-1-arch)
title EndeavourOS
but the options look correct
weird.
i reboot again and drop to the emergency shell by failing the decrypt password prompt on purpose guess how i found out about this feature! , successfully guessing my root password along the way
i try to tab-complete cryptsetup but command doesn't exist,
instead there's systemd-cryptsetup which uses a different arg format.
after figuring that out it decrypts fine and shows up in /dev/mapper as expected
then i try to mount it
no dice, modprobe btrfs fails
oh.
OH.
remember that boot config file?
# File created by /etc/kernel/install.d/90-loaderentry.install (systemd 254.1-1-arch)
turns out this is handled by kernel-install
we can call that manually to install the updated initramfs with our btrfs module (dracut recognizes we're on btrfs and helpfully includes it for us)
do arch-chroot and mount the efi partition on /boot/efi/ then run kernel-install --all
(by default it uses the host kernel version which is awfully out of date, im too lazy to set it the proper way cos that needs a bunch of weird args so --all it is)
fails halfway cos EFI partition is full, i wipe the old versions and rerun and it installs successfully
reboot and...
it works!!
lmao
df -h reports 11GB free which is unexpected :D
one not-so-quick-but-sorely-needed system update later and it's back to 1GB... sigh...
arch wiki has a helpful section on this
there's a warning about COW increasing filesize but i don't have any snapshots so not too concerned
im gonna just run this
btrfs filesystem defragment -r -v -czstd /
an eternity later...
holy shit
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/dm-0 48G 25G 23G 53% /
transparent compression ftw
btrfs-convert works perfectly aside from the confusing "no disk space" error messages
oh the boot error message is terrible too, it should try to detect the filesystem and complain about "no kernel module for btrfs" before attempting remote boot
remember to update your initramfs when migrating filesystems!
made with <3 and /.gen.sh