Repository navigation
Conversation
The 6th-parameter change made the 5th column authoritative for enabling
encryption ("yes" instead of any non-empty value), but create_partitions
still decided the fstab "crypted" marker by grepping the raw PART line for
the string "crypt". The two are now inconsistent, and since encrypt_partitions
iterates the fstab looking for "crypted", the documented syntax
PART /mnt ext4 all yes
passes the CRYPT gate in install.sh, runs encrypt_partitions, and installs
in plaintext -- no error, no non-zero exit.
Reading PART_CRYPT[$i] makes both paths use the same field. It also fixes a
pre-existing defect: the grep matched by substring against the whole
part_lines file, so with
PART /var ext4 1G
PART /var/log ext4 all crypt
/var was marked crypted as well, encrypting a partition that was never
configured for it.
Verified on Ubuntu 24.04 against two loop devices, driving read_vars ->
create_partitions -> make_swraid -> encrypt_partitions:
patch as-is + 'yes' CRYPT=1 0 crypted lines -> plaintext
patch + this + 'yes' CRYPT=1 1 crypted line -> encrypted
patch + this + 'crypt' CRYPT=0 0 crypted lines -> plaintext (intended)
upstream + 'crypt' CRYPT=1 2 crypted lines -> encrypted (+ the /var overmatch)
Mixed RAID levels are unaffected: md0 and md1 raid1, md2 raid0 with
array_raidlevel=0 on the last PART line.
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.
Hi @cyberplant — I tested hetzneronline#85 because I want exactly the layout I asked about in that thread
back in 2024 (
/var/lib/longhornon its own RAID level). The good news first: the RAID partworks. Against current upstream HEAD (e15b5ea) the patch still applies cleanly, and driving
the real
read_vars→create_partitions→make_swraidchain against two loop devices givesexactly what it promises:
The
# HZ-CFG:marker lands only on the intended fstab line, and the override is correctlyscoped per array.
The problem this PR fixes
Making the 5th column authoritative (
yesinstead of "any non-empty value") was necessary —you need a placeholder there to reach the 6th column, and under the old test every placeholder
would have switched LUKS on. But
create_partitionsstill decides the fstabcryptedmarker bygrepping the raw PART line for the string
crypt, and that half wasn't moved along.Since
encrypt_partitions()iterates the fstab looking forcrypted, the two halves nolonger meet:
$CRYPTgateencrypt_partitionscryptedlinesyesyescryptcryptRow 1 is the bad one: the installer prints "Encrypt partitions and create /etc/crypttab", the
function runs, and nothing gets encrypted. No error, no non-zero exit. With hetzneronline#85 as it stands
there is no 5th-column value that satisfies both paths.
The fix
One line — read the same field both halves should have been reading:
Side effect: it also fixes a pre-existing upstream bug
That grep matched by substring against the whole part-lines file. With
upstream produces:
/vargets encrypted becausegrep "/var"matches the/var/logline. With this patch only/var/logis marked. That bug predates hetzneronline#85; the fix removes it as a by-product.Note on the description
The PR description says
SWRAIDLEVEL=0, but the variable that actually matters isarray_raidlevel(upstream already setslocal array_raidlevel="$SWRAIDLEVEL"per iteration,and the override replaces that local). Only the tested example in your first comment is correct —
might be worth fixing in the description so nobody copies the wrong one.
How I tested this (repro script)
Ubuntu 24.04 VM, two loop devices as DRIVE1/DRIVE2. Two environment stubs were needed, neither
touching the logic under test:
getdrives()(it scans/sys/blockfornvme*/sd*, whichloop devices never match) and symlinks
/dev/loopNM -> /dev/loopNpM, because the partition-namehelper only emits the
pseparator for nvme and by-id paths.The control group carries the proof: the same run against unpatched upstream with
cryptencrypts, so a "not encrypted" result isn't just the test measuring itself.
There's no test suite in the repo to extend, so this is a manual repro. If you'd like it as a
committed script (something runnable against loop devices, no hardware needed), say the word and
I'll add it as a second commit — happy to keep this PR to the one-liner otherwise.