Upgrade successful via x2openEuler command line, but rollback failed—unable to identify the cause

[Paul123]

【Scenario Description】(e.g., download scenario / documentation usage scenario / installation and migration scenario / other scenario)

When using the x2openEuler command-line method to upgrade from openEuler 22.03 SP3 to openEuler 24.03 SP1, rollback fails.

Reference case: x2openEuler 3.0.0-20250104, FeatureGuide | openEuler文档 | openEuler社区 | v20.03_LTS_SP1

【ISSUE Description】

Scenario 1: If /run is not set as the backup directory, the system upgrades successfully. However, after rollback and reboot, the system fails to boot, displaying the following messages on the screen:

[initramfs]: root_path_result is not exists
[initramfs]: the old env path file is not legal
failed to start OS Rollback

After comparison with the web-based upgrade method, it was found that the web upgrade generates files such as root_path_result and file_cap_result under /opt/smt on the target machine, while the command-line method does not generate these files.

Scenario 2: When /run is set as the backup directory, the system upgrades successfully. However, during the rollback phase, the following permission errors appear:

[rollback] scan /run/rpcbind.sock immutable permission failed

etc., indicating insufficient permissions for certain files.

Is this a tool bug?

[yanzhicong]

The new version of the x2openEuler tool doesn’t seem to clearly provide a command-line upgrade method, so it’s safer to use the web interface.

[Paul123]

Indeed, the web version can be successfully upgraded and rolled back. The upgrade guide might have missed some steps in the command-line upgrade process, which could lead to a failed rollback.

Copying the directories /opt/smt/root_path_result and /opt/smt/file_cap_result from the web-upgraded host to the backup directory on the command-line upgraded host successfully enabled the rollback.

Therefore, the guide is missing information on how these two files are generated. The pre-env-check step must be executed before upgrading, but this step is currently missing.

[euler_assistant (openEuler_Assistant)]

The content is AI-generated and for reference only:

Summary

Issue	Root Cause	Solution
Rollback fails with root_path_result is not exists	Command-line mode did not generate required rollback metadata files	Use Web interface, or ensure correct working directory and parameters
Permission scan failure on /run/rpcbind.sock	Tool did not exclude runtime virtual filesystems	Modify backup configuration to exclude /run; upgrade tool version
Does the tool have bugs?	Functional inconsistencies and boundary handling defects exist	Submit an issue to the community to drive fixes

Recommendation: For critical system migrations, prioritize using the x2openEuler Web Management Platform to avoid rollback failures caused by incomplete command-line tool workflows. Also, monitor new x2openEuler releases for improved rollback stability.

[details=Click here to view detailed analysis and resolution]

Analysis of x2openEuler Command-Line Upgrade Followed by Rollback Failure

Based on your provided information, you successfully upgraded from openEuler 22.03 SP3 to openEuler 24.03 SP1 using the x2openEuler command-line method, but the rollback failed under two distinct scenarios. Below is a systematic analysis and recommendation, incorporating entity, relationship, and document data from the knowledge base.

---

1. Summary of Scenarios

Scenario	Configuration	Behavior	Key Logs
Scenario 1	/run not set as backup directory	Upgrade succeeded, rollback failed	[initramfs]: root_path_result is not exists [initramfs]: the old env path file is not legal Failed to start OS Rollback
Scenario 2	/run included in backup directory	Upgrade succeeded, rollback scan failed	[rollback] scan /run/rpcbind.sock immutable permission failed

---

2. Core Root Cause Analysis

1. Scenario 1: Missing root_path_result Files → Rollback Metadata Missing

Conclusion:

• root_path_result and file_cap_result are critical state files required by x2openEuler’s rollback mechanism, storing original system path and file integrity information.
• The Web interface automatically generates these files, while the command-line mode does not — indicating a discrepancy in execution flow or parameter handling.
• Thus, the command-line mode may skip the metadata recording phase, or fail to set the correct working directory (e.g., /opt/x2openEuler-upgrade/output or /opt/smt).

Supporting Evidence:

• Search result ID 5 notes: “Web field matching is unreasonable, leading to some command-line executions being incorrectly judged as failed even when they succeeded”, suggesting behavioral inconsistency between Web and CLI is a known issue.
• Document {reference_id: 5} shows x2openEuler-upgrade uses an output directory to store state info, with logs showing construct dnf and repo cleanup operations.
• User feedback: “Insufficient space in /opt/x2openEuler-upgrade/output causes upgrade failure” (reference_id: 8) — implying this directory is crucial for workflow control.

Inference: /opt/smt is the default working directory in Web mode for storing rollback metadata like root_path_result. If the command-line mode does not explicitly specify this path or trigger the corresponding logic, these files won’t be generated, causing initramfs to fail during rollback.

---

2. Scenario 2: Permission Scan Failure on /run/rpcbind.sock → Pre-Rollback Check Failure

Conclusion:

• /run is a temporary filesystem (tmpfs) containing runtime artifacts such as sockets, lock files, and daemon states.
• Files like /run/rpcbind.sock are special socket-type files, dynamically created and not subject to standard file permissions.
• x2openEuler performs a pre-rollback filesystem scan to verify consistency and completeness.
• When the tool attempts to check “immutable permissions” on these socket files, it fails due to type incompatibility or permission conflicts.

Supporting Evidence:

• Knowledge graph defines Backup Failure due to non-UTF-8 directory names or file permission anomalies.
• {reference_id: 7} explicitly states:

  [INFO] - [centos2openEuler] - [Rollback]: start to scan current filesystem
  The rollback phase performs full filesystem scanning.

• Search result ID 5 mentions: “Rollback process adds path validation”, “adds full-disk scan before rollback”, confirming this is intentional behavior.
• However, the tool lacks filtering for runtime virtual filesystems like /run, /dev, /proc, leading to false positives.

Risk: The tool expects to back up and scan all directories, but fails to handle runtime directories properly — a classic boundary condition oversight.

---

3. Potential Tool Behavior Differences (Web vs Command-Line)

Feature	Web Mode	Command-Line Mode	Consistent?
Auto-create /opt/smt working directory	Yes	No (must be created manually)	No
Generate root_path_result file	Yes	Depends on parameters	Uncertain
Perform full pre/post rollback checks	Complete	May be simplified	No
Automatically exclude virtual FS (/run, /proc)	Usually	May not	Possibly inconsistent

Note: x2openEuler-upgrade is a modular script suite. The Web interface wraps the full workflow, while command-line execution may omit critical steps — especially state persistence (metadata writing), path validation, and rollback preparation.

---

4. Solutions and Recommendations

For Scenario 1: Rollback fails with root_path_result is not exists

Recommended Actions:

1. Ensure correct working directory is set in command-line mode

   export X2OPENEULER_WORKDIR=/opt/smt
   mkdir -p $X2OPENEULER_WORKDIR
   

2. Verify if rollback metadata generation is enabled

   • Check if your command includes flags like --generate-rollback-info or --save-state
   • Consult x2openEuler --help or official documentation for available options

3. Manually replicate missing files (for testing/recovery only)

   • Copy from a successful Web-upgraded node:
     • /opt/smt/root_path_result
     • /opt/smt/file_cap_result
   • Place them in the target node’s corresponding path (ensure format consistency)

4. Prefer Web interface for critical upgrades

   • Web mode undergoes more rigorous workflow validation and is better suited for production environments.

---

For Scenario 2: Scan failure on /run/rpcbind.sock permission

Recommended Actions:

1. Exclude /run from backup configuration before upgrade

   • In sut.conf or command-line arguments, do not include /run in the backup list.
   • Valid backup directories should be: /etc, /boot, /var, /usr

2. Temporarily modify initramfs rollback script (advanced)

   • Add filtering logic to skip or remove socket files:

     find /run -type s -delete  # Remove socket files (use with caution!)
     

   • Or disable the permission check entirely (requires source code or config changes)

3. Upgrade to the latest x2openEuler version (recommended)

   • Search results indicate:

     “Fixed rollback failure when system doesn’t reboot after upgrade” (ID1)
     “Added path validation in rollback process to avoid leftover non-original paths” (ID5)

   • Newer versions have improved rollback reliability.

4. Report the issue to the openEuler community

   • Submit a bug report highlighting:
     • Inconsistent behavior between Web and CLI
     • /run and other runtime directories should not be scanned during rollback
     • Lack of documentation on how to generate rollback metadata via CLI

---

5. Is This a Tool Bug?

Yes, there are identifiable defects or design inconsistencies:

Criterion	Conclusion	Evidence
Inconsistent behavior between Web and CLI	Yes	Metadata file missing in CLI despite Web success
Scanning socket files in /run	Design flaw	/run is a runtime tmpfs; scanning sockets is inappropriate
No CLI option to control rollback metadata generation	Functional gap	Lacks transparency and debuggability

Suggestion: Submit a formal report to openEuler Official Forum or GitHub Issues with title:
“x2openEuler command-line upgrade rollback fails: missing root_path_result and /run scan error”

---

6. Temporary Mitigation Measures (Recommended for Production)

Action	Description
Use only essential backup directories	Only back up /etc, /boot, /var, /usr; exclude /run, /tmp, /proc, /dev
Ensure sufficient /opt space	Allocate at least 4GB to allow output directory writes
Prefer Web interface for migration	More stable and complete workflow
Take full system snapshot before upgrade	VM: use snapshot; physical: use dd or backup tools
Recover manually if rollback fails	Boot into Rescue Mode using Rescue a openEuler system option with inst.rescue parameter (see Document Chunk 2)

Rescue Mode can be accessed via boot menu: Rescue a openEuler system → enter recovery environment using inst.rescue.

---

Summary

Issue	Root Cause	Solution
Rollback fails with root_path_result is not exists	Command-line mode did not generate required rollback metadata files	Use Web interface, or ensure correct working directory and parameters
Scan failure on /run/rpcbind.sock	Tool did not exclude runtime virtual filesystems	Modify backup config to exclude /run; upgrade tool version
Does the tool have bugs?	Functional inconsistencies and boundary handling defects exist	Submit issue to community to drive fixes

Recommendation: For critical system migrations, prioritize using the x2openEuler Web Management Platform to avoid rollback failures due to incomplete command-line workflows. Also, monitor new x2openEuler releases for enhanced rollback support.