Perguntas[debian](unix)

Configurar

Suponha que estamos instalando uma versão atual do Debian (ou seja, Bookworm de 03/2025) em um PC moderno e "padrão", ou seja, alguma CPU moderna de arquitetura x86_64 onde nenhum módulo de kernel especial ou qualquer entrada especial do usuário é necessária durante a instalação (além da configuração regular de alto nível, como layouts de teclado, etc.). É a instalação mais básica e simples em um SSD, onde é o único sistema operacional instalado, em uma máquina que tem apenas este SSD como disco rígido.

Agora pegamos esse SSD e o movemos para um PC diferente, mesma simplicidade básica, mas possivelmente uma CPU diferente (por exemplo, um talvez tivesse um AMD e o outro um Intel, mas ambos x86_64) e possivelmente uma placa-mãe diferente (novamente, para efeito de argumentação, digamos que estamos trocando entre Intel e AMD). Talvez mais ou menos RAM ou uma placa de vídeo diferente (ou vídeo onboard). Provavelmente um chip de rede diferente, chip de áudio, controlador USB e o que mais vier com a placa-mãe. Mas tudo isso perfeitamente suportado pelo Debian com os módulos de kernel padrão. Ambas as máquinas funcionariam perfeitamente se o Debian fosse instalado do zero em qualquer uma delas e teriam capacidades comparáveis.

Além da instalação básica (com algum ambiente X, como Gnome ou KDE, nas configurações básicas padrão).

Pergunta

Alguém esperaria que para esta instalação tivéssemos movido do PC 1 para o PC 2 simplesmente movendo o SSD para funcionar perfeitamente desde a primeira inicialização? Ou algumas coisas, durante a instalação do Debian, são instaladas ou configuradas apenas conforme necessário para o hardware específico, então há uma chance significativa de que algo não funcione imediatamente no segundo PC?

Adenda

... se a resposta fosse "sim, algo provavelmente daria errado", há algo que possa ser feito após a instalação inicial no PC 1 para tornar mais provável que tal movimento funcione em um novo PC (sem saber exatamente qual PC seria)?

Reescrevi este parágrafo de abertura... tentando esconder meu desdém por systemd. Vou me contentar em dizer que acho systemda "lógica" de desconcertante, e deixar por isso mesmo. Para chegar à pergunta:

Tenho tentado reduzir o tempo de inicialização relatado por systemd-analyze timeem um pequeno Raspberry Pi Zero 2W . O SO é cerca de 95% Debian com um pouco de Raspberry Pi para lidar com o hardware.

Comecei listando os arquivos de unidade ativos e, a partir dessa lista, cheguei a alguns serviceque eu tinha certeza de que poderiam ser removidos sem impacto:

$ systemctl list-unit-files --state=enabled
...
rpi-display-backlight.service      enabled enabled
rpi-eeprom-update.service          enabled enabled
...
$

Eu escolhi disableambos os serviços da seguinte forma:

$ sudo systemctl disable rpi-eeprom-update.service rpi-display-backlight.service
Removed "/etc/systemd/system/halt.target.wants/rpi-display-backlight.service".
Removed "/etc/systemd/system/poweroff.target.wants/rpi-display-backlight.service".
Removed "/etc/systemd/system/reboot.target.wants/rpi-display-backlight.service".
Removed "/etc/systemd/system/multi-user.target.wants/rpi-eeprom-update.service".

Decepcionantemente, descobri que o tempo de inicialização (conforme relatado por systemd-analyze time) na verdade aumentou em cerca de 3 segundos. Reiniciei algumas vezes para obter uma "média"; o aumento de 3 segundos parecia real e persistente. Fiquei pensando se esse aumento poderia ser devido a systemd uma nova tentativa de iniciar esses serviços. E então procurei dependências com outras systemd"unidades":

$ systemctl list-dependencies rpi-eeprom-update.service
rpi-eeprom-update.service

$ systemctl list-dependencies rpi-display-backlight.service
rpi-display-backlight.service
● └─system.slice
$

Tomei o primeiro resultado (rpi-eeprom) como uma indicação de que não havia outras dependências. O segundo resultado (rpi-display) é desconcertante para mim. Fiz um pouco de pesquisa .slicedesde então, mas ainda faz pouco (na verdade, nenhum) sentido para mim. O que me leva à minha pergunta:

Alguém pode explicar como editar isso system.slicee remover o rpi-display-backlight.service?

Estou seguindo este tutorial explicando que posso referenciar caracteres com seu unicode, ou com seu nome definido dentro de /usr/include/X11/keysymdef.h. No entanto, este arquivo não existe no meu sistema (Debian).

Fiz uma pesquisa com sudo grep -rl "Greek_alpha"inside /usr, mas ela me deu resultados irrelevantes, nada parecidos com as definições que estou procurando. ( Greek_alphaé um dos aliases que estou procurando, você pode encontrar um em usr/share/X11/xkb/symbols/grpor exemplo.)

Onde posso encontrar a lista completa desses KeySyms / variáveis ​​/ aliases no meu computador?

Encurtar a entrada do shell para 'apt-lisbugs' para que ele possa ser executado a partir de 'apt list --upgradable' é necessário. Quando eu entro, :~$ apt list --upgradablea saída se parece com:

cracklib-runtime/testing 2.9.6-5.2+b1 amd64 [upgradable from: 2.9.6-5.2]
i2c-tools/testing 4.4-1+b3 amd64 [upgradable from: 4.4-1+b2]
libaudit1/testing 1:4.0.2-2+b2 amd64 [upgradable from: 1:4.0.2-2+b1]

Existe uma maneira de inserir nomes de pacotes somente para o comando 'apt-listbugs' para que ele envolva somente nomes no :~$ apt-listbugs list cracklib-runtime i2c-tools libaudit1estilo?

Aparentemente, "quebrei" o acesso de rede a um dos meus sistemas 'bookworm' Debian que rodam em hardware Raspberry Pi. Isso resultou da minha aparente falta de entendimento dos detalhes sobre como as várias "ferramentas de rede" operam. O sistema quebrado é uma unidade "sem cabeça"; não consigo mais fazer uma conexão SSH com ele. Ele nem responde a um ping.

Estou levantando essa questão aqui na tênue esperança de que alguém possa explicar se há uma maneira de recuperar o acesso SSH sem fazer nenhuma alteração no sistema. Meu recurso atual é remover o SSD NVME e montá-lo em outro sistema para corrigir o erro de configuração ou conectar um monitor e teclado, mas isso é difícil devido à falta de hardware/cabos, etc.

O que eu fiz: Fiquei "farto" da nmcliinterface arcana do NM e pensei: "deve haver uma maneira melhor". Li esta página no site do Debian ; especificamente:

O NetworkManager manipulará apenas interfaces não declaradas em /etc/network/interfaces

Interpretei isso como se eu declarasse minha interface WiFi ( wlan0) em /etc/network/interfaces, então NetworkManager"se afastaria" e systemdusaria ifup, ifdown, etc para gerenciar wlan0IAW o conteúdo que adicionei a /etc/network/interfaces. Aqui está o conteúdo do interfacesarquivo que criei:

iface wlan0 inet static
    address 192.168.1.222
    netmask 255.255.255.0
    gateway 192.168.1.1
    dns-nameservers 192.168.1.1

Depois rebootdescobri que não conseguia mais acessar este sistema via SSH.

Tenho duas perguntas:

1. Existe alguma maneira de recuperar o acesso SSH sem fazer alterações no sistema?
2. Por que os dados que inseri /etc/network/interfacesnão geraram uma conexão Wi-Fi funcional?

Comprei uma placa Wifi7 rodando no Debian conforme minhas perguntas e respostas . A placa é baseada no chip BE200NGW da Intel.

Apesar de Multi Link Operation estar habilitado no roteador Wifi7, a máquina Debian executando o kernel 6.12.12 conecta-se ao roteador somente em uma banda (2.4 ou 5GHz). Para comparação, o Windows 11 usa esta placa no modo Wifi7.

Módulos carregados:

$ lsmod | grep iwlwifi
iwlwifi               581632  1 iwlmvm
cfg80211             1392640  6 ath9k_common,iwlmvm,ath9k,ath,iwlwifi,mac80211

Eu dei uma olhada nas iwconfigurações, mas ainda não as entendi completamente. No entanto, também dei uma olhada nas especificações sem fio do NetworkManager 802.11 . Não encontrei nada lá confirmando que o NetworkManager é compatível com Wifi7, ou seja, que ele suporta conexões simultâneas ao mesmo SSID em bandas diferentes.

Devo esperar até que os recursos do Wifi 7 sejam totalmente suportados na pilha de rede ou há algo que eu possa alterar nas configurações ou nos módulos carregados?

Atualização 2025-02-23

Inspirado pelos comentários de grawity , eu tenho:

• versão verificada wpa_supplicant- é 2.10 (estou no Debian testing)
• verifiquei o protocolo de autenticação usado por NetworkManager: era WPA2. Lembrando que WPA3 é necessário para 6 GHz, alterei essa configuração para WPA3 Personal. Resultado: a placa agora usa banda de 6 GHz com taxa de link de aproximadamente 1,4 Gbps, o que já é uma melhoria em relação ao gigabit Ethernet da minha casa. Fico imaginando por que a NM exigiu uma intervenção manual para usar WPA3.
• em busca do MLO, modifiquei wpa_supplicant.servicea unidade adicionando -Dnl80211opções de inicialização. A configuração original não usou nenhuma -Ddiretiva. Eu queria garantir que o driver Wireless Extensions não fosse usado, pois ele não suporta Wifi7. No entanto, isso não habilitou o MLO, então eu já devo ter estado nl80211lá antes.

Quero sair automaticamente da sessão da interface gráfica do usuário após inicializar o PC porque um programa que uso não roda a menos que eu saia e entre novamente.

Eu escrevi um crontabcom este comando:

@reboot gnome-session-quit --logout --no-prompt

Mas não está funcionando.

Tenho o Debian 12 com criptografia de disco completo. O Cryptsetup desbloqueia o volume com a versão 6.1.0-28 do kernel Linux, mas falha com qualquer versão posterior, como segue.

Please unlock disk sdXY_crypt: **********
No key available with this passphrase.
cryptsetup: ERROR: sdXY_crypt: cryptsetup failed, bad password or options?

No período exato entre os kernels 6.1.0-28 e 6.1.0-29, instalei o VeraCrypt para uso com contêineres. Nunca o usei para criptografar nenhum volume de disco. Até onde sei, o VeraCrypt não altera a configuração do kernel, mas mencionei isso como uma possível razão para o problema.

Qual é o problema? Como solucionar e consertar?

$ loginctl show-session 2 -p Type
Type=x11

Como você pode ver, configurei e instalei drivers Nvidia no Debian 12. Atualmente, ele está usando x11. Então, tenho duas coisas a perguntar:

1. Devo mudar para o Wayland?
2. Se sim, como fazer da GPU da Nvidia (laptop 1650 - Asus TUF A15 2020 no meu caso) a GPU primária? A mesma pergunta, se não, também!

Também sou um iniciante total no Debian 12, pois o instalei ontem

Eu também vi um método para o debian x11. Aqui está, por favor, verifique se está tudo bem para usar ou posso ficar preso com um problema. O método: https://forums.developer.nvidia.com/t/debian-12-stable-kde-not-all-options-in-nvidia-settings-in-hybrid-mode-only-in-discrete-mode-can-see-more-options/278586/2

Deixe-me dar um exemplo do pacote Debian coreutils no Ubuntu 22.04. Se inspecionarmos a lista de arquivos instalados pelo coreutils:

$ cat /var/lib/dpkg/info/coreutils.list | less

Vemos que há alguns binários que são colocados em /bine alguns em /usr/bin. No entanto, devido à /usrfusão, o /bindiretório é essencialmente um link simbólico para /usr/bin. Qual é a lógica por trás do envio de alguns binários em /bine outros em /usr/binquando os diretórios serão usr mergedde qualquer maneira na instalação?