|
Bugzilla – Full Text Bug Listing |
| Summary: | [Build 20230611] openQA test fails in snapper_create: btrfsprogs 6.3.1 behaves differently (?) | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Dominique Leuenberger <dimstar> |
| Component: | Other | Assignee: | David Sterba <dsterba> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | dimstar, fvogt, guillaume.gardet, wqu |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| URL: | https://openqa.opensuse.org/tests/3351759/modules/snapper_create/steps/169 | ||
| Whiteboard: | |||
| Found By: | openQA | Services Priority: | |
| Business Priority: | Blocker: | Yes | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Dominique Leuenberger
2023-06-12 07:50:37 UTC
This bug is blocking btrfsprogs package updates but I haven't found any commit or other reason that would cause the openQA test failure. Is it possible to get fresh test results? I can't find a recent version of the opensuse-Tumbleweed-DVD-x86_64 build job on openqa.opensuse.org, the Tumbleweed tests don't have the snapper tests. (In reply to David Sterba from comment #1) > This bug is blocking btrfsprogs package updates but I haven't found any > commit or other reason that would cause the openQA test failure. Is it > possible to get fresh test results? I can't find a recent version of the > opensuse-Tumbleweed-DVD-x86_64 build job on openqa.opensuse.org, the > Tumbleweed tests don't have the snapper tests. https://openqa.opensuse.org/tests/3526753#step/snapper_create/1 This is btrfsprogs 6.3 - 6.3.1 had been reverted due to bug https://bugzilla.opensuse.org/show_bug.cgi?id=1212217 (In reply to Dominique Leuenberger from comment #2) > (In reply to David Sterba from comment #1) > > This bug is blocking btrfsprogs package updates but I haven't found any > > commit or other reason that would cause the openQA test failure. Is it > > possible to get fresh test results? I can't find a recent version of the > > opensuse-Tumbleweed-DVD-x86_64 build job on openqa.opensuse.org, the > > Tumbleweed tests don't have the snapper tests. > > https://openqa.opensuse.org/tests/3526753#step/snapper_create/1 > > This is btrfsprogs 6.3 - 6.3.1 had been reverted due to bug > https://bugzilla.opensuse.org/show_bug.cgi?id=1212217 erm.. that is circular :) The test runs on openQA, that';s for sure. We can tr to clone that job with an external addon repo injected to test with btrfsprogs 6.3.1 - fact is though: reverting btrfsprogs alone made the tests pass again or optionally - grab the qcow2 image linked in https://openqa.opensuse.org/tests/3526753#step/snapper_create/1 assets you can boot this, update btrfsprogs and re-inject this qcow into a local openQA instance to let it rerun the tests - or try to replay what the test does (there is of course always the option of the test doing something wrong) btrfsprogs 6.3.3 was checked in to Factory - and openQA fails again: https://openqa.opensuse.org/tests/3541566#step/snapper_create/172 libbtrfs0 broke ABI, so snapper does garbage. Commit 83ab92512e79a5f8e3d2afd06e0c28d41061fd32 needs to be redone or the soversion bumped. In /var/log/snapper.log, it's visible that btrfs send/receive ioctls for snapshot diffing failed with ENOENT, so snapper used the fallback of manually comparing the files inside. This takes much longer, so races resulting in errors like "Config in use" are more likely. With strace it was visible that snapper passed parent_root=0 to BTRFS_IOC_SEND, resulting in -ENOENT. With gdb I stepped through the code and noticed that the contents of struct subvol_info returned to snapper are at an offset, so the root_id member was not where snapper expected it to be, so it read 0 instead. Fabian is right, I didn't notice the change of subvol_info is at the beginning of the structure. Thus it would lead to a incompatible change of API. Would anyone mind to test if the following patch solves the regression? https://lore.kernel.org/linux-btrfs/4d54ca8fb8605704260aad205acd6185fe73fb49.1693561063.git.wqu@suse.com/T/#u (In reply to Wenruo Qu from comment #8) > Fabian is right, I didn't notice the change of subvol_info is at the > beginning of the structure. > > Thus it would lead to a incompatible change of API. > > Would anyone mind to test if the following patch solves the regression? > https://lore.kernel.org/linux-btrfs/4d54ca8fb8605704260aad205acd6185fe73fb49. > 1693561063.git.wqu@suse.com/T/#u It does. Is it intentional that the members of subvol_uuid_search are now prefixed with "__"? This breaks API and the "__" prefix is also invalid according to the C standard as such identifiers are reserved by the standard. Thanks Fabian for tracking it down. I'll do a full revert of the patch so the ABI is on the 6.3 level again. (In reply to Fabian Vogt from comment #9) > (In reply to Wenruo Qu from comment #8) > > Fabian is right, I didn't notice the change of subvol_info is at the > > beginning of the structure. > > > > Thus it would lead to a incompatible change of API. > > > > Would anyone mind to test if the following patch solves the regression? > > https://lore.kernel.org/linux-btrfs/4d54ca8fb8605704260aad205acd6185fe73fb49. > > 1693561063.git.wqu@suse.com/T/#u > > It does. Is it intentional that the members of subvol_uuid_search are now > prefixed with "__"? This breaks API and the "__" prefix is also invalid > according to the C standard as such identifiers are reserved by the standard. It was to discourage any usage of the old members. But since David is going to revert that one, it doesn't matter anymore. Thanks for pinning down the breakage. Version 6.5 has the fix and is now in the OBS pipeline. (In reply to David Sterba from comment #12) > Version 6.5 has the fix and is now in the OBS pipeline. this has been fixed; thanks all for working on this and identifying the underlying ABI break. |