action #49718
closed[functional][y] test fails in validate_lvm_encrypt finding boot partition in aarch64
0%
Description
Observation¶
openQA test in scenario sle-12-SP5-Server-DVD-aarch64-lvm-full-encrypt@aarch64 fails in
validate_lvm_encrypt
After introducing new validation for lvm in SLE12SP5 it is found this error finding boot partition in device mapper: Test died: command 'df | grep -P "^\/dev/\mapper\/\w+"| grep boot' The error seems to be related only with aarch64. There is some differences in the partitioning layout, boot volume for example, take a look aarch64 vs x86_64 maybe related.
Test suite works fine for SLE 15 SP1 as well, which can help to bisect the root cause.
Test suite description¶
Maintainer: riafarov poo#15926
(crypt-)LVM installations can take longer, especially on non-x86_64 architectures. Test suite creates encrypted lvm partition using expert partitioner and performs installation.
Reproducible¶
Fails since (at least) Build 0132 (current job)
Expected result¶
Last good: 0127 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by SLindoMansilla about 5 years ago
- Subject changed from test fails in validate_lvm_encrypt finding boot partition in aarch64 to [functional][y] test fails in validate_lvm_encrypt finding boot partition in aarch64
As a result of backlog triaging (see https://progress.opensuse.org/projects/openqatests/wiki#ticket-backlog-triaging for more information).
Please, feel free to adjust the category or the "[label]" if you think different.
Updated by JERiveraMoya about 5 years ago
Thanks! I forgot totally labels for a moment :)
Updated by riafarov about 5 years ago
- Priority changed from Normal to High
Increasing priority as is a recent regression.
Updated by riafarov about 5 years ago
- Description updated (diff)
- Estimated time set to 3.00 h
Updated by JRivrain about 5 years ago
On sle12+aarch64, the boot partition is separated. I did a change but I think the lvm-full-encrypt should in fact be excluded for this case, since it is actually doing the same as lvm-encrypt-separate-boot. It seems to be set by the partitioner itself.
temporary PR https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/7194
Updated by JRivrain about 5 years ago
- Status changed from Workable to In Progress
Updated by JRivrain about 5 years ago
So, create_new_partition_table in partition_setup.pm does this:
my ($table_type) = shift // (is_storage_ng) ? 'GPT' : 'MSDOS';
So it will create a MSDOS partition if we are not using storage_ng (eg on sle12)
But later in the function:
if (!get_var('UEFI') && !check_var('BACKEND', 's390x') || is_storage_ng)
[choose GPT or MSDOS, set size...]
For sle 12 on aarch64, the installer does not propose MSDOS as partition table as UEFI si set, so only in that case we have GPT partition table and /boot/efi on a separate vfat partition.
Sle12 does not create a /boot/grub2/(arch)-efi btrfs subvolume if there is an EFI partition (but it does if there is no efi partition) and this causes the test to fail. sle15 creates a /boot/grub2/(arch)-efi subvolume, and also creates a 2M "bios" partition that does not get mounted.
EDIT: sle12 on x86_64 does create a boot subvolume: http://eris.suse.cz/tests/13030#step/partitioning_full_lvm/62 (thanks Martin for the VR). So That is probably a bug.
**Remark: sle12 with UEFI probably boots using CSM, because AFAIK, UEFI needs a separate EFI partition to work properly. If I'm right, this makes the fate test case more or less invalid.
Updated by JRivrain about 5 years ago
- Status changed from In Progress to Feedback
EDIT: sle12 on x86_64 does create a boot subvolume: http://eris.suse.cz/tests/13030#step/partitioning_full_lvm/62 (thanks Martin for the VR). So That is probably a bug.
The devs do not consider this as a bug, so let's just work around it. I removed [WIP] from the PR
Updated by riafarov about 5 years ago
- Due date changed from 2019-04-09 to 2019-04-23
VR on osd is missing.
Updated by riafarov about 5 years ago
No deployment yet: https://confluence.suse.de/pages/viewpage.action?pageId=194052156
Updated by riafarov about 5 years ago
We have a bug on arm, which blocks execution of the test module. So let's resolve and act on the issues step by step.