Fix root UUID detection for device-mapper/LUKS systems#43
Fix root UUID detection for device-mapper/LUKS systems#43dmitrii-codes wants to merge 1 commit intoisantop:masterfrom
Conversation
|
@isantop please take a look - a recent pop!_os update caused my system to fail to boot because of this |
|
Neither me nor this repository are affiliated with Pop_OS or System76. You'll need to see their repository to fix this issue in Pop_OS |
| except OSError: | ||
| pass | ||
|
|
||
| # 2. Try findmnt SOURCE -> blkid |
There was a problem hiding this comment.
Is there any reason this is being handled after the existing code? If we need to add the -n flag, we should just add it instead of failing without it and falling back on nearly identical code.
| result = subprocess.run(args, stdout=subprocess.PIPE) | ||
| src = result.stdout.decode('ASCII').strip() | ||
| if src: | ||
| args = ['blkid', '-s', 'UUID', '-o', 'value', src] |
There was a problem hiding this comment.
On my machine, this command does not return anything regardless of what UUID I feed it. It just exits with status 2.
| try: | ||
| with open("/proc/cmdline", "r") as f: | ||
| cmdline = f.read() | ||
| match = re.search(r"\broot=UUID=([0-9a-fA-F-]{36})\b", cmdline) |
There was a problem hiding this comment.
This is not a good method to determine the UUID required. If kernelstub is running on a live system, this method will always fail.
2 participants
Summary
Fixes an issue where kernelstub fails to detect the root UUID on device-mapper/LUKS systems, causing it to use an empty UUID (e.g., EFI/Pop_OS-). This might lead to "No space left on device" errors by creating duplicate directories instead of updating existing ones.
Changes
Updated Drive.get_uuid with a fallback strategy:
Impact
Ensures correct ESP paths (e.g., EFI/Pop_OS-<UUID>) are used, preventing boot failures and ESP exhaustion on encrypted systems.
Verified on Pop!_OS 24.04 with encrypted root.