Closed sairon closed 4 weeks ago
[!WARNING]
Rate limit exceeded
@sairon has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 20 minutes and 7 seconds before requesting another review.
How to resolve this issue?
After the wait time has elapsed, a review can be triggered using the `@coderabbitai review` command as a PR comment. Alternatively, push new commits to this PR. We recommend that you space out your commits to avoid hitting the rate limit.How do rate limits work?
CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our [FAQ](https://coderabbit.ai/docs/faq) for further information.Commits
Files that changed from the base of the PR and between 5f4aaad0b18a3beb603223c58bbe2b356a24888a and 8b6830bf19e1c7d4d9690e52cd74fe7fc2e483e1.
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks :+1:
Proposed change
When boot slot is selected manually in GRUB, the system boots into this slot and marks it as good. However, the boot order is not changed, so in the next boot (after an explicit or unexpected reboot) HAOS returns to the version in the other slot. This might be confusing because if the system has been running for some time, the user can forget they have changed the boot slot to fix issue they had.
This gets more confusing if the "other" boot slot is selected manually three times in a row. Let's say we have ORDER="A B". This means that every time GRUB starts, it wants to boot slot A. If the slot B is selected instead, only A_TRY is incremented, system boots into slot B and marks slot B as good (B_OK=1, B_TRY=0). On another boot, this repeats, yet A_TRY is incremented again. Until it reaches 3, the slot A would be always chosen automatically, only after that it would boot to slot B, presuming slot A is dead. The ORDER variable will be still unchanged though.
This commit only makes sure that when the system is marked as healthy, the slot is both marked as good AND active, updating the ORDER variable as well. Because the X_TRY counter is incremented by GRUB, if we want the other slot not to be marked as bad, we need to adjust the logic in OS's grub.cfg as well, because Supervisor can't know whether it's apppropriate to change other slot's state or not.
I also took the courtesy to adjust the logging a bit, to include the stack trace in the error log if marking the slot fails somehow.
Type of change
Additional information
Checklist
ruff format supervisor tests
)If API endpoints or add-on configuration are added/changed:
Summary by CodeRabbit
New Features
mark_healthy
functionality to allow marking multiple states for the booted partition, improving operational flexibility.Bug Fixes
Improvements