Repository navigation
Find LUKS drives without the blkid cache; fix the Mac encrypt unit's log output - #556
Merged
Merged
Conversation
…ive-password-discovery # Conflicts: # test/shell.d/drive-password-test.sh
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ticket 69, found in the ticket 28 VM run.
Summary
omarchy-drive-passwordranblkidas the user, which reads only root's cache in/run/blkid. That cache stays empty until root runsblkid, so on a fresh boot the command found no LUKS drive. It now lists LUKS devices withlsblk(udev's probe, the same source root detection already uses), each device once. Root detection still fails closed. The LUKS-first ordering (Change the root LUKS key before syncing login and root passwords #532) and the token-only key checks (Security: keep enrolled LUKS2 tokens from passing LUKS key checks #549) are unchanged.StandardOutput=journal+kmsg. systemd rejects that value and falls back to the journal only. It now useskmsg(journal plus kernel log) withSyslogLevel=notice, because by default journald only passes notice and above to kmsg. It still never writes straight to the console.Testing
test/shell.d/drive-password-test.sh: the fakeblkidnow behaves like an empty cache (no output, exit 2), and discovery goes through a fakelsblk. A new case offers every LUKS drive once and changes the system disk. The old script fails this case; the full file passes, including the real-cryptsetup LUKS1/LUKS2 runs.mac-encrypt-test.sh: assertskmsg+SyslogLevel=noticeand runssystemd-analyze verifyon the unit, failing on any output, because verify exits 0 on parse warnings. It skips where verify can't run (emulated containers). The old unit fails; the new one passes. The boot package suite passes. All of this ran as a non-root user in the CI image (archlinux:base-devel, systemd 261) on native x86.blkid -c /dev/nullas the user (no cache) finds nothing, while the new lsblk query lists the root LUKS partition. A transient unit withStandardOutput=kmsgreached dmesg at notice; at info it reached only the journal.