action #47387
closed[sle][functional][y] test fails in partitioning_raid - incorrect file system type assigned to /boot/efi mount point
0%
Description
Observation¶
So, that's again issue when we have asserted selected FS and then another key press reaches system later.
https://openqa.suse.de/tests/2450878#step/partitioning_raid/160 Here we have correctly selected FAT, but then we can see that btrfs was selected in the end.
openQA test in scenario OpenQA::Schema::Result::TestSuites=HASH(0xba37ff8) fails in
partitioning_raid
Reproducible¶
Fails since (at least) Build 0122 (current job)
Expected result¶
Last good: 0120 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by riafarov about 5 years ago
- Description updated (diff)
- Due date set to 2019-03-12
- Status changed from New to Workable
Updated by JERiveraMoya about 5 years ago
- Status changed from Workable to In Progress
Created new needle partitioning_raid-format_fat_UEFI-20190225 where an area for the file system FAT32 is included as well. Deleted the current one.
VR: sle-12-SP5-RAID5@aarch64
Updated by JERiveraMoya about 5 years ago
Gathering statistics: 25 runs -> all look good
Updated by JERiveraMoya about 5 years ago
- Status changed from In Progress to Feedback
Updated by riafarov about 5 years ago
- Status changed from Feedback to Resolved
I doubt that needle resolves original issue, as it would match in case of mentioned job, but we still might get additional send_key reaching the system afterwards. But seems it's rare issue anyways, so let's resolve.
Updated by JERiveraMoya about 5 years ago
My assumption is that we sometimes send keys when Filesystem id control below is refreshing after we modify file system and it is the reason to this strange effect.
Thanks, I will do something more specific if does not work this theory.