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.target
relata 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 verify
possí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 ( lspci
na 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"
De alguma forma, é causado por uma
mount
unidade personalizada. Não sei por quê. Mas, olhando os logs e o quesystemd-analyze verify
foi impresso, a unidade pareceu aparecer na sequência em cada "ciclo de ordenação encontrado". Então, desabilitei e adicionei umaautomount
unidade para montar esse diretório personalizado depois que o usuário fizer login. Agorasystemd-analyze verify multi-user.target
nunca encontra problemas. E a inicialização funciona bem.A unidade de montagem personalizada se parece com isso:
Desativei-o e habilitei a
automount
unidade adicional para acionar a montagem:Agora funciona que é uma maravilha.
Não vejo por que essa
mount
unidade causou os ciclos de pedidos. Qualquer ideia sobre o que está acontecendo é bem-vinda. Mas vou fechar esta pergunta, pois não há comentários ou respostas.