Manjaro/Linux使用常见问题

一.双系统时区问题

1.1 问题描述

当安装了 Windows 和 Manjaro 双系统后，发现出现了 Windows 系统时间比 Manjaro 系统时间慢 8 小时的情况。

1.2 问题分析

在电脑中会有两个时间，一个是硬件时间，一个是系统时间。

1. 硬件时间：这个时间信息存储在电脑主板中，因此没有夏令时以及时区等概念。
2. 系统时间：这个时间信息由系统管理，通常是通过网络时间同步（Network Time Synchronization，NTS），有夏令时以及时区等概念。

注：

系统时间提供了两种管理思路：

• localtime：本地时间，Windows 系统采用此种方法。
• UTC：世界标准时间，在众多 Linux 系统中广泛使用。这种方法只需将 UTC 时间加减时区便得到本地时间。

Linux 认为硬件时间是 UTC 标准时间，Linux 时间同步后会把“正确”的时间做减 8 操作作为标准 UTC 标准时间写入主板。

Windows 系统会认为硬件时间就是本地时间，所以直接把主板中的时间信息拿来当做当前的时间。设置或同步时间后也会把“正确”时间写入主板。

这样操作就会出现双系统时间不同步的情况。

1.3 解决方法

解决的思路就是让 Manjaro 系统使用 localtime 或者让 Windows 系统使用 UTC 时间。具体操作是：

1. 在 Manjaro 系统中设置本地时间

# 使用timedatectl可以查询时间信息，通过如下方式设置 Manjaro 本地时间
sudo timedatectl set-local-rtc true

2. 在 Windows 系统中使用 UTC 时间

# 以管理员身份使用运行
reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_DWORD /f
# 使用以上方法无效或系统为64位：
reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_QWORD /f

注：

本问题参照 ArchLinux Wiki 关于时间问题的处理：ArchLinux Wiki —- Time

二.GitHub 443错误

2.1问题描述

当从Git远程仓库 pull、push 或者 clone 时会出现如下错误：

Failed to connect to github.com port 443: Connection refused

2.2 解决方法

2.2.1 由代理引起

1. 若是由于代理引起的，则使用如下命令关闭代理：

git config --global --unset http.proxy
git config --global --unset https.proxy

注：

重新开启 git 全局代理的方法：

添加全局代理：
git config --global http.proxy
git config --global https.proxy

2.2.2 由 DNS 解析异常导致

若是由于 DNS 解析异常导致的，则使用如下方式解决：

• 首先在 ipaddress.com 网站搜索获取 GitHub 域名对应的 IP 地址。

注：

1. 修改hosts文件,就修改了IP 地址和域名之间的映射关系。修改 hosts 文件域名解析就会访问 hosts 文件中的 IP和域名的映射关系以访问指定网站。
2. 如果想要更加完整的 GitHub DNS 解析列表可在 Gitee 上查询相关仓库并将其更新到本地的 Hosts 文件当中。

• 然后将 IP 地址和域名的映射关系写入系统的 hosts 文件中。

# 在 Windows 系统中修改如下路径的 hosts 文件
C:\Windows\System32\drivers\etc\hosts

# 在 Linux 系统中修改 hosts 文件
sudo vim /etc/hosts

三.签名更新出错

3.1 问题描述

当 Manjaro 更新系统时，会出现如下签名失败的情况并导致软件更新失败

错误：archlinux-keyring: 来自 "Christian Hesse <[email protected]>" 的签名是未知信任的
:: 文件 /var/cache/pacman/pkg/archlinux-keyring-20221220-1-any.pkg.tar.zst 已损坏 (无效或已损坏的软件包 (PGP 签名)).
打算删除吗？ [Y/n]

3.2 解决方法

这儿可能会有两种情况出现

1. 第一种原因呢，是 archlinux-keyring 滚不动了。根本原因呢就是升级到了 gnupg-2.1，pacman 上游更新了密钥环的格式，这使得本地的主密钥无法签署其它密钥。。解决的思路是初始化 keyring 亦或者是将其更换为 archlinuxcn-keyring。本节参考的如下链接：GnuPG-2.1 与 pacman 密钥环

# 1,移除旧的 keys
sudo rm -rf /etc/pacman.d/gnupg
# 2,初始化 pacman 的keys
sudo pacman-key --init
# 3,加载签名的keys
sudo pacman-key --populate
# 4,刷新升级已经签名的keys,这一步可以选择跳过
sudo pacman-key --refresh-keys
# 5,清空并且下载新数据
sudo pacman -Sc
# 6,安装archlinuxcn-keyring
sudo pacman -S archlinuxcn-keyring

然后再更新系统和软件，发现问题解决。

2. 第二种情况呢，是 archlinuxcn 社区源的 keyring 包 archlinuxcn-keyring 由 farseerfc 的 key 签署验证，而 Arch Linux 官方 keyring 中包含了 farseerfc 的 key 。解决思路呢就是使用如下命令在本地信任 farseerfc 的 key。本节参照的如下链接：手动信任 farseerfc 的 key

# 此 key 已随 archlinux-keyring 安装在系统中，只是缺乏信任
sudo pacman-key --lsign-key "[email protected]"

然后再更新系统和软件，发现问题解决。