NovHak's questions

Usuário 24.10 aqui. Contando apenas a partir da inicialização atual (menos de três horas atrás), já tenho mais de 6k mensagens inúteis como esta no diário:

audit: type=1400 audit(1736012989.876:317033): apparmor="ALLOWED" operation="file_perm" class="file" profile="transmission-gtk" name=<redacted> pid=11838 comm="transmission-gt" requested_mask="r" denied_mask="r" fsuid=1001 ouid=1001

Considerando que sou um usuário muito modesto do Transmission, imagino que ele deva ocupar muito espaço em disco dos usuários ativos do Transmission, chegando facilmente a centenas de milhares, se não milhões.

Eu configurei o transmission-gtkperfil para default_allow, o que parece se livrar do problema, mas de alguma forma o torna obrigatório também, ou seja, regras de negação explícitas serão aplicadas, então provavelmente o configurarei novamente para complain, mas com uma regra "permitir todos"... ou talvez jogarei tudo fora, o que parece uma opção muito atraente no momento.

No entanto, corrigir um perfil ruim seria melhor. Alguém sabe como posso permitir explicitamente essas file_permoperações?

Percebi com meu Groovy atual que, se eu confiar apenas no Gerenciador de atualizações gráfico, alguns pacotes não serão atualizados. Atualmente, 18 pacotes estão envolvidos: gnome-shell-common gnome-shell-extension-prefs gnome-shell libpulse-dev libpulse-mainloop-glib0 libpulse0(amd64 & i386) libpulsedsp lshw pulseaudio-module-bluetooth pulseaudio-utils pulseaudio qemu-block-extra qemu-system-common qemu-system-data qemu-system-gui qemu-system-x86 qemu-utils.

Qualquer comando aptou apt-get full-upgrade, dist-upgradeou upgradeatualizaria os pacotes, mas não o Update Manager, que continua informando que meu sistema está atualizado. Mesmo quando abro uma sessão tty (somente texto), recebo a mensagem de que não há atualizações disponíveis (o que suponho que significa que o Update Manager também entra em jogo aqui).

Isso é um bug ou comportamento pretendido? Mas então, se for intencional, qual é a lógica?

EDIT: Depois de executar um apt update, o gerenciador de atualização detectou algumas atualizações, entre as quais uma atualização de segurança que provavelmente foi adicionada nesse meio tempo, mas por algum motivo misterioso decidiu atualizar os pacotes relacionados ao Pulse Audio também.

Em seguida, executei os seguintes comandos em ordem (saída incluída):

$ apt list --upgradable

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Listing...
gnome-shell-common/groovy-updates,groovy-updates 3.38.2-1ubuntu1~20.10.1 all [upgradable from: 3.38.1-1ubuntu1.1]
gnome-shell-extension-prefs/groovy-updates 3.38.2-1ubuntu1~20.10.1 amd64 [upgradable from: 3.38.1-1ubuntu1.1]
gnome-shell/groovy-updates 3.38.2-1ubuntu1~20.10.1 amd64 [upgradable from: 3.38.1-1ubuntu1.1]
lshw/groovy-updates 02.18.85-0.3ubuntu2.20.10.1 amd64 [upgradable from: 02.18.85-0.3ubuntu2]
qemu-block-extra/groovy-updates 1:5.0-5ubuntu9.3 amd64 [upgradable from: 1:5.0-5ubuntu9.2]
qemu-system-common/groovy-updates 1:5.0-5ubuntu9.3 amd64 [upgradable from: 1:5.0-5ubuntu9.2]
qemu-system-data/groovy-updates,groovy-updates 1:5.0-5ubuntu9.3 all [upgradable from: 1:5.0-5ubuntu9.2]
qemu-system-gui/groovy-updates 1:5.0-5ubuntu9.3 amd64 [upgradable from: 1:5.0-5ubuntu9.2]
qemu-system-x86/groovy-updates 1:5.0-5ubuntu9.3 amd64 [upgradable from: 1:5.0-5ubuntu9.2]
qemu-utils/groovy-updates 1:5.0-5ubuntu9.3 amd64 [upgradable from: 1:5.0-5ubuntu9.2]

$ apt-cache policy gnome-shell
gnome-shell:
  Installed: 3.38.1-1ubuntu1.1
  Candidate: 3.38.2-1ubuntu1~20.10.1
  Version table:
     3.38.2-1ubuntu1~20.10.1 500
        500 http://fr.archive.ubuntu.com/ubuntu groovy-updates/main amd64 Packages
 *** 3.38.1-1ubuntu1.1 100
        100 /var/lib/dpkg/status
     3.38.1-1ubuntu1 500
        500 http://fr.archive.ubuntu.com/ubuntu groovy/main amd64 Packages

# apt update

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Hit:1 http://fr.archive.ubuntu.com/ubuntu groovy InRelease
Hit:2 http://security.ubuntu.com/ubuntu groovy-security InRelease
Hit:3 http://fr.archive.ubuntu.com/ubuntu groovy-updates InRelease
Hit:4 http://fr.archive.ubuntu.com/ubuntu groovy-backports InRelease
Reading package lists...
Building dependency tree...
Reading state information...
10 packages can be upgraded. Run 'apt list --upgradable' to see them.

Em seguida, executei apt list --upgradablee apt-cache policy gnome-shell, novamente, e obtive exatamente a mesma saída de antes apt update(comparei as saídas redirecionadas com cmp). update-managerainda diz que meu sistema está atualizado.

O título diz tudo. Eu não quero esse applet porque quando estou em um ambiente onde o wifi é de baixa qualidade, ele tem a tendência muito irritante de abrir janelas que interrompem outras atividades, como jogar jogos em tela cheia. Minha configuração do gerenciador de rede está OK, obrigado nm-applet, então cale a boca, por favor.

Minha solução atual é matar o nm-appletprocesso. No entanto, esta não é uma boa prática e não deve começar em primeiro lugar. Eu poderia remover o pacote também, mas também não é uma boa solução, pois ainda posso querer usá-lo às vezes, e desinstalar / reinstalar todas as vezes é realmente feio, além de mexer nos arquivos do pacote, como limpar o bit de execução ou renomeação, o que torna a instalação inconsistente com o pacote.

Eu tentei copiar /etc/xdg/autostart/nm-applet.desktoppara ~/.config/autostarte:

• Configuração NotShowIn=KDE;GNOME;GNOME-Flashback;=> sem sorte
• Configuração X-GNOME-Autostart-enabled=false=> sem sorte
• ln -s /dev/null ~/.config/autostart/nm-applet.desktop=> sem sorte

Portanto, meu palpite é que não é iniciado a partir de /etc/xdg/autostart.

Tentei gsettings set org.gnome.nm-applet show-applet false, também não tive sorte. Eu pensei que era muito auto-explicativo e funcionaria, mas não.

Para ser mais preciso, eu uso a sessão chamada GNOME Flashback (Metacity) na tela de login do GDM.

Algum conselho? É codificado ou o quê?

RESOLVIDO:

Graças à resposta abaixo, descobri que o arquivo está realmente no diretório de inicialização automática, mas não no que eu estava procurando. No entanto, em vez de modificar o arquivo em si, copiei-o ~/.config/autostarte acrescentei X-GNOME-Autostart-enabled=false. O método do respondente se aplica a todo o sistema e meu método funciona apenas para o usuário atual.

Em 19.04, nas sessões X, exibições em tela cheia, como vídeos do Youtube, não foram redirecionadas da composição de Mutter. Isso era óbvio ao usar o driver de configuração do modo Intel, a partir do rasgo.

No entanto, agora que mudei para 19.10, não noto mais rasgos nos vídeos do fs do Youtube. Em um gerenciador de janelas mais antigo, como o Metacity, no entanto, o rasgo ainda é atroz, então eu sei que a mudança não está vindo do driver.

Então, é impressão minha ou Mutter parou de redirecionar sistematicamente exibições de programas em tela cheia? E então, eles voltaram para a composição incondicional ou são usados ​​critérios especiais para evitar a composição de displays de jogos?

Este é complicado, pois não posso simplesmente identificar o pacote e registrar um bug em relação ao pacote, porque não é um problema em relação ao seu comportamento em um ambiente de desktop comum.

Na verdade, o problema é que o sistema live mantém /var/crash e /var/log montados no suporte. Não é mais somente leitura, hein?

Devido a esta :

• A imagem ao vivo é modificada (falhando outras verificações de integridade baseadas em soma de verificação que você gostaria de fazer antes de inicializar)
• Não é possível carregar na RAM e ejetar

Na verdade, é possível carregar na RAM e ejetar (o que é impossível com o Linux afinal?), mas isso requer mais etapas:

# umount /var/crash
# fuser -m -k -TERM /var/log ; umount /var/log # repeat until it works (usually once is enough)

E então ejete, da maneira usual, por exemplo, da interface do Nautilus.

Mas não deveria ser um lugar para reportar bugs aqui, daí minha pergunta: como devo reportar?

EDIT: Descobri que a persistência está habilitada por padrão. É preciso passar o nopersistentparâmetro na inicialização para evitar que o sistema ao vivo crie uma partição r/w adicional no suporte. Isso é irritante...

Como pode ser adivinhado pelo assunto, eu tenho um laptop Optimus. Enquanto eu estava executando o 19.04, consegui alternar para o Nvidia dGPU e voltar, usando o Prime (através do prime-select {intel|nvidia}comando). As coisas mudaram após a atualização para 19.10: no dia seguinte à atualização, o sistema congelou com o kernel reclamando sobre algumas tarefas travadas, como uma rmmod. Consegui recuperar meu sistema executando prime-select nvidiaem um ambiente de login root chroot.

Não vou entrar muito em detalhes secundários, como remover os drivers iGPU / dGPU do initramfs (o que eles têm que fazer no initramfs de qualquer maneira?), Mas agora ele inicializa pelo menos, com ou sem o dGPU ativado por prime .

E é aí que chego ao problema: se meu sistema inicializar com o perfil intel ativado, mudar para o perfil nvidia não funciona, pois o dGPU não é detectado no hardware. E, de fato, está ausente de uma listagem lspci. Eu tenho que reiniciar para que o dGPU seja detectado novamente. Portanto, quando eu desligar meu sistema, devo sempre pensar em ativar o perfil nvidia de antemão, ou terei que reiniciar para poder usá-lo na próxima vez.

Esse é o meu principal problema. Outra, menos irritante, é que sempre tenho que reiniciar o serviço gdm ao alternar da nvidia para a intel. Eu posso viver com isso, mas isso é um problema que eu não tinha em 19.04.

Conselhos sobre este problema são bem-vindos! Ou evite que a dGPU desapareça da lista de hardware ou um método para que ela seja detectada novamente pelo sistema, sem reinicializar.

Fwiw, minha iGPU é Intel HD Graphics 4600, e minha dGPU é uma Nvidia GTX 880M.

EDIT: @Syfer Polski, obrigado pela sua resposta informativa!

Percebi que havia um perfil sob demanda, mas descartei-o como provavelmente uma tentativa inútil, pois havia lido há pouco tempo que uma implementação Optimus realmente funcional não chegaria tão cedo... Eu deveria ter lido esse leia-me !

Então eu imediatamente tentei esse perfil sob demanda. No começo, não funcionou, pois eu tinha o driver 430 que não o suporta. Deve ter havido alguma verificação de driver se recusando a habilitar o perfil para pessoas que não estão executando uma versão de suporte, e suspeito que é por isso que meu sistema travou, porque esse perfil sob demanda foi ativado automaticamente durante a atualização (só supondo que eu não t verifique na hora).

Enfim... então eu instalei o driver 435 e de fato o perfil sob demanda funciona. No entanto, não acho satisfatório o suficiente, já que minha GPU não é desligada quando não é usada, e tentar desligar sozinho não funciona. Tentei desligá-lo por meio de uma chamada direta de ACPI e, de fato, desligou, mas:

NVRM: GPU at PCI:0000:01:00: GPU-9b8a3387-4913-0c33-619e-da118e532a5f
NVRM: Xid (PCI:0000:01:00): 79, pid=29013, GPU has fallen off the bus.
NVRM: GPU 0000:01:00.0: GPU has fallen off the bus.
NVRM: A GPU crash dump has been created. If possible, please run
NVRM: nvidia-bug-report.sh as root to collect this data before
NVRM: the NVIDIA kernel module is unloaded.

Então, infelizmente para mim, desde que os drivers proprietários não consigam desligar meu dGPU quando ele não for usado, acho que vou ficar com o sistema clássico de perfis intel/nvidia.

O que me traz de volta à minha pergunta original , quando inicializo com o modo Intel ativado: como posso recuperar meu dGPU sem reinicializar?

Um rescan( echo 1 >/sys/bus/pci/rescan) mostra isso nos logs:

pci 0000:01:00.0: [10de:1198] type 00 class 0x030000
pci 0000:01:00.0: reg 0x10: [mem 0xf6000000-0xf6ffffff]
pci 0000:01:00.0: reg 0x14: [mem 0xe0000000-0xefffffff 64bit pref]
pci 0000:01:00.0: reg 0x1c: [mem 0xf0000000-0xf1ffffff 64bit pref]
pci 0000:01:00.0: reg 0x24: [io  0xe000-0xe07f]
pci 0000:01:00.0: reg 0x30: [mem 0xf7000000-0xf707ffff pref]
pci 0000:01:00.0: 32.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s x16 link at 0000:00:01.0 (capable of 126.016 Gb/s with 8 GT/s x16 link)
pci 0000:01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none

Mas lspci permanece em silêncio. Eu posso ligar/desligar o dispositivo à vontade através de chamadas ACPI, o kernel mostra na nova varredura, mas não é detectado pelos drivers que, consequentemente, não serão carregados. Deve haver algo a fazer, mas o quê?