guide.deepin.org/docs/deepin进阶教程/2.deepin软件包管理/2.6.从损坏的系统中恢复.md
xiangzelong 822e152baf docs: update docs
Log:
2023-02-19 08:13:01 +08:00

141 lines
7.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 2.6.从损坏的系统中恢复
当运行 测试版 或 不稳定版 系统,系统管理员会遇到从错误的软件包管理进行恢复的情形
::: warning 注意
下面的一些方法具有很高的风险,可能会导致系统无法启动,或者导致数据丢失。请谨慎操作。
:::
## 2.6.1. 缺少依赖导致的安装失败
如果你通过"sudo dpkg -i ..."强制安装一个软件包到系统,而不安装它所依赖的所有软件包,这个软件包将作为“部分安装”而失败。
你应当安装所有依赖的软件包,使用 APT 系统或者 "sudo dpkg -i ..."。然后,使用下列命令来配置所有部分安装的软件包。
```Shell
dpkg --configure -a
```
::: tip
这也是我之前提到为什么不建议使用`dpkg -i`来安装软件包的原因。对于缺少依赖的问题,
最好参照[2.3节](2.3.为deepin添加来自debian或ubuntu的软件包.md)的内容进行解决。
:::
## 2.6.2. 软件包数据缓存错误
软件包数据缓存错误,能够造成奇怪的错误,比如 APT 的 "GPG error: ... invalid: BADSIG ..."。
你应该通过 "`sudo rm -rf /var/lib/apt/*`" 删除所有缓存的数据,然后重新尝试。(如果使用了`apt-cacher-ng`,你还应运行"`sudo rm -rf /var/cache/apt-cacher-ng/*`"。)
## 2.6.3. 不兼容旧的用户配置
如果一个桌面 GUI 程序在重要的上游版本升级后变得不稳定,你应该怀疑这是旧的本地配置文件(由它创建的)所导致的。如果它在新建的用户账号下运行稳定,那么这个假设就得到了证实。(这是一个打包的 bug 并且打包者通常会避免它。)
为了恢复稳定,你应该移除相应的本地配置文件并重新启动 GUI 程序。你可能需要阅读旧的配置文件内容以便之后恢复配置信息。(别将它们删得太快了。)
## 2.6.4. 具有相同文件的不同软件包
文档级的软件包管理系统,比如说 aptitude(8) 或 apt-get(1), 使用软件包依赖,当出现相同文件时,不会尝试去安装软件包。(参见 第 2.1.6 节 “软件包依赖关系”).
软件包维护者的错误,或者系统管理员配置了不一致的档案库混合源,(参见 第 2.7.2 节 “混合源档案库中的软件包”),都会出现不正确的软件包依赖情况。如果在出现相同文件的情况下,你通过 aptitude(8) 或 apt-get(1) 安装软件包dpkg(1) 在对软件包解包时,确定会给调用程序返回错误,并不会覆盖已经存在的文件。
::: warning 小心
使用第三方软件包会导致重大的系统风险,因为其通过使用 root 权限运行维护者脚本能够对你的系统做任何事。dpkg(1) 命令只防止解包时的覆盖行为。
:::
可以先通过删除旧的令人讨厌的软件包old-package来解决这类错误的安装问题。
```Shell
sudo dpkg -P <old-package>
```
## 2.6.5. 修复损坏的软件包脚本
当软件包脚本中的一个命令由于某些原因返回错误,脚本也将由于错误而退出,软件包管理系统忽略它们的行为,并导致部分安装的软件包。当一个软件包在它的删除脚本中有错误时,该软件包将会成为不可能删除的软件包,处理这些问题,都会变得相当棘手。
对于 “package_name” 的软件包脚本问题,你应该查看下列的软件包脚本。
- "/var/lib/dpkg/info/package_name.preinst"
- "/var/lib/dpkg/info/package_name.postinst"
- "/var/lib/dpkg/info/package_name.prerm"
- "/var/lib/dpkg/info/package_name.postrm"
使用下列的方法,以 root 编辑损坏的软件包脚本:
- 在行首添加 “#” 可以禁用出错的行
- 在出错行的行尾添加 “|| true” 可以强制返回成功
## 2.6.6. 使用 dpkg 命令进行救援
因为 dpkg 是非常底层的软件包工具,它可以在很糟糕的情况下进行工作,例如无法启动系统且没有网络连接。让我们假定 foo 软件包损坏了,并且需要更换。
你可以在软件包缓存目录:“`/var/cache/apt/archives/`” 中找到旧的 foo 软件包的无 bug 版本。(如果找不到,你可以从档案库 https://snapshot.debian.org/ 中下载它,或从具有软件包缓存功能的机器中拷贝它。)
如果你能够启动系统,你可以通过下列命令来安装它。
```Shell
sudo dpkg -i /path/to/foo_old_version_arch.deb
```
::: tip
如果你系统损坏较小,你也可以使用更高层的 APT 系统来降级整个系统,就像 第 2.7.10 节 “紧急降级” 中做的那样。
:::
如果你的系统无法从硬盘启动,你应该寻找其它方式来启动它。
使用 deepin 安装光盘以救援模式启动系统或者使用live CD。
将硬盘上无法启动的系统挂载到 “/target”。
通过下列命令安装旧版本的 foo 软件包。
```Shell
sudo dpkg --root /target -i /path/to/foo_old_version_arch.deb
```
即使位于硬盘上的 dpkg 命令已损坏,该命令依旧可以执行。
::: tip
任何由硬盘、live GNU/Linux CD、可启动的 USB 驱动或网络启动上的另一系统启动的 GNU/Linux 系统到可以类似地用来救援损坏的系统。
:::
如果由于依赖问题,无法用这种方式安装软件包,并且你真的必须真么做,你可以使用 dpkg 的 “--ignore-depends”、“--force-depends” 和其它选项来无视依赖。如果你这么做了,之后你必须认真努力地修复依赖关系。更多细节参见 dpkg(8)。
::: warning 注意
如果你的系统严重损坏了,你应该将系统完整备份到一个安全的地方(参见 第 10.2 节 “备份和恢复”)并进行一次全新的安装。这是耗时较少且效果较好的办法。
:::
::: tip
如果你无视之前的提醒义无反顾的使用混源方式安装软件包导致系统损坏建议直接备份数据在保留home目录的情况下重新安装系统。
:::
## 2.6.7. 恢复软件包选择数据
如果 “`/var/lib/dpkg/status`” 因为某种原因出现错误Debian 系统会丢失软件包选择数据并受到严重影响。寻找位于 “`/var/lib/dpkg/status-old`” 或 “`/var/backups/dpkg.status.*`” 中旧的 “`/var/lib/dpkg/status”`" 文件。
给 “/var/backups/” 分配一个单独的分区是一个好习惯,因为这个目录包含了许多重要的系统数据。
对于严重的损坏,我建议备份系统后重新安装。即使失去 “/var/” 中的所有数据,你依旧可以从 “/usr/share/doc/” 目录恢复一些信息来引导你进行新的安装。
重新安装最小(桌面)系统。
```Shell
mkdir -p /path/to/old/system
```
将旧系统挂载到 “/path/to/old/system/”。
```Shell
cd /path/to/old/system/usr/share/doc
ls -1 >~/ls1.txt
cd /usr/share/doc
ls -1 >>~/ls1.txt
cd
sort ls1.txt | uniq | less
```
然后你就可以根据软件包名称来进行安装了。(可能会有一些非软件包名称,例如 “texmf”。
## 2.6.8deepin软件包损坏以及修复方式
如果和桌面环境相关的软件包损坏可以尝试安装deepin-desktop-base进行修复