Arch Linux 使用杂记
这篇文章创建于 2020-02-08 日,距今已有 1707 天,请注意甄别内容是否已经过时!
前言
保持简单,且一目了然。 ~ K.I.S.S.自从去年(2019年)七月以来,笔者逐渐开始使用Linux发行版作为主力,起初是自己熟悉且信赖多年的Deepin,后因在我的笔电上有窗口间歇花屏和其他一些严重bug+性能问题,转而使用基于Arch的Manjaro。后来经大佬们的安利,去年(2019年)十一起,转而使用Arch Linux作为主力。中途踩了不少坑,在此一一记下吧。这篇博文也算是自己在这个站上真正的第一篇博文(上一篇是搬运旧文),以后还会随着我的使用而不断更新。
警告:由于Arch滚动更新的特性,本文内容可能随时间推移而不再适用,请读者务必小心。
安装
从零开始的 Archer 生活。 ~ Install from scratch.个人对于安装步骤的总结:准备安装介质->启动到live环境->连接到互联网->更新系统时间->建立、格式化并挂载分区->修改mirrorlist(在中国大陆推荐使用TUNA/SJTUG/Tencent Cloud/USTCLUG等镜像以提升速度,archlinuxcn源同理)->通过pacstrap安装必须的软件包->生成fstab->chroot到已安装的系统->更改时区->本地化->配置hostname&hosts->设置root密码,同时强烈建议配置一个日常使用的普通用户->安装引导程序(GRUB等)->安装桌面环境->安装其他软件。
主要参考官方安装指南。
也可以看看萌狼的安装指南,对萌新很有帮助。(咱都用了一个月才发现有这篇的存在)
优化
安装后的必备小菜。 ~ General recommendation.
添加Archlinuxcn源:TUNA / ArchlinuxCN 镜像使用帮助
在/etc/pacman.conf
文件末尾添加以下两行:
[archlinuxcn]
Server = https://mirrors.tuna.tsinghua.edu.cn/archlinuxcn/$arch
之后安装archlinuxcn-keyring
包导入 GPG key。如果安装keyring时出现大量error,很可能是系统缺少熵,可安装haveged并启用&启动其服务。稍等片刻,再重新安装keyring,看看问题是不是解决了?
sudo pacman -S haveged
sudo systemctl enable haveged.service
sudo systemctl start haveged.service
配置好Archlinuxcn源之后即可安装诸如yay等AUR工具。另外,可安装powerpill,其多线程下载的特性可极大地加快软件包下载速度。
踩过的坑
翻车实录 ~ Common & uncommon pitfalls.
I. 关于某坑人屑独显
笔者使用的笔电为Dell Inspiron 3576,搭载Intel Core i5-8250U/UHD620核心显卡/Radeon 520独立显卡。乍一看上去有块独显可能还可以,但是它后面的520出卖了它。这块独显是很久以前的GCN初代架构,并且是28nm制程,性能并不比UHD620强多少,而且只要独显稍有负载,风扇立刻拉满转速,发热量可见一斑。然而这些都不是最坑的点。
这块显卡最坑的点,在于……
它在Linux下根本不能用!(至少现在是这样)
至于不能用的具体表现呢,使用
DRI_PRIME=1 $command
调用独显运行应用的时候,短则当场卡死,长则能正常运行个把小时,然后卡死。查看dmesg出现大量类似如下的报错:[ 1937.925741] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=237115, emitted seq=237117
[ 1937.925798] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process pid 0 thread pid 0
如果使用的是radeon而非amdgpu驱动这块独显,则连操作的机会都不给,直接卡死。笔者曾尝试过降级回linux-lts内核,添加内核参数
iommu=pt
,pci=nommconf
,使用打了补丁的linux-amd-staging-drm-next-git
内核,均未能解决问题。虽然多数应用默认不会调用这块独显,但少数应用曾经偷偷背着我调用独显并且hang了整个系统
世界清净了(暂时)
当然还是希望这个bug能修(
II. 关于某网卡的奇怪报错
这台笔电采用的Qualcomm QCA9377无线网卡,实际使用尚可,但是近期发现dmesg中在不断刷报错,从开机连上WiFi就刷个不停:[27137.548302] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
[27137.548303] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
[27137.548304] pcieport 0000:00:1c.5: AER: [12] Timeout
lspci -vt
输出:$ lspci -vt
-[0000:00]-+-00.0 Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers
+-02.0 Intel Corporation UHD Graphics 620
+-04.0 Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem
+-14.0 Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller
+-14.2 Intel Corporation Sunrise Point-LP Thermal subsystem
+-15.0 Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0
+-16.0 Intel Corporation Sunrise Point-LP CSME HECI #1
+-17.0 Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode]
+-1c.0-[01]----00.0 Advanced Micro Devices, Inc. [AMD/ATI] Jet PRO [Radeon R5 M230 / R7 M260DX / Radeon 520 Mobile]
+-1c.4-[02]----00.0 Realtek Semiconductor Co., Ltd. RTL810xE PCI Express Fast Ethernet controller
+-1c.5-[03]----00.0 Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter
+-1f.0 Intel Corporation Sunrise Point LPC Controller/eSPI Controller
+-1f.2 Intel Corporation Sunrise Point-LP PMC
+-1f.3 Intel Corporation Sunrise Point-LP HD Audio
\-1f.4 Intel Corporation Sunrise Point-LP SMBus
报错的正是这块网卡所对应的PCIE总线。不过这个是小问题,毕竟上面已经写了Corrected,并没有影响实际使用,于是在内核参数中添加了
pci=nommconf
并更新grub配置文件(如grub-mkconfig -o /boot/grub/grub.cfg
),重启后问题解决。(非常感谢#archlinux-cn的@farseerfc,@HonamiKoyuki 的帮助。当时本来是想提问amdgpu相关问题的,结果没想到至今也没修好xD)PS:似乎也可添加
pci=nomsi
或pci=noaer
,笔者未进行测试。参考:HP Support Community总结:咱这台笔电真是多灾多难,坑点满满啊。独显是坑,QCA9377也是坑(网上同款网卡/ath10k爆炸的不在少数)不过,能跑就行,要啥自行车(笑)。最近唯一庆幸的是更新到5.5.x内核后i915终于不怎么炸了。
III. yay & proxies
众所周知,Yet another Yogurt a.k.a. yay 是Golang写成,然而从AUR安装软件包经常会需要从境外网站下载,而在本地网络十分糟糕的时候,使用代理几乎是必须的。如果使用proxychains yay -S $Your_App_Name
的话,则会出现connect: network is unreachable
,因为proxychains对yay这种使用静态链接编译出来的go程序无效。后来发现了graftcp,其不使用LD_PRELOAD
技巧来劫持共享库的connect()、getaddrinfo()
等系列函数达到重定向目的,而且其本身也是Golang写成,可以完美适用于yay的代理。然后……
sudo: 有效用户 ID 不是 0,/usr/bin/sudo 位于一个设置了“nosuid”选项的文件系统或没有 root 权限的 NFS 文件系统中吗?
Error installing repo packages
好在这个坑已经有人踩过了(graftcp/issues#11,AUR/graftcp-git/comment#684048)。sudo chmod a+s $(which graftcp)
然后在/usr/bin
下创建一个proxy-yay
脚本:sudo vim /usr/bin/proxy-yay
#!/bin/sh
graftcp sh -c "yay $@"
sudo chmod +x proxy-yay
以后就可以通过proxy-yay
走代理来安装AUR软件包啦。当然,需要后台已经开着graftcp-local
才行。IV.关于makepkg / A bit more tuning.
Arch Linux的软件源从2019年12月27日开始已经开始使用.tar.zst进行打包。zstd 相较于 xz 用压缩比换来高性能。根据archlinuxcn的说法,“调用 zstd 重新压缩软件包导致了总体包大小增加 ~0.8% ,相对的这些包的解压时间总体有 ~1300% 的提速”。翻看了一下archlinux的mail list,他们给出的最佳打包参数是zstd -c -T0 -18 -
。相比原来的xz压缩,zstd在压缩和解压时速度大幅提高,我自己也测试了一下,在打包zoom 3.5.383291.0407
时,使用xz -c -z - --threads=0
耗时约200s,使用zstd -c -z -q - --threads=0
耗时约14s。如图。可以说提升显著。不过,archlinux mainlist里面写的将Compression Level设置为18在本地运行makepkg的时候其实并非必要,还会大幅增加打包时间。因此我就用了默认的压缩比率(3)。文件会有锁增大,不过makepkg输出的包,定期清空就好了(笑)然而问题是,我本地的makepkg在打包的时候仍然在使用xz进行打包。而且下载还是使用的单线程下载,编译也是使用单线程编译……这里将修改成使用aria2多线程下载,zstd打包,八线程编译(我的本子是4C8T),以极大提升安装AUR软件包时的速度。
sudo vim /etc/makepkg.conf
#将原本的
#DLAGENTS=('file::/usr/bin/curl -gqC - -o %o %u'
#'ftp::/usr/bin/curl -gqfC - --ftp-pasv --retry 3 --retry-delay 3 -o %o %u'
#'http::/usr/bin/curl -gqb "" -fLC - --retry 3 --retry-delay 3 -o %o %u'
#'https::/usr/bin/curl -gqb "" -fLC - --retry 3 --retry-delay 3 -o %o %u'
#替换成
DLAGENTS=('ftp::/usr/bin/aria2c -UWget -s8 -x8 %u -o %o'
'http::/usr/bin/aria2c -UWget -s8 -x8 %u -o %o'
'https::/usr/bin/aria2c -UWget -s8 -x8 %u -o %o'
'rsync::/usr/bin/rsync --no-motd -z %u %o'
'scp::/usr/bin/scp -C %u %o')
#将MAKEFLAGS中的值改为"-j8"
#将COMPRESSZST=(zstd -c -z -q -)
#改为
COMPRESSZST=(zstd -c -T8 -`)
#将PKGEXT='.pkg.tar.xz'
#改成
PKGEXT='.pkg.tar.zst'
完事。