有一块 256GB 的硬盘，其上为 CentOS 操作系统以及数据，想全盘克隆至另一块 250GB 的硬盘上，由于目标盘容量不够，因此需要想办法。

在 Windows 下使用 DiskGenius 6.0 和 Acronic True Image 2017 执行克隆硬盘的任务都失败。联想到各自在界面中对分区状态的展示，推测失败原因似乎都与 XFS 文件系统相关。

在网络上搜索，遭到了 https://www.cnblogs.com/Jas0n0ss/p/16142457.html 这个实践，因此决定以它为主要参考教程，来实施缩小 XFS 分区的任务。

过程

到 Ubuntu 下，apt install xpsdump 后，参照前述教程亦步亦趋。

把源盘使用 USB 易驱线连接到电脑上，先看概况：

dandy@dandy-t450s-ubuntu:~$ df -Th
Filesystem Type Size Used Avail Use% Mounted on
tmpfs tmpfs 2.0G 2.5M 2.0G 1% /run
/dev/sdc2 ext4 228G 118G 100G 55% /
tmpfs tmpfs 9.8G 0 9.8G 0% /dev/shm
tmpfs tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs tmpfs 9.8G 216K 9.8G 1% /run/qemu
/dev/sdc1 vfat 511M 15M 497M 3% /boot/efi
tmpfs tmpfs 2.0G 1.7M 2.0G 1% /run/user/1000
/dev/sdd5 xfs 226G 88G 139G 39% /media/dandy/2c130885-88e9-4779-bc9b-52cac8b15605

其中的 sdd5 即是欲调整的分区。接下来先备份整个分区的所有文件，

dandy@dandy-t450s-ubuntu:~$ sudo xfsdump -f ~/centos.xfsdump /media/dandy/2c130885-88e9-4779-bc9b-52cac8b15605
xfsdump: using file dump (drive_simple) strategy
xfsdump: version 3.1.9 (dump format 3.0) - type ^C for status and control

============================= dump label dialog ==============================

please enter label for this dump session (timeout in 300 sec)
-> dump-centos
session label entered: "dump-centos"

--------------------------------- end dialog ---------------------------------

xfsdump: level 0 dump of dandy-t450s-ubuntu:/media/dandy/2c130885-88e9-4779-bc9b-52cac8b15605
xfsdump: dump date: Fri Sep 26 21:23:57 2025
xfsdump: session id: dd3e04bc-50ed-42e1-80f0-4dfd31fa64b7
xfsdump: session label: "dump-centos"
xfsdump: ino map phase 1: constructing initial dump list
xfsdump: ino map phase 2: skipping (no pruning necessary)
xfsdump: ino map phase 3: skipping (only one dump stream)
xfsdump: ino map construction complete
xfsdump: estimated dump size: 93745352000 bytes
xfsdump: /var/lib/xfsdump/inventory created

============================= media label dialog =============================

please enter label for media in drive 0 (timeout in 300 sec)
-> centos
media label entered: "centos"

--------------------------------- end dialog ---------------------------------

xfsdump: creating dump session media file 0 (media 0, file 0)
xfsdump: dumping ino map
xfsdump: dumping directories
xfsdump: dumping non-directory files
xfsdump: ending media file
xfsdump: media file size 93274618464 bytes
xfsdump: dump size (non-dir files) : 93110991456 bytes
xfsdump: dump complete: 1271 seconds elapsed
xfsdump: Dump Summary:
xfsdump: stream 0 /home/dandy/centos.xfsdump OK (success)
xfsdump: Dump Status: SUCCESS

查看备份，并确认源分区无人使用后卸下，

dandy@dandy-t450s-ubuntu:~$ ll -h ~/centos.xfsdump
-rw-r--r-- 1 root root 87G 9月 26 21:44 /home/dandy/centos.xfsdump
dandy@dandy-t450s-ubuntu:~$ fuser -km /media/dandy/2c130885-88e9-4779-bc9b-52cac8b15605
dandy@dandy-t450s-ubuntu:~$ umount /media/dandy/2c130885-88e9-4779-bc9b-52cac8b15605

接下来则与教程不同，因为源盘未启用逻辑卷管理。尝试使用 Disks 工具直接缩小 XFS 文件系统不可行，毕竟该文件系统原则上只能扩大。

那只好自行尝试现将 XFS 文件系统清除，再新创建一个小一点的。打开 GParted 工具，将 XFS 分区上的文件系统标记为 cleared，再用 Disks 把该分区的大小减小了 3GB。这样操作（即非要调整分区大小而非在扩展分区里将该子分区删除后再创建）是想看看能不能保住 UUID，结论是不行。

现在要重新创建 XFS 文件系统了，

dandy@dandy-t450s-ubuntu:~$ sudo mkfs.xfs /dev/sdd5 -f
Swipe your right index finger across the fingerprint reader
meta-data=/dev/sdd5 isize=512 agcount=4, agsize=14648448 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=1 bigtime=0 inobtcount=0
data = bsize=4096 blocks=58593792, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=28610, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0

在 Disks 里能看到 UUID 变了，想把它改回去（之前熟悉的 tune2fs -U {uuid} /dev/XXX 不行，因为那是用于 ext 文件系统的），

dandy@dandy-t450s-ubuntu:~$ sudo tune2fs -U 2c130885-88e9-4779-bc9b-52cac8b15605 /dev/sdd5
tune2fs 1.46.5 (30-Dec-2021)
tune2fs: Bad magic number in super-block while trying to open /dev/sdd5
/dev/sdd5 contains a xfs file system
dandy@dandy-t450s-ubuntu:~$ sudo xfs_admin -U 2c130885-88e9-4779-bc9b-52cac8b15605 /dev/sdd5
Clearing log and setting UUID
writing all SBs
new UUID = 2c130885-88e9-4779-bc9b-52cac8b15605

到 Disks 里一看，已经生效，直接把它 mount 上，现在就该恢复备份的文件了，

dandy@dandy-t450s-ubuntu:~$ sudo xfsrestore -f ~/centos.xfsdump /media/dandy/2c130885-88e9-4779-bc9b-52cac8b15605
xfsrestore: using file dump (drive_simple) strategy
xfsrestore: version 3.1.9 (dump format 3.0) - type ^C for status and control
xfsrestore: searching media for dump
xfsrestore: examining media file 0
xfsrestore: dump description:
xfsrestore: hostname: dandy-t450s-ubuntu
xfsrestore: mount point: /media/dandy/2c130885-88e9-4779-bc9b-52cac8b15605
xfsrestore: volume: /dev/sdd5
xfsrestore: session time: Fri Sep 26 21:23:57 2025
xfsrestore: level: 0
xfsrestore: session label: "dump-centos"
xfsrestore: media label: "centos"
xfsrestore: file system id: 2c130885-88e9-4779-bc9b-52cac8b15605
xfsrestore: session id: dd3e04bc-50ed-42e1-80f0-4dfd31fa64b7
xfsrestore: media id: cac5291e-94f5-4f9f-ba4c-6d6b7a07d9ad
xfsrestore: using online session inventory
xfsrestore: searching media for directory dump
xfsrestore: reading directories
xfsrestore: 180135 directories and 447251 entries processed
xfsrestore: directory post-processing
xfsrestore: restoring non-directory files
xfsrestore: restore complete: 389 seconds elapsed
xfsrestore: Restore Summary:
xfsrestore: stream 0 /home/dandy/centos.xfsdump OK (success)
xfsrestore: Restore Status: SUCCESS

查看一下，

dandy@dandy-t450s-ubuntu:~$ df -Th
Filesystem Type Size Used Avail Use% Mounted on
tmpfs tmpfs 2.0G 2.5M 2.0G 1% /run
/dev/sdc2 ext4 228G 204G 13G 95% /
tmpfs tmpfs 9.8G 0 9.8G 0% /dev/shm
tmpfs tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs tmpfs 9.8G 216K 9.8G 1% /run/qemu
/dev/sdc1 vfat 511M 15M 497M 3% /boot/efi
tmpfs tmpfs 2.0G 1.7M 2.0G 1% /run/user/1000
/dev/sdd5 xfs 224G 89G 135G 40% /media/dandy/2c130885-88e9-4779-bc9b-52cac8b15605

看上去是成了。到 Disks 里，把 XFS 文件系统所处的扩展分区缩到了最小。这样，整个源盘上的所有分区就都处于目标盘的容量范围内了。

用 USB 易驱线把目标盘也接上，dd 两个磁盘顺利完成。

转过天来检查成果。把源盘插回原来的电脑上启动 CentOS，可以正常登录进入系统，但是却出现了一个提示：XFS (sda1): Superblock has unknown read-only compatible features (0x4) enabled. 一检查，果然，整个 / 根分区是以只读方式 mount 起来的。还换用克隆出的目标盘也启动了一把，问题一毛一样。这样可以放下一样心：至少不是克隆的问题。瞬间感觉到昨天还是小看了 XFS，竟然不知道在哪里偷偷摸摸就给藏了雷。

又经过一番资料检索，大致有了个约摸：大概率是 Ubuntu 下操作 XFS 的工具链包括驱动等，版本与 CentOS 自带的有出入，所以制作的文件系统存在兼容性上的问题。0x4 似乎是对应于一个叫做 Reflink 的特性，而且这个特性相当特：它在文件系统创建时一旦指定，之后的存续期间就无法修改。

昨天操作这两块盘的 Ubuntu 不在手边，这两块盘虽然都能正常启动，却都是只读的 / 分区。如何是好？一开始想到 /tmp 目录通常是 tmpfs，应该可以供 mount point 存身，但在其中 mkdir 时失败了。AI 提示了一句，说可以试试 /run 目录，一试还真行。于是开启了源盘和目标盘两兄弟穷帮穷的互助之旅。

要做的事是一样的，只不过你帮我做一遍，反过来我再帮你做一遍。这些事情有：

1. 本盘正常启动 CentOS，登录进入；
2. 把另一块盘接到电脑上，对其上的 / 分区强行重建 XFS 文件系统（其实也就是格式化）：mkfs.xfs -f /dev/sdb5；这两块盘是孪生兄弟，因此 XFS 相关物料和工具之间不会存在版本差异；
3. mount /dev/sdb5 /run/destroot（这个 mount point 的目录名字随意，提前建好）；
4. 把本盘 / 下的所有内容复制过去（跳过系统仅运行时使用到的目录）：rsync -a --exclude=/dev --exclude=/media --exclude=/mnt --exclude=/proc --exclude=/run --exclude=/sys --exclude=/tmp --progress -v / /run/destroot；
5. 到 /run/destroot 下，手动创建上一步特意略过的几个目录：mkdir dev media mnt proc run sys tmp；并设置正确的访问权限：chmod 555 proc sys，以及 chmod 777 tmp；如果缺少这几个目录，系统会无法成功引导（别问是如何得知的）；
6. umount /run/destroot；
7. 这里有个问题，这两块盘是 dd 克隆出来的，各个分区的 UUID 都一样，而上面的步骤 2 重新创建文件系统时，UUID 会发生改变。两种办法，要么去把 fstab 中的 UUID 改成新的，要么像我一样，为了维持面上的 dd 原貌，恢复旧有的 UUID（可以用 blkid 查看引导盘的根分区得到），然后使用 xfs_admin -U ${uuid} /dev/sdb5 这样的命令恢复；

两遍处理过后，源盘和备份盘均恢复正常，至此功成。

下午打开 WSL 里的 Ubuntu 18.04 LTS，要编辑一个 Python 源文件时突然就想试一下这个重生版的工具，于是到官方分发页面下载了下来，准备享受一番。解压缩就来了一次暴击，压缩包是个不常见的 zst 格式，原以为 tar 可以直接解决，但试过发现不行。只好先 apt install zstd，成功后用 zstd 解压。把得到的单文件 edit 移动到 /usr/bin 里执行，报错。

[crayon-68db143e506ae267148845 inline="true" ]./edit: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by ./edit)
./edit: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./edit)
./edit: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./edit)
./edit: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./edit)

看了下系统内的 libc.so 的情况，版本是 2.27，正好差着一点。给系统升级这个重量级的 so 不是没有可能，但是风险较高，实在犯不上。正好前两天清理系统盘的时候，把 WSL 里那份不用的 Ubuntu 20.04 LTS 卸载掉了，不行就把当前的这份升级到 20.04 吧。

执行 do-release-upgrade，报错，信息的最后一句很明确：ModuleNotFoundError: No module named 'apt_pkg'。听了 AI 的劝，执行了 apt install --reinstall python3-apt python3 python3-minimal 和
apt install -f 之后就好了。所谓的好了，就是 do-release-upgrade 命令可以执行了，而不是执行完成了，继续报错：

[crayon-68db143e506b2268143855 inline="true" ]Reading cache
pcilib: Cannot open /proc/bus/pci
lspci: Cannot find any working access method.

Checking package manager
Reading package lists... Done
Building dependency tree
Reading state information... Done
Hit http://security.ubuntu.com/ubuntu bionic-security InRelease
Hit http://archive.ubuntu.com/ubuntu bionic InRelease
Hit http://archive.ubuntu.com/ubuntu bionic-updates InRelease
Hit http://archive.ubuntu.com/ubuntu bionic-backports InRelease
Fetched 0 B in 0s (0 B/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done

Restoring original system state

Aborting
Reading package lists... Done
Building dependency tree
Reading state information... Done
=== Command detached from window (Mon Aug 11 18:33:29 2025) ===
=== Command terminated with exit status 1 (Mon Aug 11 18:33:39 2025) ===

AI 又说了，你要打开 /etc/update-manager/release-upgrades 文件，找到 Prompt=lts，在它前面添加以下两行：

[crayon-68db143e506b5350026375 inline="true" ]CheckPCI=no
CheckUSB=no

然后执行 do-release-upgrade -f DistUpgradeViewNonInteractive，再次失败。

无奈之下，先把 /etc/apt/sources.list 做了个备份，将其中的 bionic 全部替换成了 focal（sed -i 's/bionic/focal/g' /etc/apt/sources.list），然后执行了 apt update 和 apy full-upgrade -y。完成后重新打开 这份 WSL 实例，果然升级成功，libc.so 的版本升到了 2.31。于是满心期待地执行了 edit，呜呼呀，怎么界面看起来像是 VI？连退出的命令都没错，显然又有乌龙发生，应该是升级后的系统把 /usr/bin/edit 给覆盖了，八成成了 vim 的符号链接。

于是又把 edit 解压一次，这次执行就没问题了吧？嘿，报错：

[crayon-68db143e506b8648765403 inline="true" ]./edit: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./edit)
./edit: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./edit)
./edit: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./edit)

除了把一行 2.28 的 glibc 找不到的信息消失了以外，涛声依旧。感情就是消遣俺来着。老夫还是先缓缓吧。

问了问 DeepSeek，给出的例子老是出问题，三五个回合以后，它又回到起初的回答上了。最后还是自己修修改改搞定了。

到 /etc/grub.d/ 目录下，创建一个新的 Grub 钩子脚本，三太爷的命名为 31_set_default_os，内容如下：

#!/bin/sh

set_windows_as_default() {
    local windows_entry

    windows_entry=$(grep -i 'windows' /boot/grub/grub.cfg | grep -oP 'menuentry \K[\x27\x32].*?[\x27\x32]' | tr -d "'\"")
    if [ -n "$windows_entry" ]; then
cat << EOF
set default="$windows_entry"
EOF
        echo "Windows is set as default OS." >&2
        # echo "Windows found." >&2
    else
        echo "Windows not found." >&2
    fi
}

set_windows_as_default

\x27 和 \x32 分别是单双引号字符，写成转义的形式是为了不影响命令行的识别和传递。

#!/bin/bash
 
# AUTHOR: Tommy Butler
#
# DESCRIPTION:
# Run this script to offline and delete a disk from your Linux system.  
# It should work for most people, but if you've got an old kernel it may not.
# Unless you know what you're doing, DO NOT USE THIS SCRIPT!
#
# LICENSE: Perl Artistic License - http://dev.perl.org/licenses/artistic.html
#
# DISCLAIMER AND LIMITATION OF WARRANTY:
# This software is distributed in the hope that it will be useful, but without 
# any warranty; without even the implied warranty of merchantability or fitness 
# for a particular purpose.  USE AT YOUR OWN RISK.  I ASSUME NO LIABILITY.
 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
 
DISK=$1;
 
if [[ `id -u` -ne 0 ]];
then
   echo Run this script with root or sudo
   exit 1
fi
 
while true;
do
   [[ "$DISK" != "" ]] && break;
   read -p 'Enter the name of the disk you want to offline and delete: ' DISK
done
 
if [[ "$( expr substr $DISK 1 4 )" == '/dev' ]];
then
   DISK=$( expr substr $DISK 6 10 )
fi
 
if [[ ! -e /sys/block/$DISK ]];
then
   echo No entry for /dev/$DISK was not found in /sys/block/ - Cannot continue
   exit 1
fi
 
echo Are you sure you want to offline and delete /dev/${DISK}?
 
select yn in "Yes" "No"; do
   case $yn in
      Yes ) break;;
      No ) exit;;
   esac
done
 
echo offline > /sys/block/$DISK/device/state
 
echo 1 > /sys/block/$DISK/device/delete
 
echo DONE
 
exit;

其下有人追问，那如何才能再让它“联机”回来。另一个人做了一个简单回答。

（脚本中的）offline 和 1 是不同的（作用），前者使得磁盘在系统的块设备子系统中不可用，而后者会在物理上通知驱动器断电。重新扫描的动作不会使得系统将离线的磁盘加回来的原因在于，内核记忆了它的离线状态。要想在线回来的话，有个吊诡的地方是，需要使用的状态词不是直觉的 online，而是 running。但在 offline 和 running 之间切换的前提是不能 delete。

苦恼了一阵，决定还是要解决一下，要不然操作太烦。在问题区找到这么个命令：

waydroid shell wm set-user-rotation lock 0

应该是强制锁定了旋转角度，用起来好不少。

wpa_supplicant 跟 wpa_cli 是有的。这前后两者是服务器和客户端的关系，所以先要把服务器跑起来。按照 wpa_supplicant 的输出帮助，其典型用法如 wpa_supplicant -Dnl80211 -iwlan0 -c/etc/wpa_supplicant.conf，在实际环境中看了一下，wpa_supplicant.conf 配置文件是有一个现成的，位置在 /etc/wpa_supplicant 下，文件里的内容只有两行，

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel

。-i 参数的接口也可以通过 ip link 命令看到，唯独 -D 所需的驱动名不知道该怎么写。不知道怎么写就不写呗，先试试，既不犯法也不要命，于是，wpa_supplicant -iwlp3s0 -c/etc/wpa_supplicant/wpa_supplicant.conf 了一下，输出了一行字，似乎成功了。当然了，这是练手，所以没有加 -B 参数让它以守护进程的方式运行到后台。

接下来就要摆弄 wpa_cli 了。首先是 wpa_cli scan，在输出的内容里首先是说它帮着自动选择了一个接口，名叫 p2p_dev_wlp3s0，由于后缀里有真实设备名，还以为前半部分的前缀是惯例，可是用 wpa_cli scan_results 命令查看扫描结果的时候，结果为空。于是 ls -l /var/run/wpa_supplicant 了一下，发现其下有两个文件，一个是前述被自动选中的，另一个则是不带有前缀的真实设备名。于是又分别执行了 wpa_cli -i wlp3s0 scan 和 wpa_cli -i wlp3s0 scan_results 命令，这下就看到周围的接入点名称列表了。

当运行 wpa_cli -i wlp3s0 命令时，即未指定要执行的动作，则会进入交互模式。可以执行 status 查看一些信息，使用 add_network 命令增加一个网络（显然，你应该能想到还有 list_networks 和 remove_network 命令），然后给新增的网络设置属性，set_network 0 ssid "留下买路钱" 指定名称，set_network 0 psk "********" 指定密码，要记住这两个属性指定的时候前后的双引号别漏了。有说还要用 set_network 0 key_mgmt WPA-PSK 指定验证方式的，但老夫的执行结果都是 FAIL。截至目前，这是增加并指定了一个网络的信息，真正要连接到它的话，需要使用 enable_network 0 命令。

很可惜的是，眼看着输出了很多信息，显然是在尝试连接，但最终的结果还是失败了。信息里写道“<3>CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid=”XXXXX” auth_failures=5 duration=60 reason=CONN_FAILED” ，老夫暂时将失败原因归结为下半身中内置的无线网卡没有天线，信号过于衰弱所致。后续老夫会动手实践一个信号增强方案，也不知后果会如何，敬请期待。

更新

昨（2024-03-19）晚，老电工来访，于是开始实践信号增强的想法（另文详述）。材料准备上出了点小状况，原本认为无需焊接技的方案需要稍作修订，焊枪一动，也算老电工人尽其才。路由器距离电脑很近，也就不到半米。之前查看信号强度（wpa_cli 的 scan_results 命令输出中带有）为 -76，改造后立刻查看为 -33，后来稳定运行在 -42 上下。执行 enable_network 命令当即成功。接着，还要取得 IP 地址，执行 dhclient 命令即可。

参考资料

• Linux 使用wpa_supplicant手动配置连接wifi – hokori – 博客园 (cnblogs.com)
• Wpa_supplicant 调试故障原因分析 – schips – 博客园 (cnblogs.com)

从百宝箱里翻腾出一个十年前的小度 Wi-Fi 来，这玩意儿当年在 Windows 下用官方驱动就会搞一大堆乱七八糟的东西进来，但在 Linux 却是一块标准的无线网卡，这回正好废物利用。插上以后，又发现了个问题。路由器是又耳哥搞的，他当初不知怎么手潮了一下，结果只起了 5G 的热点，2.4G 的热点没搞。而这小度 Wi-Fi 不支持 5G，联不进去。

他周六鼓捣了一天也没把 2.4G 网络搭起来，老夫只好在闲鱼上下单了一块新的 USB 无线网卡，价格实惠量又足，600M 的双频无线网卡，个头也不大，RTL8811CU 的方案，22 块钱还包邮，显然没有挑三拣四的理由。到手后插到 Ubuntu 机器上，lsusb 能看到，但是没有自动驱动起来。

网上说有两个仓库，一老一新，也就是 https://github.com/brektrou/rtl8821CU.git 和 https://github.com/morrownr/8821cu-20210916.git。老夫虽然两个都 clone 下来了，但首选肯定是新的那个。

进入到目录里，根据看到的指引直接执行 sudo ./install-driver.sh（事先还执行了 sudo apt install build-essential dkms 以防缺少编译设施支撑），结果这个脚本很快执行到结尾，提示（并同时建议）我打开配置文件看看是否要定制什么，并提示（并同时建议）最好立刻重启。重启之后，网卡仍未如愿驱动成功，到源代码根目录下搜索 *.ko 文件一无所获。无奈，只好先手动执行 make，这次，编译过程肉眼可见，缓缓进行；完成后也有了 8821cu.ko 文件。接着执行 sudo make install，再执行 sudo modprobe 8821cu。这下 Wi-Fi 网络就顿时出现了，那些 5G 热点也都出现在列表里了，圆满成功。

安装 Waydroid 成功后，再下载需要的 Android 映像，之后就可以启动 Android 了。要向 Android 中安装 apk 的话，可以使用 waydroid app install 命令。要是想在 Android 内部执行命令（非 GUI 应用），则可以使用 sudo waydroid shell。这样的用法，看上去又和 adb 类似。

第一个要解决的问题是 Play Store，要执行这些命令（信息源：https://github.com/casualsnek/waydroid_script）：

• 前提：sudo apt install lzip sqlite
• 安装 OpenGapps：
  • git clone https://github.com/casualsnek/waydroid_script
  • cd waydroid_script
  • sudo python3 -m pip install -r requirements.txt，这是安装此脚本工具所需的依赖
  • sudo python3 main.py -g，这是安装 OpenGapps
  • waydroid show-full-ui，启动 Android，请等待完全启动就绪
  • sudo python3 main.py -i，获取 Android ID 以便注册设备

笔者在获取 Android ID 时遇到了错误，命令行执行后一直报以下信息：

ERROR: Cannot access gservices.db, make sure gapps is installed and waydroid was started at least once after installation and make sure waydroid is running !

所以只好自己再去寻找答案，找到 https://github.com/waydroid/waydroid/issues/753，其中提到可以执行 sudo grep android_id ~/.local/share/waydroid/data/data/com.google.android.gms/shared_prefs/Checkin.xml | cut -f2 -d">" | cut -f1 -d"<"。后来发现，其实也可以在 waydroid shell 中执行 sqlite3 /data/data/com.google.android.gsf/databases/gservices.db "select * from main where name = \"android_id\";" 获取到。

然后用浏览器打开 https://www.google.com/android/uncertified/?pli=1，使用 Google 账户登录后，把上面取得的 Android ID 填进去进行注册。注册成功后，在命令行执行 sudo waydroid session stop 以确保 Waydroid 完全退出，然后重新启动 Waydroid。此时再打开 Play Store 应用，就可以像正常手机上那样登录，并下载安装应用了。

笔者另外还遇到了 Waydroid 内的 Android 网络不通的情况，折腾 Wi-Fi 连接许久无果，后来的某次重启系统后，Waydroid 内的 Android 突然以有线连接的方式联网了，就这么将就着往下用了。

更新（2025-04-23）：

时隔两年，又安装了一次。有几个小点明确一下。

• 最开头 apt 安装的 sqlite 要改为 sqlite3 了；
• Linux 确实需要一次重启，Waydroid 的网络才能工作；
• 上面在数据库中检索 android_id 的 SQL 语句，在 Google 网站的页面上已经写为 sqlite3 /data/user/$(cmd activity get-current-user)/*/*/gservices.db \
"select * from main where name = \"android_id\";"；但事实是仍会报找不到 android_id 这一列，把 where 子句去除，然后拼接上 grep 过滤即可；
• 注册成功后，Google Play 可能要等比较久才认可设备，网帖上说的“久”是三五分钟，本人实际是好几个小时。

在 Windows 10 里，要在 WSL 内 mount 另一个 ext 分区，是有一些限制的。首先是对 WSL 本身，要求必须是从 Microsoft Store 下载的版本，而非系统自带版本。否则的话，--mount 命令就不被支持。其次，由于 wsl.exe --mount 会是挂载整个磁盘，因此要求此时 Windows 不能对该盘正在占用。当 wsl.exe --mount 挂载磁盘成功后，就可以转到 Linux 子系统中使用 mount 命令挂载指定的分区了。

ChatGPT

从某个版本开始，Windows 的资源管理器中会将 WSL 中的所有 Linux 子系统列出，并可以将其中的目录树展开访问。因此我误以为在 Linux 子系统里 mount 上的 ext4 分区中的内容也可以借由此途径暴露出来。事实是当试图访问时，分区内为空白。就此事请教了 ChatGPT，发现其对此处的情况相当了解。把未作改动的交互转录于下（ME 是我，CG 是 ChatGPT）。

今天又到手了一台 ThinkPad X200，没有要电源适配器、电池、硬盘这三样，一百七十块包邮。到手后看了一下成色，算是不错的。为了早点测试一下各个部件的工作情况就给卖家确认收货，把原来自用的那台 X200 脱手后余下闲置的装了 Debian 系统的 SD 卡插上，开机启动。屏幕、声音、网络、键盘、指点杆这些工作都正常，还把好久以来认为死了的 X200 四芯电池也装上来，心想尽管无法充电不能使用，但好歹可以补上物理位置的空虚。不料用了一阵子发现屏幕下的指示灯竟然变绿了！电池貌似又活了过来。

再想看一下具体信息，系统里似乎就没用工具了。搜索到了一个叫做 tlp 的工具，说可以在 Linux 下管理/维护电池。该工具的官网链接是 https://linrunner.de/tlp/index.html，Github 仓库地址为 https://github.com/linrunner/TLP。按照官网说明安装了工具本身，并根据 tlp stat 的输出结果安装了适合 ThinkPad X200 的附加内核模块 tp-smapi-dkms。

最终命令行下执行 tlp stat，电池的信息如下：

+++ ThinkPad Extended Battery Functions
tp-smapi   = active
tpacpi-bat = inactive (unsupported hardware)

+++ ThinkPad Battery Status: BAT0 (Main / Internal)
/sys/devices/platform/smapi/BAT0/manufacturer               = SANYO
/sys/devices/platform/smapi/BAT0/model                      = 42T4646
/sys/devices/platform/smapi/BAT0/manufacture_date           = 2009-12-11
/sys/devices/platform/smapi/BAT0/first_use_date             = 2010-03-15
/sys/devices/platform/smapi/BAT0/cycle_count                =    292
/sys/devices/platform/smapi/BAT0/design_capacity            =  28800 [mWh]
/sys/devices/platform/smapi/BAT0/last_full_capacity         =   6890 [mWh]
/sys/devices/platform/smapi/BAT0/remaining_capacity         =   6850 [mWh]
/sys/devices/platform/smapi/BAT0/remaining_percent          =    100 [%]
/sys/devices/platform/smapi/BAT0/remaining_running_time_now = not_discharging [min]
/sys/devices/platform/smapi/BAT0/remaining_charging_time    =      1 [min]
/sys/devices/platform/smapi/BAT0/power_now                  =   8987 [mW]
/sys/devices/platform/smapi/BAT0/power_avg                  =   8987 [mW]
/sys/devices/platform/smapi/BAT0/state                      = charging

/sys/devices/platform/smapi/BAT0/start_charge_thresh        =     96 [%]
/sys/devices/platform/smapi/BAT0/stop_charge_thresh         =    100 [%]
/sys/devices/platform/smapi/BAT0/force_discharge            =      0

Charge                                                      =   99.4 [%]
Capacity                                                    =   23.9 [%]

据说还可以执行 tlp recalibrate 命令对电池电量进行校正，有空再说。