xealits's questions

Tenho uma placa Petalinux (uma Trenz Electronic com um AMD/Xilinx Zynq UltraScale+ MPSoC) que inicializa com uma configuração de conexão de rede errada (sem DHCP). Ela não tem configurações em /etc:

$ ls /etc/NetworkManager/system-connections/
$ 

Depois de configurar a conexão, sudo nmcli con mod eth0 ...ela funciona bem. (Eu modifico a configuração ipv4 e ipv6, como aqui no stackoverflow .) E ele cria um arquivo de configuração permanente em /etc:

/etc/NetworkManager/system-connections/eth0.nmconnection

Mas, após uma reinicialização, o NetworkManager cria uma nova /runconfiguração, que de alguma forma tem precedência sobre minha conexão em /etc:

$ nmcli -f TYPE,FILENAME,UUID,NAME,DEVICE connection
TYPE      FILENAME                                                  UUID                                  NAME  DEVICE 
ethernet  /run/NetworkManager/system-connections/eth0.nmconnection  99e39a32-c0ab-4b3f-be16-75a9bdff1277  eth0  eth0   
loopback  /run/NetworkManager/system-connections/lo.nmconnection    5d84c484-4214-47e4-8f00-01f7730200b3  lo    lo     
ethernet  /etc/NetworkManager/system-connections/eth0.nmconnection  fb365147-6ad9-47a0-a5c8-fbea10080ece  eth0  --     

Aqui, o invasor 99e39a32se /runconectou ao eth0dispositivo, e minha /etcconfiguração de conexão fb365147permanece ociosa.

Como salvar corretamente e permanentemente uma configuração de conexão no NetworkManager, ou fazê-lo usar /etca configuração como o único modelo para a eth0conexão? Onde ele obtém as configurações para /run? Por que ele não costuma /etccriar /runconfigurações?

Há posts dizendo que o NetworkManager cria conexões por usuário. Ou seja, a sugestão era algo como /etcé root e de alguma forma outras conexões são usadas para meu usuário. Mas não acho que seja o caso aqui. nmclinão me deixa modificar uma conexão sem permissões de root.

Há uma série de perguntas semelhantes na internet: 1 (não tenho /etc/netplano arquivo mencionado em um comentário lá), 2 , 3. Mas elas não ajudam no meu caso.

Atualizar:

Há algumas informações de como a /runconfiguração é feita graças ao log journalctl -u NetworkManagerapós a inicialização do computador [loggin] level=TRACEem /etc/NetworkManager/NetworkManager.conf:

NetworkManager[347]: <info>  [1734374462.9312] device (eth0): carrier: link connected
NetworkManager[347]: <trace> [1734374462.9313] ethtool[3]: ETHTOOL_GSET, eth0: success
NetworkManager[347]: <debug> [1734374462.9317] device[e5c0e28febbc1b13] (eth0): unmanaged: flags set to [platform-init,!user-settings=0x4/0x14/unmanaged/unrealized], set-managed [user-settings=0x10])
NetworkManager[347]: <debug> [1734374462.9318] device[e5c0e28febbc1b13] (eth0): unmanaged: flags set to [!platform-init,!user-settings=0x0/0x14/managed/unrealized], set-managed [platform-init=0x4])
NetworkManager[347]: <debug> [1734374462.9318] device[e5c0e28febbc1b13] (eth0): unmanaged: flags set to [!sleeping,!platform-init,!user-settings=0x0/0x15/managed/unrealized], set-managed [sleeping=0x1])
NetworkManager[347]: <trace> [1734374462.9319] dbus-object[e5c0e28febbc1b13]: export: "/org/freedesktop/NetworkManager/Devices/2"

NetworkManager[347]: <info>  [1734374462.9329] manager: (eth0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/2)
NetworkManager[347]: <trace> [1734374462.9349] settings: auto-default: cannot create auto-default connection for device eth0: already has a profile
<----- this already existing "profile" must be the config in /etc
       when I added no-auto-default=* or eth0 in NetworkManager.conf
       this line said: cannot create auto-default.. because no-auto
...
NetworkManager[347]: <debug> [1734374462.9356] Connection 'eth0' differs from candidate 'eth0' in ipv4.addresses, ipv4.gateway, ipv4.method
NetworkManager[347]: <debug> [1734374462.9357] manager: (eth0): assume: generated connection 'eth0' (b807ebb2-d7a5-4b26-82c1-c321a6e7d5ba)
NetworkManager[347]: <debug> [1734374462.9357] device[e5c0e28febbc1b13] (eth0): assume-state: set guess-assume=0, connection=(null)
NetworkManager[347]: <trace> [1734374462.9370] keyfile: commit: b807ebb2-d7a5-4b26-82c1-c321a6e7d5ba (eth0) added as "/run/NetworkManager/system-connections/eth0.nmconnection" (nm-generated,volatile,external)

Acho que a questão agora é o que significa Connection 'eth0' differs from candidate 'eth0' ...- o que é esse candidato? Ou seja, provavelmente há mais alguma configuração para o eth0próprio dispositivo, e quando a /etcconfiguração entra em conflito com essa, o NetworkManager cria uma nova?

Tentei adicionar este arquivo sem nenhuma alteração no comportamento (provavelmente está obsoleto):

$ cat /etc/network/interfaces
auto eth0
iface eth0 inet dhcp

Atualização 2:

Só para ressaltar, tentei adicionar no-auto-defaultconfiguração, mas não fez diferença neste caso:

/etc/NetworkManager/NetworkManager.conf

[main]
no-auto-default=*
# or no-auto-default=eth0

E adicionar a conexão /etc/network/interfacestambém não ajudou:

# Wired interfaces
auto eth0
iface eth0 inet dhcp
    hwaddress ether <MAC address>

Eu acho que, como @telcoM sugeriu, é um comportamento específico do Petalinux. Você define as configurações para o dispositivo eth0 quando a imagem é construída (e aparentemente o NetworkManager pode de alguma forma ler as configurações do dispositivo ou o quê?), e você não pode modificar as configurações de ethernet no Petalinux depois que a imagem foi construída . Provavelmente, não há nada que você possa modificar no ZynqMP>console do uboot também.

Então, o que acabei fazendo foi: renomear minha conexão e eth0dhcpadicionar uma unidade systemd que a conecta após a inicialização.

sudo nmcli c mod fb365147-6ad9-47a0-a5c8-fbea10080ece con-name eth0dhcp

A configuração da conexão se parece com:

$ sudo cat /etc/NetworkManager/system-connections/eth0.nmconnection 
[connection]
id=eth0dhcp
uuid=fb365147-6ad9-47a0-a5c8-fbea10080ece
type=ethernet
autoconnect=false
interface-name=eth0
timestamp=1734377647
 
[ethernet]
mac-address=<mac address>
 
[ipv4]
method=auto
 
[ipv6]
addr-gen-mode=default
method=auto
 
[proxy]

E a unidade systemd one-shot:

[Unit]
Description=UP the eth0dhcp for eth0 after boot
 
After=network.target
Requires=network.target
 
[Service]
Type=oneshot
RemainAfterExit=yes
User=root
ExecStart=nmcli con up eth0dhcp
 
SuccessExitStatus=0
Restart=on-failure
RestartSec=20
 
StartLimitInterval=300
StartLimitBurst=5
 
[Install]
WantedBy=multi-user.target

É uma solução alternativa suficiente no meu caso. Mais tarde, vamos apenas construir imagens com quaisquer configurações que forem necessárias.

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"

Eu queria ter uma unidade de serviço personalizada dependendo de um ponto de montagem de um sistema de arquivos remoto CVMFS. O sistema de arquivos remoto tem uma configuração estranha no systemd que eu não entendo completamente. Eu fiz uma solução alternativa simples com uma unidade de serviço intermediária, então funciona bem. Mas eu gostaria de entender como as unidades do sistema de arquivos remoto funcionam, para estar ciente desse comportamento no systemd.

Aqui está a unidade de ponto de montagem do sistema de arquivos remoto:

$ systemctl status cvmfs-sft.cern.ch.mount
* cvmfs-sft.cern.ch.mount
     Loaded: loaded
     Active: active (mounted) since Wed 2024-07-31 23:31:49 CEST; 1min 32s ago
      Until: Wed 2024-07-31 23:31:49 CEST; 1min 32s ago
      Where: /cvmfs/sft.cern.ch
       What: cvmfs2

Ele não lista um arquivo de unidade . A unidade deve ter sido criada dinamicamente de alguma forma. Então, quando adiciono um Requires=cvmfs-sft.cern.ch.mountà minha unidade, ele falha durante a inicialização do Linux com isto:

localhost systemd[1]: Failed to start A one shot script ...
<hostname> systemd[1]: ....service: Failed to schedule restart job: Unit cvmfs-sft.cern.ch.mount not found.

No entanto, se eu iniciar minha unidade após o boot, ela funciona bem. Ou seja, a Requires=cvmfs-sft.cern.ch.mountdependência funciona bem quando eu entro como um usuário normal, o servidor atingiu o alvo multiusuário, o cvmfs está montado e essa unidade cvmfs-sft.cern.ch.mountestá ativa.

O que eu esperava é ter arquivos de unidade reais para os pontos de montagem do cvmfs. O sistema de arquivos remoto levaria seu tempo para montar esses pontos de montagem, e minhas unidades prosseguiriam a partir daí.

De acordo com a documentação do CVMFS , o que realmente gerencia esse sistema de arquivos é isso autofs.service. O autofsserviço executa pontos de montagem como este:

$ systemctl status autofs
* autofs.service - Automounts filesystems on demand
     Loaded: loaded (/usr/lib/systemd/system/autofs.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/autofs.service.d
             `-50-cvmfs.conf
...
     CGroup: /system.slice/autofs.service
             |-3405 /usr/bin/cvmfs2 ... sft.cern.ch /cvmfs/sft.cern.ch
...

O que eu quero perguntar é o que pode criar tais unidades sem arquivos de unidade no systemd? Se eu tiver um script init.d, o systemd sempre o traduz em um arquivo de unidade real, não é? Neste caso em particular, o status da unidade diz What: cvmfs2. Isso significa que cvmfs2usar o seguinte recurso de systemd.mount?

$ man systemd.mount
...
DESCRIPTION
       ...
       The systemd-mount(1) command allows creating .mount and .automount units
       dynamically and transiently from the command line.

Acho que você precisa desse comportamento transitório para pontos de montagem, no caso em que o usuário conecta uma unidade USB no computador, etc. Mas outros tipos de unidades podem ser criados transitoriamente , ou seja, em tempo real, sem um arquivo de unidade?

Existe uma boa maneira de descobrir o que lançou uma unidade tão transitória? No meu caso, as dependências da unidade não me dizem nada:

$ sudo systemctl list-dependencies cvmfs-sft.cern.ch.mount
cvmfs-sft.cern.ch.mount
* |--.mount
* `-system.slice
$ sudo systemctl list-dependencies --reverse cvmfs-sft.cern.ch.mount
cvmfs-sft.cern.ch.mount

Existe algum outro systemctlcomando que possa lhe dizer algo mais sobre a procedência de uma unidade transitória como essa?