主页 / unix / 问题

问题[systemd](unix)

Martin Hope
CarloC
Asked: 2024-10-29 17:29:08 +0800 CST
  • 5

lsns根据运行它的用户的权限，输出看起来会有所不同。ubuntu用户和root用户得到不同的结果：

ubuntu@ubuntu:~$ lsns 
        NS TYPE   NPROCS    PID USER   COMMAND
4026531834 time        6 134628 ubuntu /lib/systemd/systemd --user
4026531835 cgroup      6 134628 ubuntu /lib/systemd/systemd --user
4026531836 pid         6 134628 ubuntu /lib/systemd/systemd --user
4026531837 user        5 134628 ubuntu /lib/systemd/systemd --user
4026531838 uts         6 134628 ubuntu /lib/systemd/systemd --user
4026531839 ipc         6 134628 ubuntu /lib/systemd/systemd --user
4026531840 net         6 134628 ubuntu /lib/systemd/systemd --user
4026531841 mnt         5 134628 ubuntu /lib/systemd/systemd --user
4026532290 user        1 134689 ubuntu /usr/bin/podman
4026532291 mnt         1 134689 ubuntu /usr/bin/podman
ubuntu@ubuntu:~$ 
ubuntu@ubuntu:~$ 
ubuntu@ubuntu:~$ sudo lsns
        NS TYPE   NPROCS    PID USER             COMMAND
4026531834 time      115      1 root             /sbin/init
4026531835 cgroup    115      1 root             /sbin/init
4026531836 pid       112      1 root             /sbin/init
4026531837 user      113      1 root             /sbin/init
4026531838 uts       112      1 root             /sbin/init
4026531839 ipc       115      1 root             /sbin/init
4026531840 net       115      1 root             /sbin/init
4026531841 mnt       101      1 root             /sbin/init
4026531862 mnt         1     25 root             kdevtmpfs
4026532284 mnt         1    414 root             /lib/systemd/systemd-udevd
4026532285 uts         1    414 root             /lib/systemd/systemd-udevd
4026532286 mnt         1    469 systemd-timesync /lib/systemd/systemd-timesyncd
4026532287 uts         1    469 systemd-timesync /lib/systemd/systemd-timesyncd
4026532288 mnt         1    572 systemd-network  /lib/systemd/systemd-networkd
4026532289 mnt         1    608 systemd-resolve  /lib/systemd/systemd-resolved
4026532290 user        1 134689 ubuntu           /usr/bin/podman
4026532291 mnt         1 134689 ubuntu           /usr/bin/podman
4026532292 mnt         1   5369 root             /usr/libexec/upowerd
4026532293 user        1   5369 root             /usr/libexec/upowerd
4026532295 mnt         2 134974 root             unshare --fork --pid --mount-proc /bin/bash
4026532296 pid         2 134975 root             /bin/bash
4026532297 mnt         2 134981 root             unshare --fork --pid --mount-proc /bin/zsh
4026532298 pid         1 134982 root             /bin/zsh
4026532345 uts         1    655 root             /lib/systemd/systemd-logind
4026532346 mnt         1    631 root             /usr/sbin/irqbalance --foreground
4026532347 mnt         1    655 root             /lib/systemd/systemd-logind
4026532348 mnt         1    678 root             /usr/sbin/ModemManager
ubuntu@ubuntu:~$

此外，Ubuntu 系统的 init 进程名称不同：systemdvs /sbin/init。这是什么原因？谢谢。

systemd
Martin Hope
xealits
Asked: 2024-10-21 06:08:56 +0800 CST
  • 5

我在从 Intel Optane（我刚从 ebay 收到）启动全新的 Ubuntu 24.04.1 时遇到了一些问题：启动过程运行很快，但有时一些 systemd 单元在启动过程中不运行，系统启动时没有 NetworkManager 或其他东西，如 snapd-apparmor。journalctl 日志报告存在排序周期。尝试找到它们时，我注意到systemd-analyze verify multi-user.target几乎每次运行它时都会报告不同的内容：

$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
7
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
13
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
0
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
0
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
18

由于对来自 ebay 的磁盘有怀疑，我在之前安装在 Corsair NVMe 上的 Ubuntu 22.04 上尝试了同样的操作，结果相同：

$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
16
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
22
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
44
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
24
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
4
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
14

Corsair NVMe 上的启动过程也存在类似的问题，即无法启动某些 systemd 单元。但这种情况不太常见。

为什么会发生这种情况？我是否遗漏了什么systemd-analyze verify？为什么systemd-analyze verify每次运行时都会报告不同的循环次数？

版本。在英特尔傲腾上：

$ systemd --version
systemd 255 (255.4-1ubuntu8.4)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=24.04
DISTRIB_CODENAME=noble
DISTRIB_DESCRIPTION="Ubuntu 24.04.1 LTS"

之前在 Corsair NVMe 上安装的情况（lspci实际上报告为 Phison Electronics Corporation E12）：

$ systemd --version
systemd 249 (249.11-0ubuntu3.12)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.5 LTS"
systemd
Martin Hope
mousetail
Asked: 2024-10-20 20:58:54 +0800 CST
  • 5

我以“Ubuntu”用户身份登录 SSH 到服务器上。但是我想以另一个用户“ABC”身份管理运行一些 systemd 服务。

如果我尝试sudo -u abc bash以用户身份执行此操作ABC，则每个systemd --user命令都会出现错误：

Failed to connect to bus: No medium found

我发现这个线程建议添加以下内容~/.bashrc：

export XDG_RUNTIME_DIR="/run/user/$UID"
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"

这会将错误更改为：

Failed to connect to bus: No such file or directory

其他消息来源表明，无头服务器通常不会安装 dbus，因此这是有道理的（它似乎是 x11 的一个组件）。虽然我不知道为什么如果我将其作为 运行，它会毫无问题地运行ubuntu。

我发现这个建议的解决方法

sudo systemctl -M abc@ --user restart foobar.service

这对于基本start、stop有效，status但是：

  • systemctl --user cat不起作用
  • 似乎没有任何变化journalctl有效：
Failed to open root directory of machine 'abc@': The name org.freedesktop.machine 1 was not provided by any .service files
Failed to open journal: No route to host
  • 打字太长，不方便。

我真的只是想要一个这个其他用户的 shell，就像我登录时一样，ubuntu并且可以毫无问题地管理我的所有用户服务。

我提到 Podman 是因为当我以其他用户身份运行 Podman 时，它也会非常不高兴。如果我以 身份使用它，它会正常工作，ubuntu但如果我以 运行它，就会出错sudo -u。像 systemd 一样，我有一些部分解决方法，但似乎都没有效果好。

systemd
Martin Hope
E962
Asked: 2024-10-20 19:05:52 +0800 CST
  • 6

我有两个网络接口，eno1 和 eth0。我希望它们都使用 DHCP 获取 IP 地址。我希望 eno1 用作所有设备的默认路由。我唯一想使用 eth0 的情况是在 curl 命令中指定接口时。

我创建了两个配置文件：

root:/etc/systemd/network$ ls -la
total 16
drwxr-xr-x 2 root root 4096 Oct 20 10:50 .
drwxr-xr-x 6 root root 4096 Oct 20 10:51 ..
-rw-r--r-- 1 root root   59 Oct 20 09:54 10-eno1.network
-rw-r--r-- 1 root root   59 Oct 20 10:41 20-eth0.network

root:/etc/systemd/network$ cat 10-eno1.network
[Match]
Name=eno1

[Network]
DHCP=yes

[Route]
Metric=100

root:/etc/systemd/network$ cat 20-eth0.network
[Match]
Name=eth0

[Network]
DHCP=yes

[Route]
Metric=4000

我尝试过重新启动并调整指标，但它们似乎没有效果。

root:/etc/systemd/network$ systemctl status systemd-networkd
● systemd-networkd.service - Network Configuration
     Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; enabled; preset: enabled)
     Active: active (running) since Sun 2024-10-20 10:51:59 UTC; 12min ago
TriggeredBy: ● systemd-networkd.socket
       Docs: man:systemd-networkd.service(8)
             man:org.freedesktop.network1(5)
   Main PID: 24821 (systemd-network)
     Status: "Processing requests..."
      Tasks: 1 (limit: 76956)
   FD Store: 0 (limit: 512)
     Memory: 1.7M (peak: 2.1M)
        CPU: 32ms
     CGroup: /system.slice/systemd-networkd.service
             └─24821 /usr/lib/systemd/systemd-networkd

Oct 20 10:51:59 systemd-networkd[24821]: eth0: Link UP
Oct 20 10:51:59 systemd-networkd[24821]: eth0: Gained carrier
Oct 20 10:51:59 systemd-networkd[24821]: eno1: Gained IPv6LL
Oct 20 10:51:59 systemd-networkd[24821]: eth0: Gained IPv6LL
Oct 20 10:51:59 systemd-networkd[24821]: Enumeration completed
Oct 20 10:51:59 systemd[1]: Started systemd-networkd.service - Network Configuration.
Oct 20 10:51:59 systemd-networkd[24821]: eno1: Configuring with /etc/systemd/network/10-eno1.network.
Oct 20 10:51:59 systemd-networkd[24821]: eth0: Configuring with /etc/systemd/network/20-eth0.network.
Oct 20 10:51:59 systemd-networkd[24821]: eno1: DHCPv4 address 192.168.0.2/24, gateway 192.168.0.1 acquired from 192.168.0.1
Oct 20 10:51:59 systemd-networkd[24821]: eth0: DHCPv4 address 192.168.0.99/24, gateway 192.168.0.1 acquired from 192.168.0.1

root:/etc/systemd/network$ ip route show
default via 192.168.0.1 dev eno1 proto dhcp src 192.168.0.2 metric 1024
default via 192.168.0.1 dev eth0 proto dhcp src 192.168.0.99 metric 1024
128.138.140.44 via 192.168.0.1 dev eno1 proto dhcp src 192.168.0.2 metric 1024
128.138.140.44 via 192.168.0.1 dev eth0 proto dhcp src 192.168.0.99 metric 1024
192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.2 metric 1024
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.99 metric 1024
192.168.0.1 dev eno1 proto dhcp scope link src 192.168.0.2 metric 1024
192.168.0.1 dev eth0 proto dhcp scope link src 192.168.0.99 metric 1024
systemd
Martin Hope
josh-stackexchange
Asked: 2024-10-05 06:11:07 +0800 CST
  • 5

systemctl --user start foo.service尝试运行包含ExecStart=touch /bar/baz具有/bar权限的systemd 服务drwxrwxr-x 1 root storage。运行该命令的用户属于该组storage，并且可以从 shell 运行该touch命令而不会出现问题，从而创建文件。但是，该服务因权限错误而失败。

我认为该服务的权限将与运行它的用户相匹配 - 并且确实让服务${USER}在其命令中使用环境变量确实会产生我的用户，并且该服务会出现在我的ps或pstree ${USER}列表中。

foo.service不包含ProtectSystem或除以下之外的任何条目：Description，EnvironmentFile，Environment，ExecStart，，。环境条目用于加载与权限无关的配置KillSignal。RestartRestartSec

该服务是否实际上不使用调用用户来获取权限？如果不是，解决问题的最佳方法是什么？/bar位于已安装的驱动器上，因此我可以dmask 0000在 fstab 中执行此操作，但我宁愿避免这种方法。

systemd
Martin Hope
Matt.
Asked: 2024-09-28 18:18:38 +0800 CST
  • 5

我有两个参考资料，看起来都很可信，但它们提供的信息不同。

在第一个引用中，提到default.target是执行的初始目标之一。然后（假设我们希望系统启动到 CLI 模式）multi-user.target将执行 ，接着是basic.target，最后，我们将到达sysinit.target。

然而，在第二个参考文献中，该过程的描述顺序却相反！它指出sysinit.target首先执行，然后执行basic.target，依此类推。

我很困惑。哪个顺序是正确的？哪个目标/sbin/init从一开始就开始？

systemd
Martin Hope
alexpotato
Asked: 2024-09-24 19:17:48 +0800 CST
  • 5

所以我的情况有些特殊。

机器启动后，我需要机器上的一个驱动器具有可全世界写入的未格式化分区。

原因：应用程序正在该分区上构建它自己的文件系统。

问题：

我编写了一个 systemd 脚本，它可以执行chmod a+rw /dev/$partition_name

stat如果我通过或检查权限ls -l，“其他”可写权限看起来不错

例如brw-rw-rw-

然而，一旦机器启动，权限就会改变为：

brw-rw---。

所以问题是：

  1. 为什么权限不断翻转？
  2. 正确的做法是什么？
systemd
Martin Hope
Braedon
Asked: 2024-09-20 08:17:51 +0800 CST
  • 5

我必须将一个服务和一个套接字设置为 Systemd 单元。期望的行为是，当我启动套接字时，服务将首先启动，然后是套接字，当其中一个被关闭时，它们都应该关闭。服务在套接字单元启动之前绑定到套接字，这就是为什么我将其作为通知服务，这样它就不会报告为已启动，直到它在套接字上绑定。

这是两个单位的文件。

#rustyvxcan.service
[Unit]
Description=Docker VXCAN plugin Service
#PartOf=rustyvxcan.socket
    
Before=docker.service
After=network.target
    
[Service]
Type=notify
ExecStartPre=/usr/bin/mkdir -p /run/docker/plugins
ExecStart=/home/braedon/.cargo/bin/rustycan4docker
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

#rustyvxcan.socket
[Unit]
Description=A network plugin for vxcan
Before=docker.service
AssertPathExists=/run/docker/plugins
Requires=rustyvxcan.service
After=rustyvxcan.service

[Socket]
ListenStream=/run/docker/plugins/rustyvxcan.sock
RemoveOnStop=True

[Install]
WantedBy=sockets.target

错误信息如下。

Sep 19 16:50:38 localhost systemd[1]: rustyvxcan.service: Found ordering cycle on rustyvxcan.socket/start
Sep 19 16:50:38 localhost systemd[1]: rustyvxcan.service: Found dependency on rustyvxcan.service/start
Sep 19 16:50:38 localhost systemd[1]: rustyvxcan.service: Unable to break cycle starting with rustyvxcan.service/start
Sep 19 16:55:09 localhost systemd[1]: rustyvxcan.socket: Found ordering cycle on rustyvxcan.service/start
Sep 19 16:55:09 localhost systemd[1]: rustyvxcan.socket: Found dependency on rustyvxcan.socket/start
Sep 19 16:55:09 localhost systemd[1]: rustyvxcan.socket: Unable to break cycle starting with rustyvxcan.socket/start

从资源来看，这意味着循环只发生在这两个文件中，我可以通过从 .socket 文件中删除 After 行来清除错误，但它们同时启动，服务的可执行文件失败。我可能只需在套接字中添加一个睡眠即可解决这个问题，但我在这里没有看到足够的依赖信息来导致循环。

我尝试清除 /{lib,etc}/systemd/system 中的服务和套接字文件，然后重新安装粘贴在此处的文件，以确保旧版本未运行，当然，在修改它时定期运行 systemctl daemon-reload。但我似乎无法弄清楚为什么即使在从服务文件中删除依赖项后，指定 after 也会破坏依赖关系图。

我遗漏了发生循环的地方在哪里？

systemd
Martin Hope
Madoc Comadrin
Asked: 2024-09-08 06:24:13 +0800 CST
  • 5

我有一台运行 Fedora Workstation 40 和 Systemd 255 的计算机。由于某种原因，内核日志消息在日志中的可用时间比其他日志消息短得多。

user@host:~ $ journalctl -k | head
Sep 07 22:15:28 host kernel: Linux version 6.10.6-200.fc40.x86_64 (mockbuild@f1069ead281040288cd8d3761ad1265a) (gcc (GCC) 14.2.1 20240801 (Red Hat 14.2.1-1), GNU ld version 2.41-37.fc40) #1 SMP PREEMPT_DYNAMIC Mon Aug 19 14:09:30 UTC 2024
Sep 07 22:15:28 host kernel: Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.10.6-200.fc40.x86_64 root=UUID=800307e3-abdf-4cc6-a111-b068a8bb22a9 ro rootflags=subvol=root rd.luks.uuid=luks-5da2f27b-d221-4a68-a150-648d03962ac0 rhgb quiet
Sep 07 22:15:28 host kernel: BIOS-provided physical RAM map:
Sep 07 22:15:28 host kernel: BIOS-e820: [mem 0x0000000000000000-0x0000000000057fff] usable
Sep 07 22:15:28 host kernel: BIOS-e820: [mem 0x0000000000058000-0x0000000000058fff] reserved
Sep 07 22:15:28 host kernel: BIOS-e820: [mem 0x0000000000059000-0x000000000009cfff] usable
Sep 07 22:15:28 host kernel: BIOS-e820: [mem 0x000000000009d000-0x00000000000fffff] reserved
Sep 07 22:15:28 host kernel: BIOS-e820: [mem 0x0000000000100000-0x000000003fffffff] usable
Sep 07 22:15:28 host kernel: BIOS-e820: [mem 0x0000000040000000-0x00000000403fffff] reserved
Sep 07 22:15:28 host kernel: BIOS-e820: [mem 0x0000000040400000-0x0000000075477fff] usable

user@host:~ $ journalctl | head
Aug 19 17:53:26 host systemd-journald[1079]: /var/log/journal/645eb9bfb5a942db9945b658805a08a5/user-1000.journal: Journal file uses a different sequence number ID, rotating.
Aug 19 17:53:26 host audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=user@42 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Aug 19 17:53:26 host audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=user@1000 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Aug 19 17:53:26 host audit[1718]: USER_START pid=1718 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_umask acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=host addr=? terminal=/dev/tty1 res=success'
Aug 19 17:53:26 host audit[1675]: USER_START pid=1675 uid=0 auid=1000 ses=2 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_loginuid,pam_keyinit,pam_limits,pam_systemd acct="th" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
Aug 19 17:53:26 host audit[1675]: CRED_REFR pid=1675 uid=0 auid=1000 ses=2 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="th" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
Aug 19 17:53:26 host audit[1679]: USER_START pid=1679 uid=0 auid=1000 ses=3 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_loginuid,pam_keyinit,pam_limits,pam_systemd acct="th" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
Aug 19 17:53:26 host audit[1679]: CRED_REFR pid=1679 uid=0 auid=1000 ses=3 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="th" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
Aug 19 17:53:26 host audit[1799]: USER_ACCT pid=1799 uid=1000 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_access,pam_unix acct="th" exe="/usr/bin/crontab" hostname=? addr=? terminal=cron res=success'
Aug 19 17:53:26 host audit[1799]: CRED_ACQ pid=1799 uid=1000 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="th" exe="/usr/bin/crontab" hostname=? addr=? terminal=cron res=success'

使用带有 sudo 的 journalctl 命令没有任何区别。据说journalctl --verify所有日志文件都正常。

Journald 配置使用默认值：

user@host:~ $ systemd-analyze cat-config systemd/journald.conf
# /usr/lib/systemd/journald.conf
[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitIntervalSec=30s
#RateLimitBurst=10000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=no
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info
#MaxLevelWall=emerg
#LineMax=48K
#ReadKMsg=yes
#Audit=yes

有足够的可用磁盘空间：

user@host:~ $ du -hs /var/log/journal/
465M    /var/log/journal/


user@host:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/dm-0       237G   23G  212G  10% /
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs           7.7G   14M  7.7G   1% /dev/shm
efivarfs        154K   55K   95K  37% /sys/firmware/efi/efivars
tmpfs           3.1G  2.2M  3.1G   1% /run
/dev/dm-0       237G   23G  212G  10% /home
/dev/nvme0n1p2  974M  353M  554M  39% /boot
tmpfs           7.7G  3.4M  7.7G   1% /tmp
/dev/nvme0n1p1  599M   20M  580M   4% /boot/efi
tmpfs           1.6G   72K  1.6G   1% /run/user/0
tmpfs           1.6G  228K  1.6G   1% /run/user/1000

可能是什么原因造成的？如何才能使内核消息像其他消息一样长时间保留在日志中？

systemd
Martin Hope
Alex Leach
Asked: 2024-08-30 16:51:04 +0800 CST
  • 7

我最近在旧的 SSD 上安装了 Ubuntu，因为我想在不同的操作系统上测试一些软件。安装 Ubuntu（使用debootstrap、arch-chroot和apt）后，我的 EFI 的 NVRAM 启动顺序变得混乱，TPM2 现在不会自动解锁我的 Arch 根分区和交换分区。系统提示我输入恢复密钥或密码。

因此，我知道我需要更新 TPM 中的 PCR 寄存器。但我有几个问题：

  • 我应该如何替换旧 TPM2 PCR 插槽中的条目，而不是添加新的条目？
  • 有人能解释一下为什么 TPM 芯片现在无法解锁我的分区吗？以及我应该尝试避免在将来再次这样做吗？

我的主要操作系统是 Arch Linux，按照以下几篇文章进行设置：

systemd-boot用作引导加载程序。

启动时使用 TPM 解锁两个 dm-crypt 分区：

  • root
  • swap（允许暂停和恢复）。

安装 Ubuntu 后，root和swap卷都无法使用 TPM 解锁。

如何使 TPM PCR 寄存器无效

我意识到我做错了一件事，就是在安装到 之前先将 Ubuntu 安装到/media/ubuntu中。因此，在第一次使用 安装 Ubuntu 后，我运行了：/efi/media/ubuntu/boot/efidebootstrap

  • mount --bind /efi /media/ubuntu/boot/efi
  • arch-chroot /media/ubuntu
  • apt install grub-efi-amd64（这将删除grub-pc）
  • grub-install

因此，我现在有一个/efi分区，一个/boot用于 Arch Linux 的加密分区，Ubuntu 分区有一个/boot文件夹。（还有一个 Windows 引导加载程序，所以是的，很乱……）

grub无法os-probe检测到我的 Arch Linux 安装，因此我不得不F11在早期启动时按下 并选择 来重新进入Linux Boot Manager。此时，systemd要求我输入根分区的解锁密码或恢复密钥。（我目前都有这两个，因此进入不是问题，除非我远程重启）。

我的设置

我列出了相当长的诊断命令列表，这对于将来诊断类似问题的人（毫无疑问也包括我）应该非常有帮助！

更新： TPM 已注册以解锁 PCR 7 上的加密分区，如下所示：

# Install the TPM tools
pacman -S tpm2-tools

# Check the name of the kernel module for our TPM
systemd-cryptenroll --tpm2-device=list

# Generate a recovery key (not mandatory but strongly recommended)
systemd-cryptenroll --recovery-key /dev/gpt-auto-root-luks

# Generate a key in the TPM2 and add it to a key slot in the LUKS device
systemd-cryptenroll --tpm2-device=auto /dev/gpt-auto-root-luks --tpm2-pcrs=7

# This is the command to use later, to remove the (insecure) initial password
#systemd-cryptenroll /dev/gpt-auto-root-luks --wipe-slot=password

我的分区表非常繁忙：

$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sdb           8:16   0 238.5G  0 disk  
├─sdb1        8:17   0   128G  0 part  /media/ubuntu
├─sdb2        8:18   0   110G  0 part  
└─sdb3        8:19   0   527M  0 part  
nvme0n1     259:0    0 931.5G  0 disk  
├─nvme0n1p1 259:1    0   100M  0 part  
├─nvme0n1p2 259:2    0    16M  0 part  
├─nvme0n1p3 259:3    0 165.4G  0 part  
├─nvme0n1p4 259:4    0   507M  0 part  
├─nvme0n1p5 259:5    0     1G  0 part  
├─nvme0n1p6 259:6    0    32G  0 part  
│ └─swap    254:1    0    32G  0 crypt [SWAP]
├─nvme0n1p7 259:7    0   227G  0 part  
│ └─root    254:0    0   227G  0 crypt /
└─nvme0n1p8 259:8    0 505.5G  0 part  
  └─data    254:3    0 505.5G  0 crypt /var/lib/docker
                                       /media/data

$ sudo fdisk -l /dev/nvme0n1 /dev/sdb
Disk /dev/nvme0n1: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 980 PRO 1TB                 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt

Device             Start        End    Sectors   Size Type
/dev/nvme0n1p1      2048     206847     204800   100M EFI System (/efi)
/dev/nvme0n1p2    206848     239615      32768    16M Microsoft reserved
/dev/nvme0n1p3    239616  347119443  346879828 165.4G Microsoft basic data (Win 10)
/dev/nvme0n1p4 347119616  348157951    1038336   507M Windows recovery environment
/dev/nvme0n1p5 348157952  350255103    2097152     1G Linux extended boot (/boot)
/dev/nvme0n1p6 350255104  417363967   67108864    32G Linux swap
/dev/nvme0n1p7 417363968  893417471  476053504   227G Linux root (x86-64) (/)
/dev/nvme0n1p8 893417472 1953523711 1060106240 505.5G Linux filesystem (/media/data)

Disk /dev/sdb: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: M4-CT256M4SSD2  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sdb1            2048 268437503 268435456  128G 83 Linux (/media/ubuntu)
/dev/sdb2  *    268437504 499035680 230598177  110G  7 HPFS/NTFS/exFAT
/dev/sdb3       499036160 500115455   1079296  527M 27 Hidden NTFS WinRE

已安装安全启动，但未启用：

$ sbctl status
Installed:  ✓ sbctl is installed
Owner GUID: 1fd4cb4a-55ff-42f6-8dbb-285bfedf56de
Setup Mode: ✓ Disabled
Secure Boot:    ✗ Disabled
Vendor Keys:    microsoft

我的启动日志显示内核命令行和 TPM 相关条目（显示它已提前加载）：

$ sudo journalctl -k --grep='Command line|tpm|TPM'
Aug 30 06:10:03 archlinux kernel: Command line: initcall_blacklist=acpi_cpufreq_init amd_pstate=passive nvidia_drm.modeset=1 nvidia_drm.fbdev=1 ip=:::::eth0:dhcp
Aug 30 06:10:03 archlinux kernel: efi: ACPI=0xbd440000 ACPI 2.0=0xbd440014 TPMFinalLog=0xbd40a000 SMBIOS=0xbde22000 SMBIOS 3.0=0xbde21000 MEMATTR=0xb7f14018 ESRT=0xb7f14898 RNG=0xbcd38f18 INITRD=0xb6d12f18 TPMEvent>
Aug 30 06:10:03 archlinux kernel: ACPI: TPM2 0x00000000BCD50000 00004C (v04 ALASKA A M I    00000001 AMI  00000000)
Aug 30 06:10:03 archlinux kernel: ACPI: Reserving TPM2 table memory at [mem 0xbcd50000-0xbcd5004b]
Aug 30 06:10:03 archlinux kernel: tpm_crb MSFT0101:00: Disabling hwrng
Aug 30 06:10:03 archlinux systemd[1]: systemd 256.5-1-arch running in system mode (+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +K>
Aug 30 06:10:03 archlinux systemd[1]: Starting TPM PCR Barrier (initrd)...
Aug 30 06:13:19 ryzenbeast systemd[1]: systemd 256.5-1-arch running in system mode (+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +>
Aug 30 06:13:19 ryzenbeast systemd[1]: Expecting device /dev/tpm0...
Aug 30 06:13:19 ryzenbeast systemd[1]: Listening on TPM PCR Measurements.
Aug 30 06:13:19 ryzenbeast systemd[1]: Listening on Make TPM PCR Policy.
Aug 30 06:13:19 ryzenbeast systemd[1]: Starting TPM PCR Machine ID Measurement...
Aug 30 06:13:19 ryzenbeast systemd[1]: Starting Early TPM SRK Setup...

内核模块和钩子：

# mkinitcpio.conf
MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)
HOOKS=(base systemd autodetect microcode modconf keyboard keymap consolefont sd-vconsole block sd-tinyssh encryptssh sd-encrypt filesystems resume fsck)

LUKS 标头键槽：

$ sudo systemd-cryptenroll /dev/disk/by-partlabel/archlinux
SLOT TYPE    
   0 password
   1 recovery
   2 tpm2
$ sudo systemd-cryptenroll /dev/disk/by-partlabel/swap
SLOT TYPE    
   0 password
   1 tpm2

已签名的文件：

$ sbctl verify
Verifying file database and EFI images in /efi...
✓ /boot/EFI/Linux/arch-linux-fallback.efi is signed
✓ /boot/EFI/Linux/arch-linux.efi is signed
✗ /efi/EFI/Boot/bootx64.efi is not signed (this became signed after running `bootctl install`)
✓ /efi/EFI/systemd/systemd-bootx64.efi is signed
✓ /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed is signed
✗ /efi/EFI/GRUB/grubx64.efi is not signed
✗ /efi/EFI/Manjaro/grubx64.efi is not signed
✗ /efi/EFI/Microsoft/Boot/Resources/bootres.dll is not signed
✗ /efi/EFI/Microsoft/Boot/Resources/en-US/bootres.dll.mui is not signed
✗ /efi/EFI/Microsoft/Boot/bg-BG/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/bg-BG/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/bootmgfw.efi is not signed
✗ /efi/EFI/Microsoft/Boot/bootmgr.efi is not signed
✗ /efi/EFI/Microsoft/Boot/cs-CZ/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/cs-CZ/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/cs-CZ/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/da-DK/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/da-DK/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/da-DK/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/de-DE/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/de-DE/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/de-DE/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/el-GR/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/el-GR/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/el-GR/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/en-GB/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/en-GB/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/en-US/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/en-US/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/en-US/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/es-ES/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/es-ES/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/es-ES/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/es-MX/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/es-MX/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/et-EE/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/et-EE/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/fi-FI/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/fi-FI/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/fi-FI/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/fr-CA/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/fr-CA/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/fr-FR/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/fr-FR/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/fr-FR/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/hr-HR/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/hr-HR/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/hu-HU/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/hu-HU/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/hu-HU/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/it-IT/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/it-IT/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/it-IT/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ja-JP/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ja-JP/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ja-JP/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/kd_02_10df.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_02_10ec.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_02_1137.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_02_14e4.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_02_15b3.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_02_1969.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_02_19a2.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_02_1af4.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_02_8086.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_07_1415.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_0C_8086.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kdnet_uart16550.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kdstub.dll is not signed
✗ /efi/EFI/Microsoft/Boot/ko-KR/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ko-KR/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ko-KR/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/lt-LT/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/lt-LT/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/lv-LV/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/lv-LV/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/memtest.efi is not signed
✗ /efi/EFI/Microsoft/Boot/nb-NO/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/nb-NO/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/nb-NO/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/nl-NL/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/nl-NL/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/nl-NL/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/pl-PL/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/pl-PL/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/pl-PL/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/pt-BR/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/pt-BR/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/pt-BR/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/pt-PT/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/pt-PT/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/pt-PT/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/qps-ploc/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ro-RO/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ro-RO/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ru-RU/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ru-RU/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ru-RU/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/sk-SK/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/sk-SK/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/sl-SI/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/sl-SI/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/sr-Latn-RS/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/sr-Latn-RS/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/sv-SE/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/sv-SE/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/sv-SE/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/tr-TR/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/tr-TR/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/tr-TR/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/uk-UA/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/uk-UA/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/zh-CN/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/zh-CN/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/zh-CN/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/zh-TW/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/zh-TW/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/zh-TW/memtest.efi.mui is not signed
✗ /efi/EFI/ubuntu/grubx64.efi is not signed

系统测量

$ sudo /usr/lib/systemd/systemd-measure status
# PCR[11] kernel-boot
11:sha1=<SHA1SUM>
11:sha256=<SHA256SUM>
# PCR[12] kernel-config (NOT SET!)
12:sha1=0000000000000000000000000000000000000000
12:sha256=0000000000000000000000000000000000000000000000000000000000000000
# PCR[13] sysexts (NOT SET!)
13:sha1=0000000000000000000000000000000000000000
13:sha256=0000000000000000000000000000000000000000000000000000000000000000

$ sudo /usr/lib/systemd/systemd-measure calculate --current --bank=sha1 --bank=sha256
# PCR[11] Phase <enter-initrd>
11:sha1=<SHA1SUM_2>
11:sha256=<SHA256SUM_2>
# PCR[11] Phase <enter-initrd:leave-initrd>
11:sha1=<SHA1SUM_3>
11:sha256=<SHA256SUM_3>
# PCR[11] Phase <enter-initrd:leave-initrd:sysinit>
11:sha1=<SHA256SUM_4>
11:sha256=<SHA256SUM_4>
# PCR[11] Phase <enter-initrd:leave-initrd:sysinit:ready>
11:sha1=<SHA256SUM_5>
11:sha256=<SHA256SUM_5>

测试使用 TPM 打开根分区

$ sudo cryptsetup open --test-passphrase /dev/nvme0n1p7
Failed to unseal secret using TPM2: Operation not permitted
Enter passphrase for /dev/nvme0n1p7:

当前 PCR 时段

$ systemd-analyze pcrs
NR NAME                SHA256                                                          
 0 platform-code       <SHA256>
 1 platform-config     <SHA256>
 2 external-code       <SHA256>
 3 external-config     <SHA256>
 4 boot-loader-code    <SHA256>
 5 boot-loader-config  <SHA256>
 6 host-platform       <SHA256>
 7 secure-boot-policy  <SHA256>
 8 -                   0000000000000000000000000000000000000000000000000000000000000000
 9 kernel-initrd       <SHA256>
10 ima                 0000000000000000000000000000000000000000000000000000000000000000
11 kernel-boot         <SHA256>
12 kernel-config       0000000000000000000000000000000000000000000000000000000000000000
13 sysexts             0000000000000000000000000000000000000000000000000000000000000000
14 shim-policy         0000000000000000000000000000000000000000000000000000000000000000
15 system-identity     <SHA256>
16 debug               0000000000000000000000000000000000000000000000000000000000000000
17 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
18 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
19 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
20 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
21 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
22 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
23 application-support 0000000000000000000000000000000000000000000000000000000000000000

添加新的 TPM 条目

我知道我可以使用以下命令添加新的 TPM 条目并删除旧的条目：

# Enroll TPM (again).
$ sudo systemd-cryptenroll --tpm2-device=auto /dev/nvme0n1p7`
🔐 Please enter current passphrase for disk /dev/nvme0n1p7:
New TPM2 token enrolled as key slot 3.

# List LUKS unlock slots on my root partition.
$ sudo systemd-cryptenroll /dev/nvme0n1p7 
SLOT TYPE    
   0 password
   1 recovery
   2 tpm2
   3 tpm2

# Wipe the old tpm2 entry
$ sudo systemd-cryptenroll /dev/nvme0n1p7 --wipe-slot=2
Wiped slot 2.

# Test I can open it
$ sudo cryptsetup open --test-passphrase /dev/nvme0n1p7
$

更新：系统日记帐分录

我检查了journalctl -u systemd-cryptsetup@root一下是否可以在第一次启动失败之前和之后找到更多信息。

启动成功后：

Aug 27 09:46:02 archlinux systemd[1]: Starting Cryptography Setup for root...
Aug 27 09:46:02 archlinux systemd-cryptsetup[407]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/gpt-auto-root-luks.
Aug 27 09:46:02 archlinux systemd-cryptsetup[407]: Automatically discovered security TPM2 token unlocks volume.
Aug 27 09:46:04 archlinux systemd-cryptsetup[407]: Successfully extended PCR index 15 with 'cryptsetup:root:<UUID>' and volume key (banks sha1, sha256).
Aug 27 09:46:04 archlinux systemd[1]: Finished Cryptography Setup for root.

下次启动失败时：

Aug 28 08:09:52 archlinux systemd[1]: Starting Cryptography Setup for root...
Aug 28 08:09:52 archlinux systemd-cryptsetup[403]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/gpt-auto-root-luks.
Aug 28 08:09:52 archlinux systemd-cryptsetup[403]: Automatically discovered security TPM2 token unlocks volume.
Aug 28 08:09:53 archlinux systemd-cryptsetup[403]: Failed to unseal secret using TPM2: Operation not permitted
Aug 28 08:09:53 archlinux systemd-cryptsetup[403]: No valid TPM2 token data found.
Aug 28 08:09:53 archlinux systemd-cryptsetup[403]: No TPM2 metadata matching the current system state found in LUKS2 header, falling back to traditional unlocking.
Aug 28 08:10:21 archlinux systemd-cryptsetup[403]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/gpt-auto-root-luks.
Aug 28 08:10:24 archlinux systemd-cryptsetup[403]: Failed to activate with specified passphrase. (Passphrase incorrect?)
Aug 28 08:10:30 archlinux systemd-cryptsetup[403]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/gpt-auto-root-luks.
Aug 28 08:10:33 archlinux systemd-cryptsetup[403]: Successfully extended PCR index 15 with 'cryptsetup:root:<UUID>' and volume key (banks sha1, sha256).
Aug 28 08:10:33 archlinux systemd[1]: Finished Cryptography Setup for root.

这里提到了 PCR15，解释man systemd-cryptenroll如下：

systemd-cryptsetup(8) 可选择将激活的 LUKS 卷的卷密钥纳入此 PCR。systemd-pcrmachine.service(8) 将 machine-id(5) 纳入此 PCR。[email protected] (8) 将挂载点、文件系统 UUID、标签、根和 /var/ 文件系统的分区 UUID 纳入此 PCR。

看起来这些测量值会通过（重新）格式化分区而改变，并且足以破坏这个 PCR 寄存器......

悬而未决的问题

现在我已经研究如何解决这个问题并且有效地完成了，但我还有疑问！

  • 什么原因导致 TPM 插槽值变得不正确？
    • 如果我更新 Ubuntu 的内核或 initrd，这种情况会再次发生吗？
  • 如何防止此类事件再次发生？
  • 我看到在2023 年 11 月systemd引入了pcrlock 工具，但（我认为）它仍处于实验阶段，我不完全了解它，也不知道它是否有帮助。会吗？
  • 更新：格式化分区后，如何更新 PCR 15？
systemd