Criando um pendrive com mais de um sistema operacional com o Ventoy

Nestes tempos em que muitas máquinas não vem mais com drive de CD/DVD, precisamos nos virar com os pendrives e bootar pela porta USB. Mas isso nem sempre é fácil.

Para uma distribuição Linux atual podemos pegar uma imagem e rodar o comando:

dd if=imagem.iso of=/dev/sdd (Usei sdd como exemplo. Mas pode ser sdb, sdc ou qualquer outro dependendo da sua máquina. Só não pode ser sda ou algum outro ocupado por um HD senão perde os seus arquivos e talvez terá que reinstalar o seu sistema operacional).

No Windows você pode apelar para o Rufus.

Já uma imagem de instalação Windows, tem a ferramenta própria da Microsoft (Media Creation Tool) ou, se estiver no Linux, procurar por algumas ferramentas, por exemplo: https://github.com/WoeUSB

Mas hoje eu esbarrei em uma nova ferramenta que permite fazer algo que facilita muito as coisas. Você, simplesmente, joga algumas isos e pode bootar elas em um menu, na inicialização. Essa ferramenta se chama Ventoy.

Para usar só é preciso fazer um download em https://www.ventoy.net/en/download.html e escolher o arquivo conforme o seu sistema operacional. Aqui vou usar o Linux, por exemplo. Neste caso o ventoy-1.0.50-linux.tar.gz que é a última versão no momento da publicação. Descompacta, entra dentro da pasta ventoy-1.0.50 e rode o comando, como root ou  usando o sudo antes: bash VentoyWeb.sh

Vai aparecer uma mensagem assim:

===============================================================
 Ventoy Server 1.0.50 is running ...
 Please open your browser and visit http://127.0.0.1:24680
===============================================================

################## Press Ctrl + C to exit #####################

Acessa o site que vai encontrar a interface web do programa:

Se estiver em inglês pode ir em Languages se quiser mudar. De preferência deixe um pendrive plugado. Neste exemplo estou usando um de 8 GB para testar. Vai em Instalar. Ele vai alertar que os dados serão perdidos já que será reformatado e clica em OK 2 vezes. (Verificação dupla para não se arrepender depois).

Após a instalação o pendrive estará pronto para uso. Entre no pendrive e copie algumas isos.

No exemplo coloquei as imagens do Clonezilla, do Debian Bullseye, que saiu ontem, o Gparted Live, o Rocky Linux e a instalação do Windows 10.

Só não coloquei o Ubuntu por falta de espaço.

Agora pegue um computador e inicializa pela usb que vai encontrar a seguinte tela:

Neste ponto é só escolher uma imagem no menu e, pronto, a iso vai iniciar sem problemas.

Quando quiser atualizar é só colocar uma nova imagem no pendrive e ele estará pronto para o uso.

As vezes pode acontecer de uma iso não funcionar e deixar a tela bagunçada. Nos testes isso aconteceu em um notebook Dell com as imagens da Debian e Rocky Linux e não aconteceu em uma máquina virtual. Neste caso existe um workaround.

Crie uma pasta ventoy dentro do pendrive e baixe o arquivo https://www.ventoy.net/download/ventoy.json nele . O conteúdo este arquivo é simplesmente:

{
    "theme": {        
        "display_mode": "CLI"
    }
}

Ele muda a interface para texto, no estilo simples do GRUB, e a inicialização das isos ocorre sem problemas.

OBS: No FAQ ele menciona o problema em imagens Windows. Mas nos testes isso ocorreu nestas duas imagens Linux e o Windows inicializou normal. Pelo menos a solução deu certo no notebook Dell.

Com isso você terá um pendrive inicializável com a opção de rodar qualquer imagem de uma maneira fácil e prática.

Como referência vou deixar este vídeo, que foi no qual descobri esta ferramenta do canal TechHut. Ele está em inglês mas mostra a ferramenta já em ação.

Tenham um bom domingo.

Lançado o Debian Bullseye

 

Depois de 2 anos, 1 mês, 9 dias de desenvolvimento e um sábado inteiro de atualizações, foi lançando, agora a pouco, a versão 11.0 da distribuição Debian, também conhecida como Bullseye, o cavalo do Woody.

Existem várias novidades que está descrito no link de lançamento, o que pode incluir o suporte ao sistema exFAT dentro do kernel oficial. A inclusão do pacote ipp-usb, para uso de impressoras, via USB sem um driver específico e muitos outros.

Para baixar os cds, dvds e outras mídias para instalação é só acessar o site https://www.debian.org.

Tenham um bom final de semana.

Como migrar de CentOS 8 para o Rocky Linux 8

Aconteceram várias coisas nesta semana. Dentre elas o anuncio de uma nova versão do Windows pela Microsoft, CPI pegando fogo no Senado (Que sexta foi essa??) e mais algumas outras. Mas nós vamos focar em um lançamento no mundo Linux: O lançamento do Rocky Linux 8.4.

Como foi explicado em https://www.adilson.net.br/2020/12/o-centos-como-conhecemos-chegara-ao-fim.html, o Rocky Linux pretende ser uma distribuição 100% compatível com o Red Hat Enterprise Linux (RHEL), o que o tornará o que o CentOS deixará de ser no final do ano. Um clone gratuito do RHEL no qual não será necessário pagar para baixar as atualizações.

"Ain, mas a Red Hat já disponibilizou o RHEL gratuito para pequena escala."

Eu sei, a pressão dos usuários leva a isso. Mas aí já é tarde demais. E se precisar de ir além de 16 máquinas, alguma alternativa? É aí que comentei no post anterior sobre o assunto. Se um projeto não está mais agradando a comunidade, vamos partir para um fork?

É neste ponto que o Gregory Kurtzer, um dos criadores originais do CentOS, resolveu agir e, com ajuda de usuários e empresas, como a Amazon Web Services, Google, e Microsoft, chegamos na disponibilização de uma versão estável do Rocky Linux.

E como o Rocky Linux é um clone do RHEL, é possível passar do CentOS 8 para o Rocky Linux 8. Uma publicação em https://ostechnix.com/how-to-migrate-to-rocky-linux-8-from-centos-8-linux/ explica como isso é feito e vou reproduzir logo abaixo.

OBS: Este blog não se responsabiliza por estragos causados por quem seguir as dicas a seguir. Se não quer ter problemas no seu sistema ou no sistema dos outros, FAÇA UM BACKUP PRIMEIRO. Seja gerando uma imagem em disco do sistema On Premise, gerando um snapshot da sua máquina virtual ou do seu provedor em nuvem, ou tendo uma máquina reserva com o sistema antigo. Depois não venha chorando dizendo que fez besteira.

E a explicação será sem o sudo, diferente da publicação original estarei usando os comandos como usuário root. Mas quem tem usuário no arquivo sudoers pode rodar com o sudo por mais segurança.

1) Atualize os pacotes para a sua última versão:

dnf --refresh upgrade

2) Se houver atualizações, principalmente de kernel, rode o comando 'reboot'

3) Veja se está rodando o CentOS 8 no seu sistema (A migração não funciona com CentOS 7)

cat /etc/redhat-release

A saída tem que ser algo parecido com isso:

CentOS Linux release 8.4.2105

Ainda pode rodar outro comando para confirmar

cat /etc/os-release

A saída tem que ser algo parecido com isso:

NAME="CentOS Linux"

 VERSION="8"

 ID="centos"

 ID_LIKE="rhel fedora"

 VERSION_ID="8"

 PLATFORM_ID="platform:el8"

 PRETTY_NAME="CentOS Linux 8"

 ANSI_COLOR="0;31"

 CPE_NAME="cpe:/o:centos:centos:8"

 HOME_URL="https://centos.org/"

 BUG_REPORT_URL="https://bugs.centos.org/"

 CENTOS_MANTISBT_PROJECT="CentOS-8"

 CENTOS_MANTISBT_PROJECT_VERSION="8"

4) Vamos baixar o script de migração. O migrate2rocky.sh

curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh

O curl tem algumas pegadinhas, verifique se baixou o script correto com um editor (vi, nano, less) ou rodando um 'head migrate2rocky.sh'.

5) Dê permissão de execução ao script.

chmod +x migrate2rocky.sh

6) Rode o script para iniciar a migração

./migrate2rocky.sh -r

A partir deste ponto terá início a atualização dos pacotes. Nos testes que fiz ele só reclamou de um problema nos locales. Isso porque o script foi desenvolvido para usar a localização en_US ao invés de setarem no C padrão. E como a máquina usada usa pt_BR isso gerou alguns erros. Se virem essas mensagens, simplesmente ignore.

Na atualização deve aparecer estas mensagens:

Preparing to migrate CentOS Linux 8 to Rocky Linux 8.

Determining repository names for CentOS Linux 8.....

Found the following repositories which map from CentOS Linux 8 to Rocky Linux 8:

CentOS Linux 8  Rocky Linux 8

appstream       appstream

baseos          baseos

extras          extras

Getting system package names for CentOS Linux 8.......

Found the following system packages which map from CentOS Linux 8 to Rocky Linux 8:

CentOS Linux 8        Rocky Linux 8

centos-backgrounds    rocky-backgrounds

centos-gpg-keys       rocky-gpg-keys

centos-logos          rocky-logos

centos-indexhtml      rocky-indexhtml

centos-linux-release  rocky-release

centos-linux-repos    rocky-repos

[...]

Aí vai baixar um monte de pacotes, mudar tudo de CentOS para Rocky Linux até chegar em:

[...] 

 Complete!

 Done, please reboot your system.

 A log of this installation can be found at /var/log/migrate2rocky.log

7) Veja se ainda em alguma atualização.

dnf distro-sync -y 

8) Estando tudo ok, rode o comando 'reboot'.

9) (Opcional) Se quiser mudar o hostname pode rodar o comando:

hostnamectl set-hostname rocky8

Desloga e reloga do sistema ou,  se algum serviço estiver incomodado com a mudança de nome, dê um novo reboot.

E assim teremos um Rocky Linux a partir de um CentOS 8.

Os testes foram feitos em uma máquina virtual no Virtualbox e deixo uma demonstração da migração no vídeo logo abaixo:

Nele mostra praticamente todos os comandos usados para a migração. O tempo pode variar de instalação em instalação do CentOS 8. Tanto que, no vídeo, cortei o processo de baixar e instalar os pacotes senão ele teria a duração de quase 3,5 Pirulas (Quem assiste o canal do Pirula entende a referência). Então ele só tem um pouquinho mais de meio Pirula.

Espero que tenham gostado. Se tiverem algo relacionado ao vídeo, comentem falem. Podem criticar a vontade já que é o primeiro vídeo com a minha voz narrando.  Também aceito sugestões e podem ter certeza que será tudo considerado (quase tudo já que os trolls e haters serão ignorados) para produção de futuros vídeos de melhor qualidade.

Para baixar o Rocky Linux: https://rockylinux.org/

Tenham uma boa semana.

Como redirecionar um site do Google App Engine para https.

 

Estava mexendo em um site que é o Palpite para Mega Sena e já tinha habilitado ele para https já tem algum tempo. Ele roda no Google App Engine com php desde 2013 como um experimento e conseguir uns números aleatórios para fazer uma fezinha.

Mas tinha uma coisa que não conseguia era redirecionar do http para https. Se eu entrava na versão http ele ficava como http e não prosseguia. Então teria que adicionar o s no http para que fosse para um lugar seguro.

Fazendo algumas pesquisas cheguei neste resultado em: https://stackoverflow.com/questions/33878825/how-to-permanently-redirect-http-and-www-urls-to-https  Em algumas plataformas uma edição no app.yaml resolve. Mas, em outras, precisa adicionar o redirecionamento na aplicação.  Como nenhuma das respostas incluía o php, então fiz mais uma pesquisa e encontrei a resposta em https://stackoverflow.com/questions/5106313/redirecting-from-http-to-https-with-php que tinha um código que é assim:

if (empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] === "off") {
    $location = 'https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];
    header('HTTP/1.1 301 Moved Permanently');
    header('Location: ' . $location);
    exit;
}

O código verifica se existe a variável HTTPS no servidor ou que está setado como "off". Se for verdade é enviado um comando de redirecionamento para a versão https do site.

A partir daí, acessando via https, o código novo não será executado e o restante do script é executado normalmente.

E como fazer isso?? Pode usar o SDK do Google Cloud ou rodar um Cloud Shell na sua conta do Google Cloud. O processo sempre é o mesmo. No início do código , depois do <?php e antes do código original, adiciona o código acima, salva ele e rode o seguinte comando:

gcloud app deploy --version 1 (ou qualquer outro número de versão)

Espera fazer o deploy e verifica se as mudanças surtiram efeito.

Funcionando, todo acesso http é redirecionado para a versão em https.

Detalhes de como funciona o script da Mega Sena: https://wiki.adilson.net.br/diversos/mega-sena.

Tenham uma boa semana.

O bloqueio do Canal de Suez não é a primeira "barbeiragem" do Ever Given.

 

Fonte: https://twitter.com/AirbusSpace/status/1375078054884749318

Nesta semana o mundo, ainda todo enrolado com essa pandemia, enfrenta agora mais um novo problema provocado por um encalhe de um super porta-contêineres que bloqueou uma das mais importantes rotas entre a Ásia e a Europa.

O nome do navio é Ever Given, da empresa Evergreen que, segundo eles, devido a ventos fortes, o navio desviou e acabou se esbarrando em um banco de areia, bloqueando totalmente a passagem do canal.

E não dá para passar.

A situação é tão complicada que a rota alternativa dos navios, tanto na ida quanto na volta, terá que ser uma que foi feita, pela primeira vez, por Vasco da Gama, em 1498, que é contornar o Cabo da Boa Esperança.

Fonte G1 e JN: Para o Brasil não faz muita diferença mas, para a Europa o caminho é mais longo.

E, por ser uma rota mais longa e cara, que fizeram o canal de Suez, ainda no século XIX. Mas este problema de ventos carregando um grande navio não é o primeiro do Ever Given. De acordo com https://www.mopo.de/hamburg/frachter-rammt-faehre-knapp-an-der-katastrophe-vorbei-32016794, em fevereiro de 2019, este mesmo navio, ao sair do porto de Hamburgo, na Alemanha, acabou batendo em um pequeno ferry boat, como mostra este vídeo abaixo:

E impacto foi em cima do barco.

Praticamente acabou com o barco.

Segundo os relatórios apresentados, a causa da colisão com o ferry boat eram ventos fortes que empurrou o Ever Given contra a pequena embarcação.

E, dois anos depois, essa nova ventania no Egito empurra o barco fazendo ele encalhar atravessado no Canal de Suez.

É muita coincidência, mais uma o capitão pode pedir música para o Fantástico. A única diferença entre os dois incidentes e no tamanho do prejuízo. Enquanto em Hamburgo a perda é apenas de um pequeno barco, no Egito o prejuízo já está em torno de alguns bilhões de dólares.

Tenham um bom final de semana.

Se o seu Linux está trocando ip toda hora, veja o NetworkManager.

Já tem alguns dias que aconteceu uma coisa curiosa em um dos computadores com Linux. De uma hora para outra o IP do computador, conectado via WiFi, alterava o seu IP e isso acontecia praticamente todos os dias. Uma situação um pouco estranha. No caso do servidor DHCP usado, o ISC DHCP, uma ou outra troca ocasional de IP é normal. Mas trocas feitas todos os dias já causa muito estranhamento. Então existe algo de errado.

Ambas as máquinas são Debian Sid e nós sabemos que problemas no Sid podem ocorrer. Então resolvi investigar isso a fundo. Dentro dos logs encontrei algo:

Mar 21 08:34:41 server dhcpd[59268]: reuse_lease: lease age 3758 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.72

Mar 21 08:34:41 server dhcpd[59268]: DHCPDISCOVER from 5c:ea:1d:17:bf:01 (notebook01) via eth0

Mar 21 08:34:41 server dhcpd[59268]: ICMP Echo reply while lease 192.168.0.72 valid.

Mar 21 08:34:41 server dhcpd[59268]: Abandoning IP address 192.168.0.72: pinged before offer

Mar 21 08:34:41 server dhcpd[59268]: Wrote 0 deleted host decls to leases file.

Mar 21 08:34:41 server dhcpd[59268]: Wrote 0 new dynamic host decls to leases file.

Mar 21 08:34:41 server dhcpd[59268]: Wrote 21 leases to leases file.

Mar 21 08:34:43 server dhcpd[59268]: DHCPDISCOVER from 5c:ea:1d:17:bf:01 via eth0

Mar 21 08:34:44 server dhcpd[59268]: DHCPOFFER on 192.168.0.182 to 5c:ea:1d:17:bf:01 (notebook01) via eth0

Mar 21 08:34:44 server dhcpd[59268]: DHCPREQUEST for 192.168.0.182 (192.168.0.1) from 5c:ea:1d:17:bf:01 (notebook01) via eth0

Mar 21 08:34:44 server dhcpd[59268]: DHCPACK on 192.168.0.182 to 5c:ea:1d:17:bf:01 (notebook01) via eth0

A mensagem acima difere um pouco de:

Mar 21 12:00:54 server dhcpd[147933]: DHCPREQUEST for 192.168.0.159 from 98:39:8e:68:ab:f4 (Mobile-Phone) via eth0

Mar 21 12:00:54 server dhcpd[147933]: DHCPACK on 192.168.0.159 to 98:39:8e:68:ab:f4 (Mobile-Phone) via eth0

Vou ter que explicar o significado das mensagens do log para descrever o que ocorre.

O esquema do DHCP é mais ou menos esse

• A máquina que precisa de IP manda, via broadcast, uma mensagem de DHCPDISCOVER, esperando que o servidor DHCP responda (Tem algum servidor DHCP?? Eu quero um IP!).
• Se for a primeira vez, o servidor envia um comando DHCPOFFER fornecendo um endereço IP (Eu tenho aqui o IP 192.168.5.23 para você.)
• A partir daí a máquina manda o comando DHCPREQUEST, solicitando este IP. (Eu quero o IP 192.168.5.23!)
• Então o servidor responde com um DHCPACK, com todas as informações, finalizando a configuração (Então pode usar este IP.)
• Só que este IP tem um tempo de uso, quando terminar este tempo, a máquina manda um novo DHCPREQUEST (Eu ainda quero usar este IP!).
• Então o servidor responde de volta com um DHCPACK, renovando o tempo de uso deste IP (Tudo bem, pode continuar usando este IP).

Só que, em vez disso, a máquina manda um novo DHCPDISCOVER (Tem algum servidor DHCP?? Eu quero um IP!).

O servidor verifica e descobre que a máquina já usou um IP antes. Faz uma verificação na rede vê que o IP ainda está ativo. Daí marca como temporariamente abandonado. (Ué? Já tem uma máquina com este IP. Não quero nenhum conflito de IP então vou fornecer um outro.). Mas só que o IP ativo era da máquina que mandou a requisição, não de alguma outra que entrou com IP fixo.

• Neste ponto o servidor manda um DHCPOFFER com um novo IP. (Olha, este IP está ocupado mas tenho o 192.168.5.84)
• Daí máquina responde com um DHCPREQUEST (Eu quero o iIP 192.168.5.84!)
• O servidor responde com um DHCPACK e o IP da máquina é alterado (Então agora você pode usar este IP).

Mas isso não poderia acontecer, já que o IP ocupado já está sendo usado pela máquina original. O normal seria mandar um DHCPREQUEST direto.

Após quebrar a cabeça encontrei uma coisa como descrito em https://wiki.archlinux.org/index.php/NetworkManager_(Portugu%C3%AAs)#Cliente_DHCP (Eu sei que é ArchLinux e a minha máquina é Debian. Mas, apesar das diferenças, a configuração do serviço em uma distribuição pode servir na outra.) Nesta página diz o seguinte:

"Por padrão, o NetworkManager usa seu cliente DHCP interno. O plugin DHCPv4 interno baseado na biblioteca n-dhcp4 do nettools"

Humm será que a configuração do DHCP via NetworkManager bugou??

Então segui esta dica:

Para usar o cliente DHCP da ISC, instale dhclient. Para alterar o backend do cliente DHCP, defina a opção main.dhcp=nome_cliente_dhcp com um arquivo de configuração em /etc/NetworkManager/conf.d/. Por exemplo:

/etc/NetworkManager/conf.d/dhcp-client.conf

[main]

dhcp=dhclient

O dhclient já se encontrava instalado, então eu adicionei esta configuração e reiniciei o NetworkManager e, até agora, não houve novas mudanças de IP.

Verificando os processos notei onde ficava as configurações de concessão nos clientes. (/var/lib/NetworkManager)

ls *.lease -lrt

-rw-r--r-- 1 root root   69 mai  3  2018 dhclient6-02505906-fe76-460f-92e6-19c45eb565e1-wlp1s0.lease

-rw-r--r-- 1 root root   69 mai 13  2018 dhclient6-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp0s20f0u3.lease

-rw-r--r-- 1 root root 1350 mai 18  2018 dhclient-0d445d73-9092-4943-a981-0d0c2af8ac75-wlp1s0.lease

-rw-r--r-- 1 root root   69 mai 25  2018 dhclient6-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp0s20f0u2.lease

-rw-r--r-- 1 root root 1022 jun  1  2018 dhclient-02505906-fe76-460f-92e6-19c45eb565e1-wlp1s0.lease

-rw-r--r-- 1 root root   69 jun  1  2018 dhclient6-ce0c666e-52d3-4d31-9b7c-0a588f831938-wlp1s0.lease

-rw-r--r-- 1 root root  570 jun  1  2018 dhclient-ce0c666e-52d3-4d31-9b7c-0a588f831938-wlp1s0.lease

-rw-r--r-- 1 root root    0 jun  1  2018 dhclient-923bb507-d222-4c11-be80-239380ece5d7-wlp1s0.lease

-rw-r--r-- 1 root root   69 jun  1  2018 dhclient6-7018e3cc-b3d2-43bf-91d6-b01272ddf91f-wlp1s0.lease

-rw-r--r-- 1 root root   69 jul  8  2018 dhclient6-d4f5d26a-a21c-4803-b240-acf2b1368b6c-wlp1s0.lease

-rw-r--r-- 1 root root  766 ago  6  2018 dhclient-328b281b-3000-4a45-9998-40261aeced67-wlp1s0.lease

-rw-r--r-- 1 root root  948 ago 27  2018 dhclient-be0f0986-3785-406e-a654-3b18f24ba242-wlp1s0.lease

-rw-r--r-- 1 root root   69 set 11  2018 dhclient6-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp0s20f0u1.lease

-rw-r--r-- 1 root root  998 set 11  2018 dhclient-2c13e46d-1878-43c5-97e0-9105467c2350-wlp1s0.lease

-rw-r--r-- 1 root root 1380 set 12  2018 dhclient-c16f749f-5c07-4f7a-b127-3c171df374a3-wlp1s0.lease

-rw-r--r-- 1 root root  536 out  2  2018 dhclient-d3a40ff6-5d10-41f5-9793-1a2a0a8ce95c-wlp1s0.lease

-rw-r--r-- 1 root root   69 out 28  2018 dhclient6-2c6d923f-f466-4c4e-b66e-ad3ec647cef9-wlp1s0.lease

-rw-r--r-- 1 root root 1001 out 28  2018 dhclient-2c6d923f-f466-4c4e-b66e-ad3ec647cef9-wlp1s0.lease

-rw-r--r-- 1 root root  383 out 30  2018 dhclient-83d56bf6-bebb-4d5e-8482-b1ff4a9d00e2-wlp1s0.lease

-rw-r--r-- 1 root root  772 out 30  2018 dhclient-dc902bc5-e968-4b29-8aba-ef16408d62a6-wlp1s0.lease

-rw-r--r-- 1 root root 1064 dez  4  2018 dhclient-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp2s0.lease

-rw-r--r-- 1 root root   68 dez  4  2018 dhclient6-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp2s0.lease

-rw-r--r-- 1 root root  772 jan 18  2019 dhclient-518b09a6-9cfc-4635-bf56-ae6f63969145-wlp1s0.lease

-rw-r--r-- 1 root root  511 abr  5  2019 dhclient-ef0ed57a-15fc-4178-947c-f55cf55d985c-wlp1s0.lease

-rw-r--r-- 1 root root  772 abr 18  2019 dhclient-77d4d0e6-6804-4120-87f7-6e93da3cec2e-wlp1s0.lease

-rw-r--r-- 1 root root 1162 mai  9  2019 dhclient-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp0s20f0u3.lease

-rw-r--r-- 1 root root  404 mai 17  2019 dhclient-8060d99a-4eb0-4faf-8490-45b76ce159ac-wlp1s0.lease

-rw-r--r-- 1 root root 1160 jul 10  2019 dhclient-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp0s20f0u2.lease

-rw-r--r-- 1 root root 4917 jul 16  2019 dhclient-30eea889-018c-4497-81e6-40954c2cf299-wlp1s0.lease

-rw-r--r-- 1 root root 1140 jul 25  2019 dhclient-d4f5d26a-a21c-4803-b240-acf2b1368b6c-wlp1s0.lease

-rw-r--r-- 1 root root  916 jul 25  2019 dhclient-0eb7c19a-c154-4967-8028-d402d219ce71-wlp1s0.lease

-rw-r--r-- 1 root root 1308 jul 29  2019 dhclient-7018e3cc-b3d2-43bf-91d6-b01272ddf91f-wlp1s0.lease

-rw-r--r-- 1 root root 1162 jul 29  2019 dhclient-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp0s20f0u1.lease

-rw-r--r-- 1 root root 2616 jul 31  2019 dhclient-a5092b04-3274-4d62-906e-49b5f53dce35-wlp1s0.lease

-rw-r--r-- 1 root root  772 jul 31  2019 dhclient-549dd9df-23db-49d8-90eb-6ba0de3b96ec-wlp1s0.lease

-rw-r--r-- 1 root root  321 ago 26  2019 internal-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp0s20f0u3.lease

-rw-r--r-- 1 root root  320 set 13  2019 internal-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp0s20f0u1.lease

-rw-r--r-- 1 root root  321 out 14  2019 internal-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp0s20f0u2.lease

-rw-r--r-- 1 root root  215 out 15  2019 internal-549dd9df-23db-49d8-90eb-6ba0de3b96ec-wlp1s0.lease

-rw-r--r-- 1 root root  215 nov  1  2019 internal-57a3995a-0ca6-4610-816e-6dd024085915-wlp1s0.lease

-rw-r--r-- 1 root root  215 nov  6  2019 internal-7c67b0fd-5e40-4ac4-ae99-2abc37d034d4-wlp1s0.lease

-rw-r--r-- 1 root root  215 nov  6  2019 internal-38e86600-9943-4568-9b74-8c0b3065a24d-wlp1s0.lease

-rw-r--r-- 1 root root  215 nov  7  2019 internal-f3617cf2-0230-43a5-9bd1-5b1c548a8e4d-wlp1s0.lease

-rw-r--r-- 1 root root  215 dez  5  2019 internal-a467e312-98de-4900-8ff2-952eb8bf1238-wlp1s0.lease

-rw-r--r-- 1 root root  215 dez  6  2019 internal-a870b552-943a-45d5-af33-180306cc9b7a-wlp1s0.lease

-rw-r--r-- 1 root root   61 dez 20  2019 internal-3cdafbc1-afa9-4418-8938-dcc8661e2bca-wlp1s0.lease

-rw-r--r-- 1 root root   60 jan  3  2020 internal-34cdab43-7d25-4082-b458-8d9a93203bc2-wlp1s0.lease

-rw-r--r-- 1 root root   58 fev  1  2020 internal-a5092b04-3274-4d62-906e-49b5f53dce35-wlp1s0.lease

-rw-r--r-- 1 root root   59 fev 28  2020 internal-30eea889-018c-4497-81e6-40954c2cf299-wlp1s0.lease

-rw-r--r-- 1 root root   58 jun 10  2020 internal-7018e3cc-b3d2-43bf-91d6-b01272ddf91f-wlp1s0.lease

-rw-r--r-- 1 root root   60 jun 15  2020 internal-3226454e-aa87-45c3-930e-6c7121910d49-bnep0.lease

-rw-r--r-- 1 root root   59 jun 23  2020 internal-b7d7cfb9-64ca-40d5-8085-37680735d0eb-wlp1s0.lease

-rw-r--r-- 1 root root   60 out 23 16:49 internal-cf2d4e9d-9cbe-46fe-a874-8ac046a7b2a4-wlp1s0.lease

-rw-r--r-- 1 root root   59 out 23 17:01 internal-5ae0cffe-f1c7-43f2-9b27-eed3a5ecdcb9-wlp1s0.lease

-rw-r--r-- 1 root root   60 nov 10 15:58 internal-0ca8ecbf-b70b-4e83-a02e-f2d3c847343b-wlp1s0.lease

-rw-r--r-- 1 root root   60 nov 10 16:04 internal-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp2s0.lease

-rw-r--r-- 1 root root   61 jan 20 17:49 internal-63f967ee-d4dc-48dc-a363-9bd48f63d53b-usb0.lease

-rw-r--r-- 1 root root   58 mar  6 14:39 internal-f48cbc0e-97ec-495e-b33d-4d279224fb5f-wlp1s0.lease

-rw-r--r-- 1 root root   60 mar 13 23:50 internal-d4f5d26a-a21c-4803-b240-acf2b1368b6c-wlp1s0.lease

-rw-r--r-- 1 root root   60 mar 20 11:06 internal-0eb7c19a-c154-4967-8028-d402d219ce71-wlp1s0.lease

-rw-r--r-- 1 root root   60 mar 21 17:18 internal-ca818677-2457-4ffd-8f58-e0dde62d99bc-wlp1s0.lease

-rw-r--r-- 1 root root  830 mar 21 17:47 dhclient-ca818677-2457-4ffd-8f58-e0dde62d99bc-wlp1s0.lease

Originalmente o NetworkManager usava o dhclient até, mais ou menos, agosto de 2019, quando uma atualização fez com que ele usasse a biblioteca interna para as requisições de DHCP. Até aí nada demais. Funcionou normal até março de 2021, quando os problemas começaram a ocorrer. Então provavelmente foi quando o bug apareceu. Agora, já ajustando a configuração para usar novamente o dhclient os problemas acabaram.

Eu ainda não vi no https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=network-manager;dist=unstable alguma mensagem relativa a isso. Mas teria que fazer alguns testes e, provavelmente, alguém que usa uma rede maior, vai perceber e abrir um ticket informando sobre a falha. Então, enquanto não corrigem, a mudança para o dhclient pode resolver esta falha.

Tenham um bom dia.