Início / unix / 问题

Perguntas[systemd](unix)

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

A saída de lsnsparece diferente com base no privilégio do usuário que o executa. ubuntuusuário e rootusuário obtêm resultados diferentes:

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:~$

Além disso, o nome do processo init do sistema Ubuntu é diferente: systemdvs /sbin/init. Qual é o motivo disso? Obrigado.

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

Estou tendo alguns problemas com a inicialização de um Ubuntu 24.04.1 novo da Intel Optane (que acabei de receber do eBay): o processo de inicialização é rápido, mas de vez em quando algumas unidades systemd não são executadas durante a inicialização, o sistema inicia sem o NetworkManager ou algo como snapd-apparmor. O log journalctl relata que há ciclos de ordenação. Tentando encontrá-los, percebi que ele systemd-analyze verify multi-user.targetrelata coisas diferentes quase toda vez que o executo:

$ 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

Desconfiado do disco do eBay, tentei o mesmo no Ubuntu 22.04 instalado anteriormente em um Corsair NVMe, com os mesmos resultados:

$ 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

O processo de inicialização no Corsair NVMe tem problemas semelhantes com a não inicialização de algumas unidades systemd. Mas é menos frequente.

Por que isso está acontecendo? Eu perdi algo sobre systemd-analyze verify? Como é systemd-analyze verifypossível relatar um número diferente de ciclos toda vez que você o executa?

As versões. No Intel Optane:

$ 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"

E a instalação anterior no Corsair NVMe ( lspcina verdade, é relatado como 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

Eu entro no wish SSH como um usuário "Ubuntu" em um servidor. No entanto, quero gerenciar a execução de alguns serviços systemd como outro usuário "ABC".

Se eu tentar sudo -u abc bashcomo usuário ABC, todo systemd --usercomando dará o erro:

Failed to connect to bus: No medium found

Encontrei este tópico que sugeriu adicionar o seguinte a ~/.bashrc:

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

Isso altera o erro para:

Failed to connect to bus: No such file or directory

Outras fontes sugeriram que servidores headless normalmente não têm dbus instalado, então isso faz sentido (parece ser um componente do x11). Embora eu não saiba por que funciona sem problemas se eu o executo como ubuntu.

Encontrei esta solução alternativa sugerida

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

Isso funciona para start, , básico stop, statusmas:

  • systemctl --user catnão funciona
  • Nenhuma variação journalctlparece funcionar:
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
  • É muito longo para digitar e inconveniente.

Eu realmente só quero um shell para esse outro usuário, assim como quando eu entro ubuntu, e posso gerenciar todos os meus serviços de usuário sem problemas.

Menciono o Podman porque o Podman também fica realmente infeliz quando o executo como um usuário diferente. Ele funciona bem se eu o uso como, ubuntumas dá erros se eu o executo com sudo -u. Como o systemd, tenho algumas soluções alternativas parciais, mas nenhuma parece funcionar bem.

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

Tenho duas interfaces de rede, eno1 e eth0. Gostaria que ambas usassem DHCP para obter um endereço IP. Gostaria que eno1 fosse usado como rota padrão para tudo. A única vez que quero usar eth0 é ao especificar interface em um comando curl.

Criei dois arquivos de configuração:

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

Tentei reiniciar e mexer nas métricas, mas elas não surtiram efeito.

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

Tentando executar um serviço systemd com systemctl --user start foo.servicewhich contém ExecStart=touch /bar/bazwhere /barhas permissions drwxrwxr-x 1 root storage. O usuário que está executando o comando pertence ao grupo storagee pode executar o touchcomando do shell sem problemas, criando o arquivo. O serviço, no entanto, falha com um erro de permissão.

Pensei que as permissões do serviço corresponderiam ao usuário que o executa - e, de fato, fazer com que o serviço use a ${USER}variável de ambiente em seu comando produz meu usuário, e o serviço aparece em minhas listas psou .pstree ${USER}

foo.servicenão contém ProtectSystemou qualquer entrada diferente de: Description, EnvironmentFile, Environment, ExecStart, KillSignal, Restart, RestartSec. As entradas de ambiente são para carregar configuração não relacionada a permissão.

O serviço não usa realmente o usuário chamador para permissões? E se não, qual seria a melhor abordagem para resolver o problema? /barestá em uma unidade montada, então posso apenas dmask 0000no meu fstab, mas prefiro evitar essa abordagem.

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

Tenho duas referências que parecem confiáveis, mas oferecem informações diferentes.

Na primeira referência, é mencionado que default.targeté um dos alvos iniciais executados. Então (assumindo que queremos que o sistema inicialize no modo CLI) multi-user.targetserá executado, seguido por basic.target, e finalmente, chegaremos a sysinit.target.

Entretanto, na segunda referência, o processo é descrito na ordem oposta! Ele afirma que sysinit.targeté executado primeiro, seguido por basic.target, e assim por diante.

Estou confuso. Qual ordem está correta? /sbin/initCom ​​qual alvo começa logo no começo?

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

Então eu tenho um caso um pouco especial.

Depois que a máquina inicializar, preciso que uma das unidades da máquina tenha uma partição não formatada que seja gravável por todos.

O motivo: um aplicativo está criando seu próprio sistema de arquivos nessa partição.

O problema:

Eu montei um script systemd que faz umchmod a+rw /dev/$partition_name

Se eu verificar as permissões via statou ls -l, a permissão gravável "outra" parece boa

por exemplo ébrw-rw-rw-

NO ENTANTO, depois que a máquina inicializou, as permissões foram alteradas para:

brw-rw---.

Então as perguntas:

  1. por que as permissões continuam mudando?
  2. qual é a maneira correta de fazer isso?
systemd
Martin Hope
Braedon
Asked: 2024-09-20 08:17:51 +0800 CST
  • 5

Tenho que unidades Systemd de um serviço e um soquete. O comportamento desejado é que quando eu iniciar o soquete o serviço será iniciado primeiro seguido pelo soquete e quando qualquer um for desativado ambos devem ser desativados. O serviço se vincula ao soquete antes que a unidade de soquete seja iniciada, e é por isso que o tenho como um serviço de notificação para que ele não relate como iniciado até que tenha o vínculo no soquete.

Aqui estão os arquivos das duas Unidades.

#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

A mensagem de erro é a seguinte.

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

Pelos recursos, parece que significa que o ciclo está acontecendo apenas com esses dois arquivos e eu posso limpar o erro removendo a linha After do arquivo .socket, mas então eles inicializam simultaneamente e o executável para o serviço falha. Eu provavelmente poderia resolver isso simplesmente adicionando um sleep ao socket, mas não vejo informações de dependência suficientes aqui para causar um ciclo.

Eu tentei limpar /{lib,etc}/systemd/system do serviço e do arquivo de socket e reinstalar os que foram colados aqui só para ter certeza de que versões mais antigas não estavam em execução e, claro, executar systemctl daemon-reload regularmente enquanto o modificava. Mas não consigo entender por que especificar depois quebra o gráfico de dependências mesmo depois de remover as dependências do arquivo de serviço.

Onde está acontecendo o loop que estou perdendo?

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

Tenho um computador executando o Fedora Workstation 40 e o Systemd 255. Por algum motivo, as mensagens de log do kernel ficam disponíveis no Diário por muito menos tempo do que outras mensagens de log.

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'

Usar o comando journalctl com sudo não faz diferença. De acordo com journalctl --verifytodos os arquivos do Journal, eles estão OK.

A configuração do Journald está usando os valores padrão:

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

Há espaço livre suficiente em disco disponível:

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

O que pode estar causando isso e como fazer com que as mensagens do kernel permaneçam no Journal tanto tempo quanto outras mensagens?

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

Recentemente, instalei o Ubuntu em um SSD antigo, pois queria testar algum software em um sistema operacional diferente. Depois de instalar o Ubuntu (usando debootstrap, arch-chroote apt), a ordem de inicialização da NVRAM do meu EFI ficou bagunçada, e o TPM2 não desbloqueará automaticamente minhas partições raiz e swap do Arch. Sou solicitado a inserir uma chave de recuperação ou senha.

Então, eu sei que preciso atualizar os registros de PCR no TPM. Mas tenho algumas perguntas:

  • Como devo substituir as entradas nos antigos slots TPM2 PCR, em vez de adicionar novas?
  • Alguém pode explicar por que o chip TPM agora não consegue desbloquear minhas partições e o que devo tentar evitar fazer novamente no futuro?

Meu sistema operacional principal é o Arch Linux, configurado seguindo alguns artigos:

systemd-booté usado como bootloader.

Duas partições dm-crypt são desbloqueadas com o TPM na inicialização:

  • root
  • swap(permite suspender e retomar).

Após instalar o Ubuntu, os volumes roote swapnão foram desbloqueados com o TPM.

Como invalidar os Registros TPM PCR

Uma coisa que percebi que fiz incorretamente foi instalar o Ubuntu (em /media/ubuntu) antes de montar /efiem /media/ubuntu/boot/efi. Então, depois de instalar o Ubuntu com debootstrap, executei:

  • mount --bind /efi /media/ubuntu/boot/efi
  • arch-chroot /media/ubuntu
  • apt install grub-efi-amd64(Isso remove grub-pc)
  • grub-install

Então, agora tenho uma /efipartição, uma /bootpartição criptografada para o Arch Linux, e a partição do Ubuntu tem uma /bootpasta. (Há um bootloader do Windows também, então sim, é uma bagunça...)

grub's os-probenão detecta minha instalação do Arch Linux, então tive que voltar pressionando F11no início da inicialização e selecionando Linux Boot Manager. Neste ponto, systemdpede para eu digitar a senha de desbloqueio ou a chave de recuperação para minha partição raiz. (Eu tenho as duas atualmente, então entrar não é um problema, a menos e até que eu reinicie remotamente).

Minha configuração

Coloquei uma longa lista de comandos de diagnóstico, que devem ser muito úteis para qualquer um que esteja diagnosticando algo semelhante no futuro (eu incluso, sem dúvida!)

Atualização: O TPM foi registrado para desbloquear a partição criptografada no PCR 7, assim:

# 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

Minhas tabelas de partição estão bastante ocupadas:

$ 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

O Secure Boot está instalado, mas não habilitado:

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

Meus logs de inicialização mostrando a linha de comando do kernel e entradas relacionadas ao TPM (mostrando que ele foi carregado antecipadamente):

$ 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...

Módulos e ganchos do kernel:

# 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)

Slots de chave de cabeçalho 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

Arquivos assinados:

$ 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

Medições do Systemd

$ 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>

Teste a abertura da partição raiz com TPM

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

Slots PCR atuais

$ 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

Adicionando uma nova entrada TPM

Sei que posso adicionar uma nova entrada TPM e excluir a antiga com o seguinte comando:

# 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
$

Atualização: Lançamentos de diário do sistema

Verifiquei journalctl -u systemd-cryptsetup@rootse conseguia obter mais informações antes e depois da primeira inicialização com falha.

Em uma inicialização bem-sucedida:

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.

Na próxima inicialização com falha:

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.

Vendo menção de PCR15 aqui, explicado man systemd-cryptenrollcomo:

systemd-cryptsetup(8) optionally measures the volume key of activated LUKS volumes into this PCR. systemd-pcrmachine.service(8) measures the machine-id(5) into this PCR. [email protected](8) measures mount points, file system UUIDs, labels, partition UUIDs of the root and /var/ filesystems into this PCR.

It would appear that these measurements would have changed by (re-)formatting a partition and would be enough to corrupt this PCR register...

Overhanging Questions

Now I've looked into fixing this and effectively have done, I have questions!

  • What caused the TPM slot value to become incorrect?
    • If I update Ubuntu's kernel or initrd, will it happen again?
  • How to prevent this from happening again?
  • I see systemd introduced a pcrlock tool in November 2023, but (I think) it is still experimental and I don't fully understand it, nor do I know if it would help. Would it?
  • Update: How should I update PCR 15 after formatting a partition?
systemd