flatcar-postinst does not download sysext images from URLs advertised by Nebraska
#1281
Labels
kind/bug
Something isn't working
Comments
github-project-automation
bot
moved this to 📝 Needs Triage
in Flatcar tactical, release planning, and roadmap
|
Thanks for the detailed report, good point about the possible overwriting - maybe that needs to be filtered to only be done for responses to update requests. (FYI: That doesn't happen with |
pothos
moved this from 📝 Needs Triage
to 🌱 Upcoming / Focus
in Flatcar tactical, release planning, and roadmap
|
PR in flatcar/update_engine#33 but it won't make it into the December release |
github-project-automation
bot
moved this from 🌱 Upcoming / Focus
to Implemented
in Flatcar tactical, release planning, and roadmap
|
Thank you for fixing this so quickly, @pothos 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
(Disclaimer: This might not be a bug but just me misunderstanding how to use Nebraska to advertise URLs for sysext images.)
When Nebraska sends URLs of OEM or custom extension sysext images in response to update requests from the update engine, then
flatcar-postinstshould use those URLs to download sysext images. But for me, this does not work:flatcar-postinstfalls back to hard-coded URLs of release servers even if Nebraska advertises URLs.Impact
I cannot get Flatcar to download OEM and extension images using URLs configured in a Nebraska instance.
Environment and steps to reproduce
flatcar_production_update.gz, and, under "extra files", add the metadata foroem-qemu.gz. As base URL, use a locally running file server that serves those files. Write a Butane config that instructs Flatcar to pull this update package from the Nebraska instance. Then, start a Flatcar 3760.1.0 VM with QEMU using the official QEMU image.update_engine_client -check_for_updatea. Run
update_engine_client -check_for_update.b. Observe in webserver logs that
flatcar_production_update.gzis downloaded.c. Observe in webserver logs that
oem-qemu.gzis not downloaded. Observe intcpdumpthat the VM talks toupdate.release.flatcar-linux.net, the fallback URL defined in theflatcar-postinstBash script, downloading about 2KB, which is the size ofoem-qemu.gz.oem-qemu.gz, so the installer terminates without error. (To provoke an error, a more complex setup can be used in which a custom extension is defined that is only present on the local file server. In that case,flatcar-postinstwill fail and report a 404 error because the fallback servers does not offer the custom extension image.)Expected behavior
oem-qemu.gzis downloaded from the local webserver, i.e., from the URL defined in Nebraska.Additional information
Support for this feature was added in this PR.
My speculative explanation for why this happens:
oem-qemu.gzand other files and writes the response to/var/lib/update_engine/prefs/full-response.flatcar_production_update.gzfrom the URL specified by Nebraska, i.e., the local webserver./var/lib/update_engine/prefs/full-response. The file does not contain the URLs anymore.flatcar-postinst.flatcar-postinstchecks the contents of/var/lib/update_engine/prefs/full-responseand can't find URLs in it. Thus,flatcar-postinstfalls back to using hard-coded URLs of public Flatcar servers.Excerpt from the journal (some URLs / names redacted):
I continuously printed the contents of
/var/lib/update_engine/prefs/full-response, and it's visible that the response containing the URLs is not present anymore at 13:13:23, when (as far as I understand)flatcar-postinstruns:We're very excited about this new feature! Any advice on what we are doing wrong (if it's not a bug) would be much appreciated.
The text was updated successfully, but these errors were encountered: