Crash on launch

[ThoriumTextile]

Traceback (most recent call last):
  File "<frozen runpy>", line 189, in _run_module_as_main
  File "<frozen runpy>", line 148, in _get_module_details
  File "<frozen runpy>", line 112, in _get_module_details
  File "/usr/lib/python3.11/site-packages/refind_btrfs/__init__.py", line 36, in <module>
    from refind_btrfs.utility.injector_modules import CLIModule, WatchdogModule
  File "/usr/lib/python3.11/site-packages/refind_btrfs/utility/injector_modules.py", line 27, in <module>
    from transitions.core import State
ModuleNotFoundError: No module named 'transitions'

Happens when launched with sudo too.

[Venom1991]

@ThoriumTextile

Do you have this package installed? Are you using the AUR provided package or did you install refind-btrfs from PyPI? Perhaps you need to rebuild Python packages which were installed from the AUR. See the pinned comment.

[ThoriumTextile]

@ThoriumTextile

Do you have this package installed? Are you using the AUR provided package or did you install refind-btrfs from PyPI? Perhaps you need to rebuild Python packages which were installed from the AUR. See the pinned comment.

Turns out I had a broken version of said package. Now it runs but says it can't find the root partition:

Found the ESP mounted at '/efi' on '/dev/sda1'.
ERROR (refind_btrfs.state_management.conditions/conditions.py/check_filtered_block_devices): Could not find the root partition!

[Venom1991]

Please provide the output of:

findmnt --json --mtab --real --nofsroot --output PARTUUID,PARTLABEL,UUID,SOURCE,FSTYPE,LABEL,TARGET,OPTIONS

[ThoriumTextile]

Please provide the output of:

findmnt --json --mtab --real --nofsroot --output PARTUUID,PARTLABEL,UUID,SOURCE,FSTYPE,LABEL,TARGET,OPTIONS

findmnt.log

[Venom1991]

Something is going on with the "source" property of the root partition:

{
   "partuuid": "a6aaf844-791a-204c-ae01-ee53f24906cc",
   "partlabel": "CachyOS",
   "uuid": "490b080e-71f5-407a-bf88-bf954ff3ab31",
   "source": "/dev/disk/by-uuid/490b080e-71f5-407a-bf88-bf954ff3ab31",
   "fstype": "btrfs",
   "label": "CachyOS",
   "target": "/",
   "options": "rw,noatime,compress=zstd:3,ssd,discard=async,space_cache,commit=120,subvolid=256,subvol=/@"
}

I use it to match findmnt's output with that of lsblk.

Please provide the output of:

lsblk --json --merge --paths --output NAME,TYPE,MAJ:MIN
lsblk /dev/sda --json --paths --tree --output PTUUID,PTTYPE,PARTUUID,PARTTYPE,PARTLABEL,UUID,NAME,FSTYPE,LABEL,MOUNTPOINT

Replace the "/dev/sda" part with the your root device's actual name.

The problem most likely has nothing to do with your setup because it obviously works (the OS itself, that is) but it does have to do with the fact that I never added support for persistent block device naming and it seems to me that you've set up exactly that (or the OS installer, doesn't matter), the UUID method to be precise. It's on my to-do list but I just can't find the time to improve upon this tool.

[ThoriumTextile]

lsblk1.log
lsblk2.log

Something is going on with the "source" property of the root partition:

{
   "partuuid": "a6aaf844-791a-204c-ae01-ee53f24906cc",
   "partlabel": "CachyOS",
   "uuid": "490b080e-71f5-407a-bf88-bf954ff3ab31",
   "source": "/dev/disk/by-uuid/490b080e-71f5-407a-bf88-bf954ff3ab31",
   "fstype": "btrfs",
   "label": "CachyOS",
   "target": "/",
   "options": "rw,noatime,compress=zstd:3,ssd,discard=async,space_cache,commit=120,subvolid=256,subvol=/@"
}

I use it to match findmnt's output with that of lsblk.

Please provide the output of:

lsblk --json --merge --paths --output NAME,TYPE,MAJ:MIN
lsblk /dev/sda --json --paths --tree --output PTUUID,PTTYPE,PARTUUID,PARTTYPE,PARTLABEL,UUID,NAME,FSTYPE,LABEL,MOUNTPOINT

Replace the "/dev/sda" part with the your root device's actual name.

The problem most likely has nothing to do with your setup because it obviously works (the OS itself, that is) but it does have to do with the fact that I never added support for persistent block device naming and it seems to me that you've set up exactly that (or the OS installer, doesn't matter), the UUID method to be precise. It's on my to-do list but I just can't find the time to improve upon this tool.

[Venom1991]

Yeah, it's like I thought - the UUID block device naming method is causing problems. This is your root partition as reported by lsblk:

{
   "ptuuid": "343d7322-2e1a-44bd-b1f3-32bd70f2d27e",
   "pttype": "gpt",
   "partuuid": "a6aaf844-791a-204c-ae01-ee53f24906cc",
   "parttype": "0fc63daf-8483-4772-8e79-3d69d8477de4",
   "partlabel": "CachyOS",
   "uuid": "490b080e-71f5-407a-bf88-bf954ff3ab31",
   "name": "/dev/sda2",
   "fstype": "btrfs",
   "label": "CachyOS",
   "mountpoint": "/mnt/@rootfs"
}

Now, compare the "name" property with the "source" property in findmnt command's output. They're not exactly the same, unfortunately. Until I add support for persistent block device naming (or switch to using partition UUIDs, perhaps) you won't be able to run this tool. Of course, you could try and get rid of it but I don't exactly know how to do so, honestly, as I've never used it.

EDIT: The process of matching lsblk and findmnt output needs to be reconsidered, I think. I'll try and do something about it but the issue is I only have one machine available to me and I could potentially break this tool for other people...

[CodingWithAnxiety]

I have multiple machines and, while pretty new to python, would love to honestly work on this and see what I can do. If I find a fix, and I make a merge request?

[Venom1991]

@CodingWithAnxiety

Sure, I don't see why not. Try supporting the "by-uuid" naming method first as it's the most common one (AFAIK). It shouldn't be that much work if I remember correctly how the matching process is implemented.
Basically, it should be enough to check (as an alternative to the currently implemented one, i.e. as an "elif") whether lsblk's "uuid" property's value appears as a substring in findmnt's "source" property's value. In @ThoriumTextile's example, "490b080e-71f5-407a-bf88-bf954ff3ab31" is a substring of "/dev/disk/by-uuid/490b080e-71f5-407a-bf88-bf954ff3ab31".

I don't have much free time to work on this tool, anymore.

EDIT: Honestly, my plans for this tool is to rewrite it in Rust, improve upon it by implementing a few new features, write tests and also learn a new language in the process. Porting non-trivial software is, at least for me, a good way of doing so.

[CodingWithAnxiety]

Right, so I've looked over the code, And... With VERY few comments, it's very difficult for me to comprehend how it's structured. Any idea where I should be starting?

[Venom1991]

@CodingWithAnxiety

Yep, no comments. It's also one of the things that should be added, perhaps even in Sphinx syntax.

Anyway, I'd start here as this is where lsblk's output is matched with the one received from findmnt.
The whole codebase is typed so you should be able to navigate it with, for example, F12 in VS Code which is what I'm using to develop and debug this program. To debug, pressing F5 should be enough.

You'll also need to create a virtual environment and install every package found in this file. You'll end up with a hidden directory named ".venv" in the project's root directory. Inside it, there exists a "pyenv.cfg" file in which you must change the value of "include-system-site-packages" from false to true because there is no package on PyPI for libbtrfsutil. Just make sure to change that flag's value after you've installed the required packages.

If you can't figure it out due to a lack of comments, that's also alright. I understand it's a bit convoluted but it's also pretty straightforward once you step through the whole process, i.e. from here onwards.