Revert "Move the pending_config* files from /tmp/ to /etc/sonic/ (#25215)"#26800
Revert "Move the pending_config* files from /tmp/ to /etc/sonic/ (#25215)"#26800xwjiang-ms wants to merge 2 commits into
Conversation
…)" This reverts commit 9a62417.
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Pull request overview
Reverts PR #25215 by moving the pending_config_* marker files back from /etc/sonic/ to /tmp/, restoring the prior first-boot/config-migration signaling behavior to address reboot-related test failures.
Changes:
- Update
rc.localto createpending_config_migration/pending_config_initializationunder/tmp/. - Update
config-setupto check/remove the pending config markers under/tmp/. - Update
docker_image_ctl.j2to detect pending config markers under/tmp/when settingCONFIG_DB_INITIALIZED.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| files/image_config/platform/rc.local | Reverts pending-config marker creation back to /tmp/ during first boot. |
| files/image_config/config-setup/config-setup | Reverts pending-config marker checks/removals back to /tmp/. |
| files/build_templates/docker_image_ctl.j2 | Reverts database post-start pending-config marker detection back to /tmp/. |
Comments suppressed due to low confidence (1)
files/build_templates/docker_image_ctl.j2:320
- Checking for pending_config_* only under /tmp means database startup will not detect a pending first-boot config operation after an unexpected reboot (the /tmp markers are cleared). Consider using a persistent signal (or inferring from /etc/sonic/old_config) so CONFIG_DB_INITIALIZED is not incorrectly set to "1" on the next boot before config-setup finishes migration/initialization.
if [ -e /tmp/pending_config_migration ] || [ -e /tmp/pending_config_initialization ]; then
# this is first boot to a new image, config-setup execution is pending.
# for warmboot case, DB is loaded but migration is still pending
# For firstbboot/fast/cold reboot case, DB contains nothing at this point
# unset CONFIG_DB_INITIALIZED to indicate pending config load and migration
| # and create a flag in /tmp/ | ||
| if [ -d /host/old_config ]; then | ||
| mv -f /host/old_config /etc/sonic/ | ||
| rm -rf /etc/sonic/old_config/old_config | ||
| touch /etc/sonic/pending_config_migration | ||
| touch /tmp/pending_config_migration |
There was a problem hiding this comment.
Storing the pending_config_* flags under /tmp makes them non-persistent across an unexpected reboot between rc.local and config-setup, reintroducing the migration/initialization loss scenario that PR #25215 addressed. Consider using a persistent trigger (e.g., a flag under /etc/sonic or /host) or making config-setup infer migration from the persisted /etc/sonic/old_config contents instead of relying on a volatile /tmp marker.
| check_system_warm_boot | ||
| if [ -e /etc/sonic/pending_config_migration ] || [ -e ${CONFIG_SETUP_POST_MIGRATION_FLAG} ]; then | ||
| if [ -e /tmp/pending_config_migration ] || [ -e ${CONFIG_SETUP_POST_MIGRATION_FLAG} ]; then | ||
| do_config_migration |
There was a problem hiding this comment.
Using /tmp for pending_config_migration as the sole trigger means a reboot before config-setup runs will clear the marker and skip migration. If the goal is to avoid persistent flags, consider deriving the need for migration from durable state (e.g., presence of /etc/sonic/old_config/* artifacts) so migration still occurs after an unexpected reboot.
|
/azpw run |
|
Retrying failed(or canceled) jobs... |
|
/azp run |
|
You have several pipelines (over 10) configured to build pull requests in this repository. Specify which pipelines you would like to run by using /azp run [pipelines] command. You can specify multiple pipelines using a comma separated list. |
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Revert PR #25215 since it's causing dns/static_dns/test_static_dns.py, reboot/test_reboot_blocking_mode.py and platform_tests/test_reboot.py fail on multi-asic topology
For test_static_dns:
For test_reboot_blocking_mode:
For test_reboot: