In reply to @erahhal:homefree.host
the nix wiki on dual boot seems to be out of date

When systemd-boot is installed to the same EFI System Partition (ESP) that Windows uses
sounds like it's the same disk to me

When systemd-boot is installed to the same EFI System Partition (ESP) that Windows uses...

sounds like it's the same disk to me

Here's the disk configs if anyone is willing to take a look.

https://warez.kernelpanic.cafe/Code/impermanence.nix.txt

https://warez.kernelpanic.cafe/Code/disko.nix.txt

Hello. I'm currently working on improving disko's support for bcachefs. So far, I have made a PR to add encryption support. Currently, I am working on adding subvolume support. However, I am having trouble getting this to work. This is the output when I run nix build --no-link .#checks.x86_64-linux.bcachefs-subvolumes --show-trace -L -v.

I suspect that a reason that this could happening might be due the order in which mountpoints are mounted. My theory is that descendant mountpoints (e.g., /ancestor/descendant) could be being mounted before ancestor mountpoints (e.g., /ancestor) have been created/mounted.

Does disko mount filesystems such that ancestor mountpoints are mounted before descendants, or is this behaviour dependent on how the _mount option (made with diskoLib.mkMountOption) for the relevant filesystem type is implemented?

I have tried to debug my implementation using nix build .#checks.x86_64-linux.bcachefs-subvolumes.driverInteractive; result/bin/nixos-test-driver --keep-vm-state, but this doesn't seem to be working properly, as it doesn't show the bcachefs filesystem that should have been created:

$ lsblk -f
NAME FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
fd0                                                                         
sr0                                                                         
vda  ext4   1.0   nixos a7ac900e-9d30-45da-b745-56d7d190aedd  888.3M     2% /
vdb  

In fact, it shows that same lsblk output for various other examples I tried it with (I also tried it with btrfs-subvolumes and simple-efi).

Is there another way I can go about debugging this?

I am having (skill) issues resizing my .swapvol after I have mistakenly put it to 20M instead of 16G,
I've tried to do

% sudo btrfs filesystem resize "+16G" "/.swapvol"
Resize device id 1 (/dev/mapper/crypted) from 476.42GiB to 492.42GiB
ERROR: unable to resize '/.swapvol': no enough free space

but

% df -h | \grep -E 'Avail|.swapvol'
Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/crypted  477G   88G  389G  19% /.swapvol

% sudo btrfs filesystem df /.swapvol
Data, single: total=80.00GiB, used=77.80GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=5.00GiB, used=4.52GiB
GlobalReserve, single: total=243.62MiB, used=0.00B

Is there a way to get Disko to just resize a subvolume?