Rollback Fixes#2213
Conversation
There was a problem hiding this comment.
Code Review
This pull request implements dropping staged deployments on rollback to match ostree's behavior, updates boot entry sorting logic to sort based on the bootloader type (by sort-key for systemd-boot and by filename for GRUB), and adds corresponding unit and integration tests. The reviewer identified a robustness issue in rollback.rs where stale staged entries might not be cleaned up if host.status.staged is None and the rollback could fail unnecessarily if the staged deployment file is already missing. Additionally, a maintainability issue was found in status.rs where the comments in the GRUB sorting test contradict the actual assertions and sorting behavior.
a266a4c to
e07ffbd
Compare
|
GHA seems to be having issues |
| // Ostree will drop any staged deployment on rollback | ||
| // We follow the same approach for now | ||
| if let Some(..) = &host.status.staged { | ||
| println!("Removing currently staged deployment"); |
There was a problem hiding this comment.
I'd like to try to centralize reporting more in the future and get away from just random println!. This isn't the only case of course.
One thing we could probably do instead here is log to the journal, which would have other benefits.
e07ffbd to
3f8eaf8
Compare
Similar to ostree, if we find any staged deployment while performing a rollback, we'll get rid of the staged deployment. The staged deployment still exists on disk and will be GC'd later Fixes: bootc-dev#2208 Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
Add a case in the rollback test which tests rollback when there is a staged deployment present. This is a test for bootc-dev#2208 Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
3f8eaf8 to
9ac67f1
Compare
Update `get_sorted_type1_boot_entries_helper` to implement sorting
logic based on bootloader type
- systemd-boot: Sort by sort-key (using BLSConfig::cmp which handles
sort-key ascending, then version descending)
- GRUB: Sort by filename in descending order (ignoring sort-key fields)
Unit Tests generated by ClaudeCode (Opus)
Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
Instead of blindly selecting the "second" one in a list of sorted boot entries as the rollback and failing if there are more than one rollback candidate, sort the rollback candidates in the same order as the boot entries and take the first one as rollback. All the remaining deployments become `other_deployments`. This is especially useful if and when we implement pinned deployments for composefs Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
2408645 to
9e127ff
Compare
9e127ff to
830e90a
Compare
If we are unable to find the origin file for a deployment, we were immediately exiting with an error which rendered any bootc operation useless. Instead, just log a warning in the journal and continue with the specified operation so that we don't completely stop working if the system is in an unpredictable state Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
830e90a to
d08c253
Compare
cfs/rollback: Remove staged entry on rollback
Similar to ostree, if we find any staged deployment while performing
a rollback, we'll get rid of the staged deployment. The staged
deployment still exists on disk and will be GC'd later
Fixes: #2208
cfs/status: Implement bootloader-specific sorting
Update
get_sorted_type1_boot_entries_helperto implement sortinglogic based on bootloader type
sort-key ascending, then version descending)
Unit Tests generated by ClaudeCode (Opus)