Processing passed XML for payload download is broken

[pothos]

Description

In the postinstall action we use --input-xml /var/lib/update_engine/prefs/full-response to download_sysext to work on the Omaha response and download a given extension. Now it fails to process the given extension and returns with exit code 0 despite doing nothing.

Impact

This means that we fall back to downloading from bincache/the release server but that's bad because this breaks self hosting with Nebraska or also supplying payloads directly via flatcar-update when either no public internet access is available or when custom images are used that are not official releases or when bincache is cleaned up.

Environment and steps to reproduce

1. Set-up: Use any Flatcar image as qemu VM
2. Task: Copy flatcar_test_update.gz flatcar_test_update-flatcar-python.gz flatcar_test_update-oem-qemu.gz to the VM for a dev build that's not on bincache.
3. Action(s):
   a. sudo flatcar-update -D -V 9999.9.9 -P flatcar_test_update.gz -E flatcar_test_update-flatcar-python.gz -E flatcar_test_update-oem-qemu.gz
   b. See that it fails to update for a dev build not on bincache (it passed for the upcoming 4487.0.0 Alpha and for a dev build/nightly on bincache) and check logs which now contain mv: cannot stat '/var/lib/update_engine/ue-rs//flatcar-python.raw': No such file or directory and Falling back to bincache-server for extension 'flatcar-python' or similar for the oem image

Expected behavior

No fallback download

Additional information

I think the regression was part of these updates: flatcar/scripts#3310

[dongsupark]

Thanks for reporting the issue.

The regression was caused by #87. That has other regressions around payload-url, which was already fixed in #90. But that was just a part of the bug.

Created a WIP PR to fix the part 2, #93.

I want to test that locally, however, I am having a little hard time creating an input xml that works for that. Will try tomorrow again.

What I am doing is basically like that:

$ cat uetest1/full-response.xml
<response protocol="3.0" server="flatcar-update"><daystart elapsed_seconds="0"></daystart>
<app appid="{e96281a6-d1af-4bde-9a0a-97b76e56dc57}" status="ok"><ping status="ok"></ping>
<updatecheck status="ok"><urls><url codebase="http://localhost:9091/"></url></urls>
<manifest version="9999.9.9">
<packages>
<package name="flatcar_production_update.gz" hash="8GtC2/dIhCg6cp6jiQjoMNrMSm8="  size="490678005" required="true"></package>
<package name="flatcar-python.gz" hash="FF+ci4cThKAdESIk5GbSgrN0Q7A=" hash_sha256="85c7f1baa8bb88aeaad71c58541c3857356c419df2ae0114f061ac41a7528647" size="20435562" required="false"></package>
<package name="oem-qemu.gz" hash="qU0rMxxD4n3LEnn1i5LrWLRptv8=" hash_sha256="512b3e9b8a707bd1e45ecf3ec10c8263ca5baae349ecf3cc43440e473995bd44" size="2065" required="false"></package>
</packages>
<actions><action event="postinstall" sha256="rciibhCaKYRr9RoTKJFVpk+tJvSp2PumLdVj09S/4k0=" DisablePayloadBackoff="true"></action></actions></manifest>
</updatecheck><event status="ok"></event></app></response>

$ RUST_LOG=debug ./target/debug/download_sysext --pubkey-file .../official-v2.pub.pem --output-dir /tmp/outdir --input-xml ./uetest1/full-response.xml
# that fails with XML parsing error

[pothos]

The XML file from /var/lib/update_engine/prefs/full-response while flatcar-update runs should work.

[pothos]

I think your file misses <?xml version="1.0" encoding="UTF-8"?> as first line - Edit: No, makes no difference. But I also didn't get the parsing error

[pothos]

I created this kola PR to catch a similar regression in the future: flatcar/mantle#678
Also handy now already to validate that this is fixed.

[dongsupark]

The XML file from /var/lib/update_engine/prefs/full-response while flatcar-update runs should work.

That is basically how I got the input XML file for my testing.

According to my debugging so far, the XML parsing error disappears when I revert the PR #88. So it has something to do with the recent refactoring around XML.

However it is not simple to do bisect to find out the culprit, because the PR has 31 commits that have interconnected dependencies. Reverting certain commits result in build errors or other strange runtime issues.

[dongsupark]

The regression consists of multiple issues:

1. Issues of passing command-line flag --input-xml into download module. That is already fixed in download_sysext: fix passing XML data with --input-xml #93.
2. Issues of defining child nodes of xml tags in omaha/src/response.rs. That was caused by the refactoring PR Omaha crate improvements #88. Fix would be to define child tags correctly for packages and actions.
3. Issues of supporting only hex strings. Actually we should support also base64, because the input hashes are supposed to be given as base64 encoded strings. The refactoring PR removed the base64 parts, so it breaks use cases.