linuxmirrors-os

LinuxMirrors system software source switching

Quick Start

Do not immediately give a one-click command. First collect the system, network, permissions, current sources, and rollback conditions, then generate a plan of "pre-check → plan → confirm → execute → verify → rollback".

Ready to use:

• "Create a LinuxMirrors source switching and rollback plan for an Ubuntu 24.04 server."
• "Generate a non-interactive system source switching command suitable for CI, but do not execute it yet."
• "CentOS 7 is EOL; how should LinuxMirrors handle vault and EPEL?"

When to use

Use when the user explicitly wants to change GNU/Linux system software sources, restore official sources, handle EPEL/vault/EOL, or generate a source switching automation plan. Docker CE repositories, Registry Mirror, Docker Desktop, and container runtime configuration do not apply.

Intended users

• Beginners: use the interactive plan and default backup, and avoid custom branches.
• Operations staff: use pinned commits, explicit parameters, diff, maintenance windows, and rollback verification.
• CI/CD maintainers: use unattended parameters, stop conditions, and build log retention.

Prerequisites

You must know the distribution, version, architecture, network region, root/authorization status, and rollback channel; when information is missing, output only a safe-assumption plan.

How to use

Step 1: Pre-check

Read thepre-check checklist, and confirm the distribution, version, architecture, root, network region, and package manager.

Step 2: Choose mode

According tosource modeschoose mainland China,--edu、--abroad or --use-official-source true。

Step 3: Set parameters

Fromparameter referencechoose the minimum parameters, and do not invent switches.

Step 4: Draft plan

Clarify the files to be modified, backup location, package index refresh, verification, and maintenance window.

Step 5: Confirm first

Show the command but do not authorize on the user's behalf; do not run it directly in an unknown production environment.

Step 6: Verify after execution

Check the source files, package manager refresh results, and target domains; do not substitute the script exit code for all verification.

Step 7: Roll back on failure

Follow therollback guideto restore .bak or directory backups and refresh the cache again.

Capability boundaries and inapplicable scenarios

✅ Good at handling

1. Source switching planning for supported systems such as Debian/Ubuntu, Red Hat family, openSUSE, Arch, Alpine, Gentoo, and NixOS.
2. Interactive selection, unattended parameters, EPEL, security, vault, underlying system sources, and custom mirror paths.
3. Backup,--print-diff, verification, failure diagnosis, and fallback to official sources.

⚠️ Requires conditions

1. Actual execution requires a root shell, change authorization, network connectivity, and a maintenance window.
2. EOL or derivative systems require verifying the version codename, repository paths, and whether the mirror site is still synchronized.
3. Custom --source/--branch The complete URL, Release/repodata, and other metadata availability must be verified first.

❌ Out of scope (provide alternatives)

1. Docker CE software source or Docker Hub acceleration → use the dedicated Docker source-switching process.
2. Independent distributions not recognized by the current script → read that distribution's official repository documentation and plan manually.
3. Executing source switching on an unauthorized production machine on someone's behalf → only output a review version of the plan, commands, and rollback checklist.

Information routing

• Full parameters: readParameter reference。
• Supported systems: readSystem matrix。
• Mainland China/education network/overseas/official sources: readSource modes。
• Main script and Lite: readScript selection。
• Before running: readPre-check checklist。
• CI/CD: readAutomation guide。
• Restore configuration: readRollback guide。
• Error troubleshooting: readTroubleshooting。

Security and privacy

This skill does not collect or upload user data. Do not ask for host passwords, SSH private keys, or cloud credentials. For remote scripts, download and inspect the source and hash/content first, then have the user execute them in a root shell; do not write it as sudo bash <(curl ...). Backups are kept by default; do not proactively use --ignore-backup-tips。

Rules

1. Do not fabricate parameters, version codenames, repository paths, or image availability.
2. Back up by default, do not upgrade all packages by default, and do not clean caches by default.
3. If refreshing the package index fails, stop immediately and do not continue installing or upgrading.
4. For multi-host tasks, verify on a representative node first, then roll out in batches.

When information is insufficient

First provide a safe example based on "Ubuntu 24.04, x86_64, mainland China, generate a plan only, do not execute, keep backups, do not upgrade packages." Please supplement: distribution and version, architecture, network region, whether the current source is available, whether EPEL/security/vault is needed, and whether upgrading packages is allowed.

Verification checklist

• cat /etc/os-release Does it match the package manager?
• Do the command parameters exist in the current ChangeMirrors.sh --help？
• Are the backup path and recovery command clear?
• Does it avoid upgrading all packages and cleaning caches by default?
• Is the target repository metadata and package index refresh verified?

Gotchas

1. sudo bash <(curl ...) may fail due to process substitution permissions/file descriptor behavior; enter a root shell first.
2. --source When only the host part is specified, the correct --branchis still required; multi-level paths must be verified as a whole.
3. Debian/Ubuntu security sources may require separate --source-security and --branch-security。
4. CentOS/AlmaLinux EOL repositories may require vault; ordinary main repository paths cannot continue to be used.
5. --ignore-backup-tips means ignoring overwrite prompts and not backing up, and is not suitable as a default automation parameter.
6. When refreshing the package index fails, do not continue upgrading packages; first roll back or fix DNS/TLS/version codename.

FAQ

Q1: Does the script back up? The main script backs up by default, commonly by appending .bakto the original path; still confirm disk space and existing backups before execution.

Q2: How do I avoid upgrading packages? In the automation plan, explicitly use --upgrade-software false, and verify that the current script supports this option.

Q3: How do I restore the official sources? Prefer using --use-official-source true Regenerate; restore from backup on failure.

Q4: What if curl cannot be installed at all? Use Python, wget, a browser, or a trusted local copy to obtain the script, review it first, then run it.

Q5: How do I choose an education network mirror? For education network scenarios in mainland China, use --edu, and first confirm that the target mirror supports that system version.

Q6: How do I confirm that the mirror change succeeded? Check the target domain in the source file, run the corresponding package manager refresh command, and confirm there are no Release/repodata, signature, or TLS errors.