Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: fix to detect mounted LUKS-encrypted btrfs subvolumes #2198

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

intentionally-left-nil
Copy link

PR Description:

This is a prototype fix for detecting already-mounted btrfs volumes, when inside of a LUKS encrypted partition. Without this fix, the code only detects the LUKS partition and not its mounted counterpart.

This code adds the detection for this case, and then recurses down to the children to find the btrfs subvolumes. The reason this is a prototype (request for comment) is that I don't know what to do about the partition information. The subvolume is technically part of the LUKS partition, but e.g. the path is /dev/mapper/ not /dev/sda1 (which points to LUKS). etc.

This PR does seem? to work when running archinstall on my own setup, but I don't have enough knowledge of the codebase to understand what the correct solution is.

I'm happy to carry this PR forward, with guidance. Otherwise I'm happy to turn it over to @Torxed or others to implement a more robust solution

Tests and Checks

  • I have tested the code!

@intentionally-left-nil intentionally-left-nil changed the title RFC: fix to detect mounted cryptfs btrfs subvolumes RFC: fix to detect mounted LUKS-encrypted btrfs subvolumes Nov 4, 2023
@intentionally-left-nil
Copy link
Author

The PR isn't quite right, now btrfs.progs isn't being installed. The attempted commit I pushed to fix this just made things worse...

@Torxed
Copy link
Member

Torxed commented Nov 6, 2023

I just wanted to swing by with a comment so you know I've seen it and will take a look :)

@intentionally-left-nil
Copy link
Author

Thanks!

I think there's a few pieces to get right:

  • The UUID (especially when creating any boot entries)
  • The filesystem type (btrfs) so that you end up with btrfs.progs installed
  • The root subvolume id

and there are probably others that don't pertain to my specific scenario

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants