update_engine/bootengine: Clean up incomplete move target#1272
Conversation
|
I didn't bump the ebuild revision because it always creates conflicts when backporting. |
|
Build action triggered: https://github.com/flatcar/scripts/actions/runs/6533079643 |
I know it's a PITA, but we already had weird problems due to not bumping the revisions, so please do bump them. I'm wondering though if by dropping the |
This pulls in flatcar/update_engine#29 and flatcar/bootengine#76 to fix the problem of not being able to update from ≤ 3619.0.0 on Azure.
554e443 to
aaecc8f
Compare
krnowak
left a comment
There was a problem hiding this comment.
Updated the PR with the commit hashes from merged PRs. Pulling it in into the main branch for the release this week.
update_engine/bootengine: Clean up incomplete move target
|
For now, backported to alpha only. Probably no point in backporting to beta, as we will do a new beta release from current alpha release this week, so 3732 becomes dead. |
|
Thanks! |
This pulls in flatcar/update_engine#29 and flatcar/bootengine#76
to fix the problem of not being able to update from ≤ 3619.0.0 on Azure.
How to use
Backport to Alpha/Beta because this fixes the problem of not being able to update from ≤ 3619.0.0
Testing done
Jenkins
Provision Flatcar Azure 3619.0.0, then update once, e.g.
sudo flatcar-update -V 3732.0.0, then update to this built dev image and it should work (sudo flatcar-update -P flatcar_test_update.gz -E flatcar_test_update-oem-azure.gz -D -V 1.2.3), while updating to 3745.0.0 or 3732.1.0 (must not the version you are on) would fail and fill the OEM disk.This also tested the bootengine PR because it will try to move the dev sysext to the OEM partition as active OEM sysext but that fails because the old OEM files only get deleted at the end of the preparations. Moving the inactive prod OEM sysext out would normally be done and could have created enough space but in this case not because the symlink under
/etcisn't set up and we don't mount the inactive/usrto find out what version it is. Hence the moval of the active OEM only happens after the next boot.changelog/directory (user-facing change, bug fix, security fix, update)/bootand/usrsize, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.