lmoly's questions

Eu tenho um HDD que ainda roda em um sistema Debian Stretch com kernel 4.9. O HDD também foi mkfs naquele kernel. Quando monto manualmente o HDD nele, há alguns ruídos de acesso curtos e quase inaudíveis.

Quando eu inicializo um Linux com kernel 5.15 ou 6.2 e monto o HDD lá, ele fica muito barulhento e barulhento por cerca de 8 segundos, aparentemente causado por acessos em todo o HDD, como uma espécie de verificação rápida intensiva.

Qual é a razão para isto? E se for possível: isso pode ser desabilitado ou pelo menos limitado a todas as X startups sem desvantagens?

A situação:

• O computador A executa o Windows 10 com um código de registro originado do Windows 7
• O computador B executa o Windows 10 com um código de registro originado do Windows 7

Assim, ambas as instalações receberam códigos de registro genéricos idênticos durante o processo de ativação, então não consigo mais ler os códigos de registro originais com a ajuda de ferramentas dedicadas (já estive lá, tentei isso)

Agora estou prestes a fazer uma alteração de hardware no computador B e quero fazer uma nova instalação completa usando o Windows 10 ou (de preferência) o Windows 11.

O antigo caminho de atualização agora está fechado , mas pelo que entendi, meus antigos códigos de registro do Windows 7 ainda são elegíveis para uma nova instalação do Windows 10/11, uma vez que já foram vinculados aos códigos genéricos nos servidores de ativação da Microsoft ao fazer o Windows 10 instalações - corrija-me, se eu estiver errado.

Minha pergunta agora é: o que acontece se eu ativar acidentalmente a nova instalação do Windows 10/11 no computador B com o código que ainda está em uso no computador A? Ambos podem entrar na lista negra? Ou existe a chance de trocar os dois nesse caso?

Por padrão, o nitter.net aparece em um tema escuro. Anexar ?theme=Twittera um URL faz com que todas as páginas apareçam no tema claro.

Exemplo:

• https://nitter.net/elonmusk
• https://nitter.net/elonmusk?theme=Twitter

Existe algum tipo de extensão ou regra na origem do uBlock, que poderia reescrever cada URL nitter.net para adicionar ?theme=Twitter?

DIMMs padrão antes do DDR4 não tinham verificação de erros e a prática comum para servidores HA ou estações de trabalho com maior RAM era o uso de DIMMs com ECC.

O padrão DDR4 introduziu a verificação CRC para módulos não-ECC.

Isso fechou um pouco a lacuna de segurança entre a RAM normal e a ECC ou a ECC ainda é aconselhada a partir de uma certa quantidade de RAM, mesmo em estações de trabalho?

Estou usando o Debian 10 (Buster) com uma placa gráfica NVidia GT630 em um sistema i386. apt install nvidia-driverdrivers nvidia-legacy-390xx instalados. Infelizmente o módulo do kernel não carrega (saída de /var/log/Xorg.log):

[   100.857] (II) LoadModule: "nvidia"
[   100.858] (WW) Warning, couldn't open module nvidia
[   100.858] (EE) Failed to load module "nvidia" (module does not exist, 0)
[   100.858] (EE) No drivers available.

/lib/modules/4.19.0-12-686-pae/updates/dkmscontém três arquivos nvidia-legacy-390xx*.ko.

dkms statusafirma que o módulo nvidia está instalado. modprobe nvidiaquer carregar nvidia-current, que falha (veja o log abaixo). Não tem certeza se isso não deve ler nvidia-legacy?

Qualquer ajuda seria muito apreciada.

htpc:~# systemctl status nvidia-persistenced.service
● nvidia-persistenced.service - NVIDIA Persistence Daemon
   Loaded: loaded (/lib/systemd/system/nvidia-persistenced.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2020-11-25 12:42:40 CET; 33s ago

Nov 25 12:42:40 htpc systemd[1]: Starting NVIDIA Persistence Daemon...
Nov 25 12:42:40 htpc nvidia-persistenced[7376]: nvidia-persistenced failed to initialize. Check syslog for more details.
Nov 25 12:42:40 htpc systemd[1]: nvidia-persistenced.service: Control process exited, code=exited, status=1/FAILURE
Nov 25 12:42:40 htpc systemd[1]: nvidia-persistenced.service: Failed with result 'exit-code'.
Nov 25 12:42:40 htpc systemd[1]: Failed to start NVIDIA Persistence Daemon.
htpc:~# modprobe nvidia
modprobe: FATAL: Module nvidia-current not found in directory /lib/modules/4.19.0-12-686-pae
modprobe: ERROR: ../libkmod/libkmod-module.c:979 command_do() Error running install command for nvidia
modprobe: ERROR: could not insert 'nvidia': Operation not permitted
htpc:~# dkms status
nvidia-legacy-390xx, 390.138, 4.19.0-12-686-pae, i686: installed
htpc:~# dkms install nvidia-legacy-390xx/390.138 -k $(uname -r)
Module nvidia-legacy-390xx/390.138 already installed on kernel 4.19.0-12-686-pae/i686

Saída do syslog sobre persistência da nvidia

Nov 25 12:42:40 htpc nvidia-persistenced: Started (7377)
Nov 25 12:42:40 htpc nvidia-persistenced: Failed to open libnvidia-cfg.so.1: libnvidia-cfg.so.1: cannot open shared object file: No such file or directory
Nov 25 12:42:40 htpc nvidia-persistenced: Shutdown (7377)

Um link simbólico libnvidia-cfg.so.1 apontando para libnvidia-cfg.so.390.138 existe em /usr/lib/i386-linux-gnu/nvidia/legacy-390xx. Nenhum link simbólico e arquivo em /usr/lib/i386-linux-gnu/nvidia/current.

Estou executando o Linux Mint 20 de um SSD Samsung NVMe em um sistema Intel (CPU Broadwell, placa-mãe H97). Meu plano é fazer a mudança para um sistema AMD Ryzen. Verifiquei a compatibilidade do kernel com o novo hardware Ryzen, que acabou funcionando bem, apenas os drivers da GPU Radeon precisam ser instalados adicionalmente.

Posso simplesmente remover o SSD NVMe do sistema antigo, instalá-lo no slot M.2 do novo sistema e inicializá-lo como era possível com SSDs e HDDs SATA no passado?

Atualizei uma máquina do Debian Jessie para o Stretch, que também atualizou a versão do Samba de 4.2.14 para 4.5.16. Posso montar um compartilhamento do Samba, navegar e lê-lo, mas a permissão é negada quando tento escrever algo.

Meu smb.conf ficou assim e funcionou bem no Samba 4.2.14:

[global]
   workgroup = video
   server string = %h server (Samba %v)
   dns proxy = no
   log file = /var/log/samba/log.%m
   max log size = 1000
   panic action = /usr/share/samba/panic-action %d
   obey pam restrictions = yes
   invalid users = root
   security = user  
   map to guest = Bad User
   os level = 33
   socket options = TCP_NODELAY
   unix charset = UTF-8
   strict allocate = yes
   log level = 3

[backup]
   comment = backup
   path = /mnt/backup
   writeable = yes
   public = yes
   force user = vdr
   read only = no
   guest ok = yes

Encontrei o seguinte nos logs do Samba:

[2020/07/15 09:55:06.621634,  3] ../source3/auth/auth.c:178(auth_check_ntlm_password)
  check_ntlm_password:  Checking password for unmapped user []\[vdr]@[] with the new password interface
[2020/07/15 09:55:06.621717,  3] ../source3/auth/auth.c:181(auth_check_ntlm_password)
  check_ntlm_password:  mapped user is: [VDR]\[vdr]@[]
[2020/07/15 09:55:06.621865,  3] ../source3/auth/check_samsec.c:400(check_sam_security)
  check_sam_security: Couldn't find user 'vdr' in passdb.
[2020/07/15 09:55:06.621922,  2] ../source3/auth/auth.c:315(auth_check_ntlm_password)
  check_ntlm_password:  Authentication for user [vdr] -> [vdr] FAILED with error NT_STATUS_NO_SUCH_USER
[2020/07/15 09:55:06.622054,  3] ../source3/auth/auth_util.c:1611(do_map_to_guest_server_info)
  No such user vdr [] - using guest account

O usuário vdr existe em /etc/samba/smbpasswd. Onde mais devo procurar?

Formatei um HDD com EXT4 com e2fsprogs 1.45.6-2 em um ArchLinux de 64 bits (Kernel 5.4.50) e o preenchi com dados. Depois, instalei-o em um computador diferente executando Debian Jessie de 32 bits (Kernel 3.16.84-1) com e2fsprogs 1.42.12-2+deb8u2 e copiei um único arquivo para ele.

Essa diferença de versão é problemática e pode ter causado danos ao sistema de arquivos?

Durante o desligamento do sistema Jessie de 32 bits, notei uma mensagem de erro e2fsck, que basicamente dizia que não pode ser executado devido a metadata_csum.

Então, pesquisei no Google e descobri que as somas de verificação de metadados foram introduzidas no 1.43: https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums

O que me deixa realmente desconfortável é a seguinte citação lá ... NÃO deve ser possível para o código fs antigo gravar em um sistema de arquivos com somas de verificação de metadados ativadas. O sinalizador metadata_csum é implementado como um sinalizador ROCOMPAT, que deve impedir que programas antigos (não maliciosos) estraguem as coisas.

Eu esperava não conseguir montar o sistema de arquivos se houvesse algum problema de incompatibilidade, mas realmente temo que possa ter estragado o FS.

Qualquer ajuda sobre isso seria muito apreciada.

Editar: usei o GParted para criar o FS e aprendi nesse meio tempo que, ao contrário do mke2fs, ele cria sistemas de arquivos no modo de 32 bits por padrão para unidades <16TiB, que é o caso da minha unidade de 8 TB. Eu verifiquei isso verificando os recursos dos sistemas de arquivos fornecidos por tune2fs -l /dev/sda | grep features, que de outra forma incluiriam o termo '64 bits'.

Esta questão está relacionada à explicação de como o Firefox lida com logins armazenados de preenchimento automático: https://stackoverflow.com/questions/10738090/why-firefox-autocomplete-even-with-different-input-name

Sou um usuário regular de um site que usa esses três campos em seu formulário de login.

<input class="field" type="text" name="username" autocomplete="username" id="username">
<input class="field" type="text" name="email" autocomplete="email" id="emailRegister" disabled="disabled">
<input type="password" maxlength="1024" name="password" id="password">

Infelizmente, o Firefox sempre usa o campo logo antes do campo de senha como campo de nome de usuário para preenchimento automático, então ele preenche o nome de usuário armazenado no campo de entrada de e-mail oculto.

Existe alguma maneira de contornar isso para que o nome de usuário seja preenchido corretamente no campo de nome de usuário, por exemplo, ocultando o campo de e-mail por meio de uma regra de filtro no ublock Origin?