Andreas's questions

Meu objetivo final é usar uma Geforce GTX 550 Ti em um desktop Linux Gnome moderno. Como as versões recentes do Ubuntu pararam de suportar o driver Nvidia 390 que é necessário para isso, escolhi o Debian Sid (também conhecido como Unstable), que oferece instruções de instalação aparentemente diretas para ele .

Depois de tentar instalá-los, fico com uma tela de erro GUI de baixa resolução "Algo deu errado" em branco em vez da tela de login (sem botões, sem cursor), e alternar para um console não me dá um prompt de login, mas apenas uma tela preta e um cursor não responsivo no canto superior esquerdo. Então preciso reiniciar e fazer uma inicialização segura para acessar o console. Atualização: Depois de um, full-upgradeagora acabo com renderização de software, o que é tecnicamente melhor do que ter que reiniciar, mas não muito.

O que eu fiz

1. Instalei o Debian Testing amd64 weekly DVD build. Isso estava funcionando perfeitamente no desktop Gnome usando nouveaue Wayland.
2. Preenchi meu sources.listcom o conteúdo apropriado, pois estava completamente vazio, exceto por uma referência à mídia de instalação (iso USB). Antes disso, eu não conseguia nem fazer um apt update. Não sei por que fiquei com um essencialmente vazio sources.listimediatamente após uma instalação limpa.
3. Habilitado unstableadicionando uma linha em sources.list, de acordo com as instruções do Debian para habilitar unstableem Testes .
4. Segui as instruções para o driver Nvidia 390 para Sid na página wiki vinculada acima. Sim, esqueci de instalar os cabeçalhos do kernel antes de fazer isso.
5. Acabei com um sistema que não funcionava como descrito acima, então desinstalei os dois pacotes de driver novamente usando safe-boot ( nvidia-legacy-390xx-driver firmware-misc-nonfree) e removi todos os três links simbólicos da nvidia etc/modprobe.d(um dos quais estava na lista negra nouveau). Recuperei um sistema funcional.
6. Percebi meu erro e instalei os cabeçalhos do kernel ( linux-headers-amd64) de acordo com as instruções.
7. Tentei instalar o driver novamente ( nvidia-legacy-390xx-driver firmware-misc-nonfree), mas obtive o mesmo resultado de antes, após uma reinicialização.
8. Não vi muita ação de compilação acontecendo ao instalar os pacotes de driver, então tentei --reinstallo nvidia-legacy-390xx-kernel-dkmspacote, que finalmente mencionou "compilar" algo.
9. Ainda acabei na mesma situação, ou seja, sem tela de login e sem acesso ao console durante a inicialização normal.

Não tenho certeza se acidentalmente baguncei algo e não consertei corretamente, ou qual seria o problema neste momento. Qual seria o melhor curso de ação para solucionar esta situação?

Também tomei uma full-upgradeboa medida para garantir que todos os pacotes estivessem atualizados.

Observações

• Quando o sistema está funcionando (com nouveau), o Gnome desktop funciona bem no Wayland, mas exibe uma tela de erro de GUI "Algo deu errado" em tela cheia ao fazer login com o Gnome no Xorg. Ele tem um botão para "sair" no qual posso clicar com a barra de espaço (sem cursor do mouse). O MATE desktop funciona bem, e também usa o Xorg. Estou bem com o Gnome no Xorg temporariamente não funcionando — afinal, é Testing + Unstable, mas gostaria de pensar que pelo menos a tela de login ( gdm) e o console devem funcionar se os drivers gráficos funcionarem (assim como com nouveau)?
• Uma razão pela qual escolhi especificamente o Debian Testing , ou seja, o Debian 13 Trixie, em vez do Debian 12 é que eu precisava garantir que tinha o mais recente nouveaupossível . Isso porque, mesmo no Ubuntu 24.10 mais atualizado, o nouveaudriver invariavelmente congela o sistema inteiro depois de algum tempo (eu determinei isso experimentalmente; o Ubuntu está travando apenas quando nouveaué carregado e nunca quando executado apenas em gráficos integrados da Intel). Estou tentando maximizar minhas chances de que isso nouveaufuncione (o Windows 10 não congela, então atribuo isso aos nouveaudrivers, e não ao hardware).

Informações adicionais

fontes.lista

Por algum motivo, tive que reconstruir esse arquivo imediatamente após a instalação do sistema operacional, porque ele continha apenas a primeira linha (agora comentada).

# deb cdrom:[Debian GNU/Linux testing _Trixie_ - Official Snapshot amd64 DVD Binary-1 with firmware 20250310-03:29]/ trixie contrib main non-free-firmware

# unstable
deb http://deb.debian.org/debian unstable main contrib non-free non-free-firmware


deb http://deb.debian.org/debian testing main contrib non-free non-free-firmware
deb-src http://deb.debian.org/debian testing main contrib non-free non-free-firmware

deb http://deb.debian.org/debian-security/ testing-security main contrib non-free non-free-firmware
deb-src http://deb.debian.org/debian-security/ testing-security contrib non-free main non-free-firmware

deb http://deb.debian.org/debian testing-updates contrib non-free main non-free-firmware
deb-src http://deb.debian.org/debian testing-updates contrib non-free main non-free-firmware

Erros de log do Xorg

Elas podem não ser relevantes, já que não consigo nem acessar a tela de login e o console, e já que o MATE funciona no Xorg, mas as incluo para fins de completude até saber se podem ser descartadas.

$ grep EE /var/log/Xorg.0.log
[    74.735] Current Operating System: Linux debian 6.12.17-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.17-1 (2025-03-01) x86_64
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    75.166] (EE) systemd-logind: failed to take device /dev/dri/card0: Invalid argument
[    77.033] (EE) Failed to load module "nv" (module does not exist, 0)
[    77.552] (EE) [drm] Failed to open DRM device for pci:0000:01:00.0: -19
[    77.552] (EE) open /dev/dri/card0: Invalid argument
[    77.552] (EE) open /dev/dri/card0: Invalid argument
[    77.562] (EE) Unable to find a valid framebuffer device
[    77.563] (EE) Screen 0 deleted because of no matching config section.
[    77.563] (EE) Screen 0 deleted because of no matching config section.
[    77.653] (II) Initializing extension MIT-SCREEN-SAVER
[    77.667] (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found)
[    78.331] (EE) systemd-logind: failed to take device /dev/dri/card0: Invalid argument

$ grep EE /var/log/Xorg.0.log.old
[    23.670] Current Operating System: Linux debian 6.12.17-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.17-1 (2025-03-01) x86_64
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    23.970] (EE) systemd-logind: failed to take device /dev/dri/card0: Invalid argument
[    25.852] (EE) Failed to load module "nv" (module does not exist, 0)
[    26.471] (EE) [drm] Failed to open DRM device for pci:0000:01:00.0: -19
[    26.471] (EE) open /dev/dri/card0: Invalid argument
[    26.472] (EE) open /dev/dri/card0: Invalid argument
[    26.490] (EE) Unable to find a valid framebuffer device
[    26.491] (EE) Screen 0 deleted because of no matching config section.
[    26.491] (EE) Screen 0 deleted because of no matching config section.
[    26.522] (II) Initializing extension MIT-SCREEN-SAVER
[    26.535] (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found)
[    27.025] (EE) systemd-logind: failed to take device /dev/dri/card0: Invalid argument

Fique à vontade para perguntar qualquer outra coisa que pareça relevante e eu adicionarei.

Ao inicializar uma nova instalação do Debian 12 Bookworm, recebo uma mensagem dizendo que preciso ir para https://wireless.wiki.kernel.org/en/users/Drivers/b43#devicefirmware e download the correct firmware for this driver versione para carefully read all instructions. Muito bem, aqui está a introdução dessa página:

b43 e b43legacy são drivers sem fio para chipsets Broadcom SoftMAC. O Kernel escolherá automaticamente um módulo adequado para você:

• b43 para qualquer hardware novo (suportado)
• b43legacy para BCM4301 e versões anteriores do BCM4306

Resumo

Você precisa ter arquivos de firmware (geralmente em /lib/firmware/) para que b43(legado) possa carregá-los no cartão e funcionar corretamente. Para suporte a dispositivos FullMAC, consulte brcmfmac e rndis_wlan

É bom saber, eu acho. As outras seções dessa página são: Problemas conhecidos e limitações , Problemas resolvidos , Lista de hardware , Contato . Que instruções devo seguir aqui? Eu não vejo nenhum.

No topo da página há um link para o "conteúdo antigo" da página , então dou uma olhada na seção Instalação de firmware do dispositivo nesse conteúdo antigo:

Ubuntu/Debian

Nas versões recentes do Ubuntu e Debian, a instalação do pacote firmware-b43-installer cuidará de tudo para você:

1 sudo apt-get install firmware-b43-installer

Você será solicitado a buscar e instalar automaticamente o firmware no local correto. Novamente, você precisará de uma conexão com a Internet .

Minha reação aqui foi mais ou menos “haha, muito engraçado”. Então fui procurar algumas instruções mais promissoras. Encontrei https://wiki.debian.org/wl#Installation que lista meu chip no título (BCM43228). Finalmente, isso parece promissor!

Instalação

Adicione um componente "não-livre" ao /etc/apt/sources.list para sua versão Debian, por exemplo:

Debian 9 "Esticar"

deb http://deb.debian.org/debian stretch-backports main contrib non-free

Debian 10 "Buster"

deb http://deb.debian.org/debian buster-backports main contrib non-free

Debian 11 "Alvo"

deb http://deb.debian.org/debian bullseye contrib non-free

...realmente? A solução novamente parece ser ter acesso à Internet. Além disso, o Debian 12 não é mencionado. Independentemente disso, as instruções continuam com a seção crítica:

Atualize a lista de pacotes disponíveis. Instale os pacotes linux-image, linux-headers e broadcom-sta-dkms relevantes/mais recentes:

# apt-get update
# apt-get install linux-image-$(uname -r|sed 's,[^-]*-[^-]*-,,') linux-headers-$(uname -r|sed 's,[^-]*-[^-]*-,,') broadcom-sta-dkms

Isso também instalará o pacote de ferramentas sem fio recomendado. O DKMS construirá o módulo wl para o seu sistema.

Eu li em mais de um lugar que o Debian 12 inclui firmware na mídia de instalação (usei a imagem do DVD i386) - inclusive em seu próprio feed de notícias, sobre a votação sobre isso - mas certamente não acabei trabalhando com WiFi após a instalação, nem fui solicitado a instalar nada durante o processo de instalação do sistema operacional (ou perdi?), então não sei exatamente o que fazer com isso.

Agora, supondo que eu tenha entendido algo errado, o que eu deveria ter feito de diferente nesse processo?

A única coisa que vem à mente como solução neste momento é fazer manualmente a resolução de dependências de broadcom-sta-dkmse dos outros pacotes, baixar todos esses pacotes do debian.org, colocá-los em um pendrive e instalá-los manualmente. Certamente não é assim que foi projetado para ser feito?

Copiei alguns arquivos para HFS+, usando macOS, garantindo que foi copiado exatamente. No macOS, esses arquivos copiados têm 501 como proprietário, de acordo com ls -han.

Em seguida, conecto o pendrive HFS + no Ubuntu, e lá os arquivos têm 1000 como proprietário, de acordo com ls -han. Por que?

Tentei então copiar um dos 501 arquivos de propriedade no Ubuntu (para o mesmo volume HFS+), garantindo que ele fosse copiado exatamente usando cp -a.

Agora o macOS lsvê o novo arquivo como propriedade do usuário 1000...

Realmente? Não entendo - qual foi o sentido de usar cpa -aopção se ela nem preserva o ID do usuário do proprietário? O que eu perdi?

Atualização: para esclarecer, acho que minha confusão aqui decorre disso - na minha opinião - o HFS suporta permissões de arquivo Unix nativamente e deveria "simplesmente funcionar" com elas.

Aprendi recentemente que cps preserve=timestampsnão preserva, de fato, carimbos de data/hora (as datas de criação são redefinidas). Devo agora acreditar que isso preserve=ownershipnão preserva a propriedade?

Copiei alguns diretórios para -aos quais preserve=allentendi que incluiriam os tempos de criação:

cp -a ./* /mnt/destination/

Ao inspecionar os diretórios resultantes no destino, todos eles têm o horário de criação definido para o horário atual,enquanto seu conteúdo parece ter preservado seus tempos de criação.

Por que as datas de criação donível superiordiretórios preservados?

A origem é HFS+ e o destino é btrfs.

Trechos de listagens de diretório de destino e origem:

$ ls -hal --time=creation
total 16K
drwxrwxr-x 1 andreas andreas   74 sep  2 23:25  .
drwx------ 1 andreas andreas  310 apr 26 17:08  ..
drwx------ 1 andreas andreas 2,3K sep  2 23:45  Library

$ ls -hal --time=creation /mnt/source
total 8,1M
drwxrwxr-x  1 andreas andreas   15 mar 28  2022  .
drwxr-x---+ 3 root    root    4,0K aug  9  2022  ..
drwx------  1 andreas andreas   95 apr 15  2019  Library

Atualizar

A julgar pelas respostas e comentários, concluí que devo ter cometido um erro ao inspecionar as datas dos subdiretórios. Eu fiz. A culpa é minha - minhas expectativas em relação ao resultado me cegaram para o que eu estava vendo. Essa parte da questão foi abandonada.

Parece que eu sempre tenho que instalar arquivos em um --boot-directoryarquivo grub-install.

E se eu já tiver arquivos grub existentes /bootem minhas partições? Eu não deveria apenas instalar as partes MBR do grub e apontá-las para uma das minhas partições existentes /boot/grub? Não consegui encontrar tal opção.

Fiz o downgrade do meu GPT para MBR e removi minha partição de inicialização do BIOS, o que significa que preciso reinstalar o Grub no meu MBR, se não entendi nada mal. Sem fazer isso, fico com um prompt de resgate do grub que nem pode listar minhas partições ao fazer ls. Percebo que minhas entradas de menu ainda podem não funcionar após a reinstalação do grub no MBR, pois se referem a partições como hd0,gpt5, mas ter um prompt utilizável seria bom o suficiente e me permitiria confirmar minha compreensão do grub mais facilmente.

Tenho que escrever em um --boot-directorysempre que quiser instalar o grub, mesmo que já exista um diretório?

Eu estava olhando para o Python2.7 para o debian jessie , pois meu objetivo era fazer o downgrade do Python 2.7.13 para 2.7.10 ou inferior (executando no OSMC que agora está em stretch). Pelo nome, parecia que esse pacote era a versão 2.7.9.

Eu adicionei deb http://ftp.de.debian.org/debian jessie mainao meu de /etc/apt/sources.list acordo com as instruções aqui , e como eu tinha apenas uma linha marcada jessie, continuei com:

apt-get install -t jessie python2.7

Depois que foi feito python --versionme deu 2.7.15+. Isso não é realmente o que eu estava procurando.

Eu estou querendo saber onde eu fiz uma suposição errada?

Estou no processo de mapeamento de botões remotos IR no LIRC. Eu olhei através de input-event-codes.he me deparei com KEY_NEXTe KEY_NEXTSONG, então fiz algumas pesquisas, mas não consegui encontrar descrições para eles.

Eu estou querendo saber qual é a diferença, se houver, e quando devo usar um ou outro? Ou sua semântica está aberta para interpretação?

Estou executando o daemon de transmissão como um serviço systemd no OSMC. Ao abrir sua interface web de controle remoto após uma reinicialização, todas as transferências são quase sempre interrompidas com a mensagem "Erro: Nenhum dado encontrado! Certifique-se de que suas unidades estejam conectadas [...]".

Estou assumindo que isso ocorre porque a transmissão começa antes que o caminho de download exista - neste caso, em uma unidade USB que é montada automaticamente pelo sistema /media/Elements/[...]sem nenhuma configuração manual feita por mim. Eu não editei fstab.

Depois de tentar esta resposta sem sucesso, gostaria de saber se existe alguma outra maneira de resolver isso? O que fiz de acordo com essa resposta foi adicionar o seguinte em um override.conf:

cat /etc/systemd/system/transmission.service.d/override.conf

[Unit]
After=media-Elements.mount
After=media-Vault\x2013.mount
After=media-Black\x20Mesa.mount

O arquivo de serviço:

$ cat /lib/systemd/system/transmission.service

[Unit]
Description=Transmission BitTorrent Daemon
After=udisks-glue.service

[Service]
User=osmc
Group=osmc
Type=notify
ExecStartPre=/bin/sleep 10
ExecStart=/usr/bin/transmission-daemon -f --log-error --allowed *.*.*.*

[Install]
WantedBy=multi-user.target

Status do sistema:

$ systemctl status transmission

● transmission.service - Transmission BitTorrent Daemon
   Loaded: loaded (/lib/systemd/system/transmission.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/transmission.service.d
           └─override.conf
[...]

Vale a pena mencionar que recebo Warning: transmission.service changed on disk. Run 'systemctl daemon-reload' to reload units.ao verificar o status transmissionapós cada reinicialização. daemon-reloadsilencia até a próxima reinicialização.

Esta questão está relacionada, mas tem a ver com montagens fstab. Eu preferiria resolvê-lo sem fstab, se possível, pois não quero tratar a unidade USB como permanentemente conectada.

Depois de tentar a resposta inicial:

$ systemctl cat --no-pager transmission.service
# Warning: transmission.service changed on disk, the version systemd has loaded is outdated.
# This output shows the current version of the unit's original fragment and drop-in files.
# If fragments or drop-ins were added or removed, they are not properly reflected in this output.
# Run 'systemctl daemon-reload' to reload units.
# /lib/systemd/system/transmission.service
[Unit]
Description=Transmission BitTorrent Daemon
After=udisks-glue.service

[Service]
User=osmc
Group=osmc
Type=notify
ExecStartPre=/bin/sleep 10
ExecStart=/usr/bin/transmission-daemon -f --log-error --allowed *.*.*.*

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/transmission.service.d/override.conf

[Unit]
RequiresMountsFor=/media/Elements

[Install]
WantedBy=media-Elements.mount