Fix & enable LUKS tests #1013
Fix & enable LUKS tests #1013
Conversation
| # Ignore unused variable parsed out by tooling scripts as test tags metadata | ||
| # shellcheck disable=SC2034 | ||
| TESTTYPE="skip-on-rhel storage partition luks" |
There was a problem hiding this comment.
part-luks-* are failing for me for rhel, (I've just run them locally on rhel9 and all failed with RESULT not found). That is why I enabled them only on Fedora. Are they stable for you? I wonder if it can be just my environment (even though the tests are run in container)?
There was a problem hiding this comment.
It seems to work fine for me:
$ ./containers/runner/launch part-luks-1 -p rhel9
...
TEST | RESULT | EXPLANATION
--------------------------------------------------------+------------+-------------------------------------------
part-luks-1 | SUCCESS |
===================================================================================================================================
Test suite for kickstart tests summary:
===================================================================================================================================
# TOTAL: 1
# PASS: 1
# FAILED: 0
# TIMED OUT: 0
===================================================================================================================================
+ exit 0
$ file data/images/boot.iso
data/images/boot.iso: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'RHEL-9-3-0-BaseOS-x86_64' (bootable)
There was a problem hiding this comment.
Ah, I've just realized that my kstest runner container is 17 months (!) old. Let me try with something more recent :)
There was a problem hiding this comment.
Indeed, it works with current container!
There was a problem hiding this comment.
So let's enable the tests and see. If they show up unstable again, we can disable them. I won't do any harm.
| md_device=$(run_with_timeout ${COPY_FROM_IMAGE_TIMEOUT} "guestfish --ro ${disks} launch : list-md-devices" 2>&1) | ||
| md_devices_count=$(wc -l <<< ${md_device}) | ||
| if [ ${md_devices_count} -ne 1 ]; then | ||
| echo "Only 1 RAID device supported by encrypted_file_encrypted_raid()" > ${dir}/RESULT |
There was a problem hiding this comment.
It could be useful to report what devices were found.
|
@jstodola I'm not sure if such a message would be visible in the test output. However, I just noticed I forgot there two debug messages which I should likely get rid of. |
jikortus
force-pushed
the
reenable-luks-tests
branch
from
880ebb8 to
f9dc169
Compare
This fixes the issue with copying out the RESULT file from encrypted partitionings properly and reenables the LUKS tests.
jikortus
force-pushed
the
reenable-luks-tests
branch
from
f9dc169 to
c96d7e3
Compare
|
OK, now after a discussion with @jstodola, I found out I originally misunderstood his comment, which is obvious to me now that I looked clearer where it was located. I fixed the related piece of code to output the MD devices found to |
The code copying RESULT file out of encrypted partitionings has been amended/fixed, so the LUKS tests work OK now.
The way guestfish is handled to do this task is somewhat cumbersome, but I couldn't find with a better solution. guestfish is not able to autodetect the partitioning and open/mount the LUKS container, so a series of explicit commands is needed to do so. I tried to combine this approach with --keys-from-stdin or --key 🔑passphrase, but neither option worked for me.
As I have only fairly limited experience with guestfish so far, I'm not able to tell whether my assumption on how to use the parameters is wrong, whether the options collide with 'manually' entering the commands, or this is a bug. If the latter is the case, I can create a BZ against libguestfs to cover this.