sexta-feira, 4 de setembro de 2020

Solução para o VMware com o Kernel 5.8 1 mês depois.

Depois de 1 mês após o lançamento do kernel 5.8 (veja em https://www.adilson.net.br/2020/08/lancado-o-linux-58-mas-nao-atualize-se.html). Finalmente, na manhã desta sexta-feira, surgiu um patch que corrige esta falha em https://github.com/mkubecek/vmware-host-modules/pull/72 . O autor do patch o fez baseado nas correções que foram aplicadas nas versões em desenvolvimento do VirtualBox.

Eu fiz uns testes aqui e tudo funcionou perfeitamente. Não aconteceu nenhum problema do host ter rebootado ou qualquer outro problema relacionado aos módulos. 

Fora isso, o único problema é em um segfault no vmware-modconfig. Mas aí é um problema mais interno entre o vmware e o /proc do sistema operacional. Isso é mais facilmente corrigido. Enquanto não surge uma nova atualização, isso pode ser corrigido com estes dois passos.

  •  Edita o /usr/bin/vmware e, no final do arquivo, deixe comentado estas linhas:

#if "$BINDIR"/vmware-modconfig --appname="VMware Workstation" --icon="vmware-workstation" &&
#   vmware_module_exists $vmmon; then
  exec "$libdir"/bin/"vmware" "$@"
#fi

Só não comenta a linha do exec, que é o que roda o vmware. Já a parte dos módulos, pode usar o script usado em https://www.adilson.net.br/2017/08/resolvendo-o-problema-compilacao-de.html para compilar os módulos de forma manual toda vez em que for compilar ou instalar um kernel novo a partir da versão 5.8.

De qualquer forma, isso resolve o problema do VMware com o kernel 5.8. Já com o VirtualBox, ainda precisamos esperar a liberação da próxima versão estável. Mas, se estiver com pressa, pode tentar a versão em desenvolvimento. Pena que não tem para Debian/Ubuntu, senão isso seria de grande ajuda. [Atualização para sextar de vez no final de tarde] Já foi liberado a versão mais nova do VirtualBox que também dá suporte ao kernel 5.8. Agora sim isso resolve o problema de virtualização no kernel mais recente.

Apesar de ter agradecido lá no tópico do Github, tenho que agradecer o autor do patch, mais uma vez, pela solução:


Quando tiver mais novidades, com o VirtualBox, eu informo aqui.

Tenham um ótimo final de semana e um bom feriado na segunda.


segunda-feira, 3 de agosto de 2020

Lançado o Linux 5.8 - Mas não atualize se for rodar máquina virtual.

A algumas horas atrás foi lançado o kernel 5.8 conforme monitorado neste Tweet.


Uma lista completa das novidades pode ser conferida em https://kernelnewbies.org/Linux_5.8

Porém, esta atualização vem com alguns efeitos colaterais. Primeiro com os drivers da NVIDIA. Mas isso é facilmente resolvido instalando o último driver disponível que é o 450.57. Veja se a sua distribuição já atualizou ou procure em https://www.nvidia.com.

Agora a dor de cabeça fica por conta da área de virtualização.


Acessando o blog http://rglinuxtech.com/, foi encontrado um relato que diz que o drive do VMware apresenta alguns problemas e, mesmo com alguns patches, qualquer tentativa de iniciar uma máquina virtual pode reiniciar a máquina host sem aviso, conforme o log indicado no mesmo blog mencionado.


$ uname -a
Linux rgz220 5.8.0 #2 SMP Sun Aug 2 16:34:15 PDT 2020 x86_64 x86_64 x86_64 GNU/Linux

[root@rgz220 rgadsdon]# vmware-modconfig –console –install-all
[AppLoader] GLib does not have GSettings support.
Segmentation fault (core dumped)

[root@rgz220 vmware-host-modules-workstation-15.5.6]# make
make -C vmmon-only
make[1]: Entering directory ‘/home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only’
Using kernel build system.
make -C /lib/modules/5.8.0/build/include/.. M=$PWD SRCROOT=$PWD/. \
MODULEBUILDDIR= modules
make[2]: Entering directory ‘/usr/src/linux-5.8’
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/linux/driver.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/linux/hostif.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/linux/driverLog.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/common/memtrack.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/common/apic.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/common/statVarsVmmon.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/common/vmx86.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/common/sharedAreaVmmon.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/common/cpuid.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/common/task.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/common/comport.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/common/phystrack.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/vmcore/moduleloop.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/bootstrap/monLoaderVmmon.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/bootstrap/monLoader.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/bootstrap/vmmblob.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/bootstrap/bootstrap.o
LD [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/vmmon.o
MODPOST /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/Module.symvers
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/vmmon.mod.o
LD [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/vmmon.ko
make[2]: Leaving directory ‘/usr/src/linux-5.8’
make -C $PWD SRCROOT=$PWD/. \
MODULEBUILDDIR= postbuild
make[2]: Entering directory ‘/home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only’
make[2]: ‘postbuild’ is up to date.
make[2]: Leaving directory ‘/home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only’
cp -f vmmon.ko ./../vmmon.o
make[1]: Leaving directory ‘/home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only’
make -C vmnet-only
make[1]: Entering directory ‘/home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only’
Using kernel build system.
make -C /lib/modules/5.8.0/build/include/.. M=$PWD SRCROOT=$PWD/. \
MODULEBUILDDIR= modules
make[2]: Entering directory ‘/usr/src/linux-5.8’
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/driver.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/hub.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/userif.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/netif.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/bridge.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/procfs.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/smac_compat.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/smac.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/vnetEvent.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/vnetUserListener.o
LD [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/vmnet.o
MODPOST /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/Module.symvers
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/vmnet.mod.o
LD [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/vmnet.ko
make[2]: Leaving directory ‘/usr/src/linux-5.8’
make -C $PWD SRCROOT=$PWD/. \
MODULEBUILDDIR= postbuild
make[2]: Entering directory ‘/home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only’
make[2]: ‘postbuild’ is up to date.
make[2]: Leaving directory ‘/home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only’
cp -f vmnet.ko ./../vmnet.o
make[1]: Leaving directory ‘/home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only’
[root@rgz220 vmware-host-modules-workstation-15.5.6]# make install
install -D -t /lib/modules/5.8.0/misc vmmon-only/vmmon.ko vmnet-only/vmnet.ko
strip –strip-debug /lib/modules/5.8.0/misc/vmmon.ko /lib/modules/5.8.0/misc/vmnet.ko
if test -z “”; then /sbin/depmod -a 5.8.0; fi
[root@rgz220 vmware-host-modules-workstation-15.5.6]# service vmware start
Starting vmware (via systemctl): [ OK ]

[rgadsdon@rgz220 ~]$ vmware
/usr/bin/vmware: line 105: 12956 Segmentation fault (core dumped) “$BINDIR”/vmware-modconfig –appname=”VMware Workstation” –icon=”vmware-workstation”

[rgadsdon@rgz220 ~]$ /usr/lib/vmware/bin/vmware

VMware Workstation Warning:
An old version of smart card service (pcscd) is running on this system. Upgrade to the latest version to use virtual smart cards.

PowerOn
VProbes facility is disabled.
VProbes facility is disabled.
SOUNDLIB: Connection failure: Connection refused
SOUNDLIB: SoundLib_CreatePulseBackend: failed to connect to PA context (Connection refused)
FILE: FileLockMemberValues file ‘/home/rgadsdon/vmware/Windows_XP_Pro-SP3-2/Windows_XP_Pro-000001-cl3.vmdk.lck/M37025.lck’: size 0, required size 512
FILE: FileLockMemberValues removing problematic lock file ‘/home/rgadsdon/vmware/Windows_XP_Pro-SP3-2/Windows_XP_Pro-000001-cl3.vmdk.lck/M37025.lck’
Could not initialize emulated USB smart card subsystem.
VIDE: Using LBA48 for ide0:0
<< Immediate system reboot – connection lost >>
client_loop: send disconnect: Broken pipe


Ainda não existe uma solução, conforme indicado em https://communities.vmware.com/thread/638457, ainda vou monitorar para ver se tem alguma novidade.

Ah, mas vou usar o VirtualBox enquanto isso.


Seria bom se isso fosse simples. Mas, parece que o bug também afeta o VirtualBox: https://www.virtualbox.org/ticket/19644


E agora??? Como rodar as máquinas virtuais??

Por hora, a solução é permanecer na versão 5.7 até que uma correção saia. Qualquer novidade publicarei aqui.

Tenham uma boa semana.


quarta-feira, 17 de junho de 2020

Como fazer o Google Chrome voltar a exibir a URL completa

Já tem algum tempo que o Google Chrome esconde detalhes dos endereços dos sites como os famosos http:// e https:// e também escondem a parte www e m dos endereços. Para alguns isso não é muito problema. Mas, para alguns outros (E isso também me inclui),  acham muito chato esta parte já que não mostra muita coisa e pode ser também uma porta para phishing. Mas parece que apareceu uma forma de retornar a antiga forma sem precisar de pular para o Firefox.

Pegamos um exemplo a própria página do blog no Google Chrome 83. E isso vale em qualquer sistema operacional.

Sem https:// e sem www :/
Em uma aba acesse o endereço about:flags

Note que o endereço é chrome://flags mas ambos os endereços são válidos

Note que você precisa apenas escrever context menu e procura por "Context menu show full URLs". Ao encontrar esta opção, mude a opção para "Enabled" e, em seguida, vai em "Relaunch".

Após reiniciar, feche a aba já que tem várias opções que podem bagunçar o navegador. Volte a URL e clica com o botão direito na barra de endereços.

Agora aparece a opção.

Clica em "Sempre mostrar URLs completos" e aí o endereço completo surge na barra de endereços.
Agora sim o endereço aparece completo

Como a opção do chrome://flags é totalmente experimental, ela pode sumir nas futuras versões ou possa permanecer e até ficar dentro das configurações do Google Chrome. Tomara que fique na segunda opção para não deixar chateados quem prefere ver o endereço completo no navegador.


E espero voltar mais vezes, em breve mais postagens. E tomara que não seja em 2021 ou além.

Tenham uma boa semana.

sábado, 6 de julho de 2019

Lançado o Debian Buster




Depois de mais de 25 meses de desenvolvimento e, praticamente, um dia de atualizações. Foi lançado, agora a pouco, a versão 10.0 da distribuição Debian, também conhecida como Buster. Acho que este é o segundo nome que não é de um brinquedo da franquia Toy Story. O outro nome é da versão instável que é conhecida como Sid.

Existem várias novidades que estão descritas no link do lançamento, como o suporte a inicialização segura quando o boot é feito pela UEFI. O Wayland sendo usado por padrão no GNOME e muitas outras novidades e atualizações.

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

Tenham um bom final de semana.

quarta-feira, 26 de junho de 2019

Resolvendo os problemas do tamanho do ibdata1 no MySQL - versão 2019

Esta é uma atualização da publicação https://www.adilson.net.br/2009/12/resolvendo-os-problemas-do-tamanho.html , que tem quase 10 anos. Só que vou adicionar alguns detalhes novos que mudaram de 2009 para hoje, em 2019.

Um problema que enfrentava sempre que colocava um aplicativo utilizando o MySQL é o tamanho sempre crescente do arquivo /var/lib/mysql/ibdata1. Este arquivo armazena as tableas do tipo InnoDB e, mesmo que os dados sejam removidos ou elimine tabelas e, até mesmo, banco de dados, o tamanho do ibdata1 não diminui, o que pode ocasionar problemas de espaço em disco mais para frente.


Fazendo uma pesquisa na rede descobri uma boa solução para esta complicação que é definida como padrão em várias instalações do MySQL e, também, no MariaDB.

Como o MariaDB é um fork do MySQL, vou tratar tudo como MySQL. Então o que for para o MySQL pode valer também para o MariaDB.

A primeira coisa a fazer é criar um backup de todos os bancos de dados do MySQL que utiliza as tabelas InnoDB. Vamos imaginar que temos apenas um banco de dados deste tipo no servidor MySQL. Então será feito o seguinte:


mysqldump -u"usuario" --password="senha" --routines bancodedados > bancodedados.sql


Remove o banco de dados propriamente dito no console do MySQL:


DROP DATABASE bancodedados;


Desative o serviço do MySQL:


service mysql stop ou systemctl stop mysql


remove o arquivo ibdata1


rm -rf /var/lib/mysql/ibdata1


Dependendo da versão deve-se, também remover mais dois arquivos senão o MySQL não inicializa.

rm -rf /var/lib/mysql/ib_logfile0  /var/lib/mysql/ib_logfile1

Edita o /etc/mysql/my.cf e adiciona a seguinte linha aonde está o InnoDB:


innodb_file_per_table ou innodb_file_per_table=ON ou innodb_file_per_table=1


Esta linha faz com que as informações das tabelas fiquem em arquivos em separado.


service mysql start ou systemctl start mysql


Recria o banco de dados no console do MySQL


CREATE DATABASE bancodedados;


Restaura o backup dos banco de dados removido:


mysql -u root -p bancodedados < bancodedados.sql


Depois desta configuração, os dados não ficam mais no ibdata1, e sim nos arquivos *.ibd dentro da pasta do banco de dados relacionado. Em algumas tabelas, este arquivo também cresce e, as vezes, não diminui o tamanho mesmo eliminando dados. Mas, para este problema, existe uma maneira de obter mais espaço no servidor após remover os dados.


Dentro do banco de dados, no console do MySQL, rode o comando


OPTIMIZE TABLE tabela;


Este comando faz com que todo espaço vazio dos dados removidos seja liberado no servidor.

Tenham uma boa semana.

sábado, 8 de junho de 2019

Descanse em paz André Matos 😢

A muitos anos atrás eu participava de um outro blog coletivo e fiz uma resenha de um show do Shaman. Eu ainda não encontrei para fazer um "Recordar é viver" do fundo do baú e alguns dos arquivos antigos estão guardados em algum canto do material que veio comigo do RJ até BH.


Hoje não tem Copy & Paste mas a notícia é triste. Os dois antigos blogs tinham links justamente para as páginas do Angra e do Shaman, duas bandas que foram fundados pelo André Matos. E, de alguma forma, influenciou o antigo blog e quem escrevia, incluindo eu e mais alguns amigos.

Então, como homenagem, vou deixar um link do Youtube, que encontrei da música Fairy Tale, da banda Shaman. Da mesma época em que criei a resenha quando fui a um show deles na Barra.



Esta pessoa aqui que já participou do www.juvifa.webblogger.com.br, que virou www.juvidadi.blogger.com.br (os dois já não existem mais) e, atuamente, em carreira solo no site www.adilson.net.br só tem que dizer obrigado por ser parte das nossas vidas e obrigado por ser uma referência ao Rock nacional e internacional. Descanse em paz.


sábado, 13 de abril de 2019

A imagem do buraco negro e o avanço da ciência



Esta semana o mundo ficou maravilhado com a divulgação da primeira foto de um buraco negro. Na verdade nem é do próprio buraco negro. E sim do que está ao redor dele. Uma espécie de sombra já que nada consegue escapar dele. O que vemos, na foto, é o disco de acreção que fica ao redor dele. Então, o que está no meio é, com a mais absoluta certeza, um buraco negro.



Esse foi um trabalho de três anos processando 5 petabytes de dados coletados por diversos radiotelescópios espalhados pelos mais diversos cantos do mundo. A quantidade de dados é tão enorme que os dados foram 'transmitidos' por voos de avião. Ou seja, um carregamento enorme de HDs para serem processados.

Katie Bouman, a principal responsável pelo algorítimo para chegar na imagem com uma pequena parte dos dados.  
E este vídeo mostra como foi feita esta coleta e o porque da escolha do M87, apensar de ser em inglês.




Talvez teremos uma foto do Sagitarius A* mas vai demorar um pouco. Apesar de perto ele é menor e bem mais calmo que o buraco negro do M87. Tanto que preparei um vídeo mostrando a tremenda distância que este buraco negro está e a comparação com o sistema solar e o Sagitarius A*.



E, sim, este buraco negro é enorme mesmo. Mas, como foi mostrado no primeiro vídeo, ele é um pontinho que está muito, muito longe. Por isso que saiu um pouco borrado. Mas a importância desta imagem é mostrar que Einstein está certo e todos aqueles que previram os buracos negros conseguiram acertar. Então um marco como este tem que ser comemorado. No futuro, com o avanço da ciência, teremos imagens melhores. Mas isso é apenas um começo.

Mais detalhes: https://eventhorizontelescope.org/
https://www.youtube.com/channel/UC_Fk7hHbl7vv_7K8tYqJd5A - Canal do Space Today. Não vou citar um porque tem vários vídeos falando sobre o assunto. Então é melhor assistir todos.

E tenham um bom final de semana.

domingo, 10 de março de 2019

A senha ji32k7au4a83 parece segura mas não é e é muito comum.



Eu esbarrei numa notícia bem curiosa sobre senhas em https://www.tecmundo.com.br/seguranca/139309-senha-ji32k7au4a83-parece-segura-entenda-password-comum.htm que tem a sua fonte em https://gizmodo.com/why-ji32k7au4a83-is-a-remarkably-common-password-1833045282 que explica sobre uma senha que, apesar de ter letras e números é tão insegura como qualquer outra.

Mas aí você imagina: "Mas ela já foi publicada então já deixou de ser segura já que todo mundo sabe sobre ela." É verdade. Se é pública então deixa de ser seguro. Mas o motivo de ser inseguro é algo totalmente diferente.

Vou evitar um pouco o Copy & Paste e contar toda a história. Tudo começou em um simples tweet do Robert Ou, que ficou intrigado sobre o motivo dessa senha ser tão comum e insegura, estando várias vezes no site Have I been Pwned:


Não demorou muito e a resposta apareceu e o problema é de um teclado lá de Taiwan.

Teclado Zhuyin. Fonte: Apple


Existe uma codificação usada para gerar os caracteres em chinês e a tal senha pode ser traduzida como:

ji3 -> 我
2K7 -> 的
au4 -> 密
a83 -> 碼

Que forma 我的密碼 que pode ser pronunciado como "Wǒ de mìmǎ" e isso pode ser traduzido como "Minha senha".

Isso daí quer dizer minha senha????

Isso mesmo. Tão insegura quanto a palavra password ou senha. E ninguém, fora de Taiwan, poderia imaginar que uma senha dessas pode ser tão insegura assim.

Por isso sempre tem que ter cuidado na hora de criar as senhas. Essa daí já está queimada por conta deste detalhe também já está incluída em muitos dicionários para ataque de força bruta.

Tenham uma ótima semana.



segunda-feira, 4 de março de 2019

Lançado o Linux 5.0



A algumas horas atrás foi liberada a mais nova versão do kernel do Linux, a 5.0.


Era para ser a 4.21, mas o Linus resolveu mudar a numeração logo para 5.0 do mesmo jeito que foi da 3.0 para 4. Então a diferença não é tão grande assim. Mesmo assim tem várias novidades como.

  • Suporte ao AMD Radeon FreeSync;
  • Trabalho contínuo no desenvolvimento do Intel Icelake e outros novos recursos de CPU;
  • Recursos de rolagem de alta resolução da Logitech;
  • Melhorias de rede e muito mais.

Uma lista completa pode ser conferida em: https://kernelnewbies.org/Linux_5.0

Pode haver alguma complicação para placas NVIDA mas isso se resolve na última versão do driver. Ou, se ainda não estiver disponível na sua distribuição, pode dar uma olhada em http://rglinuxtech.com/. O mesmo vale para os drivers do Vmware.

Quem quiser baixar direto é só ir em: https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.0.tar.xz.

Mais informações:


Tenham um bom Carnaval.

domingo, 24 de fevereiro de 2019

Usando rebase para unificar as alterações no git.

Voltamos ao assunto do git

Essa é uma continuação do https://www.adilson.net.br/2018/02/removendo-commits-indesejaveis-do.html onde, por algum motivo, não conseguimos remover aquela entrada indesejável, após a correção do código das dicas anteriores. Mas, antes, volto a repetir o disclaimer 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 repositório ou no repositório dos outros, FAÇA UM BACKUP PRIMEIRO. Seja dando um clone em outro lugar, copiando a pasta .git para um outro lugar ou dando um tar/zip no seu repositório. Depois não venha chorando dizendo que fez besteira.


Agora vamos voltar para a seguinte situação. Os estagiários fizeram tanta alterações no meio, por exemplo:

Number Hash     Commit Message               Author

1      2c6a45b  (HEAD) Adicionando novidades Desenv.
2      93bf23d  bla bla bla bla bla          Estagiário 1
2      ae45fab  Melhorando banco de dados    Estagiário 1
3      77b9b82  Corrigindo banco de dados    Estagiário 2
4      3c9093c  Dando merge com master       Desenv.
5      b3d92c5  Adicionando novo evento      Colega
6      7feddbb  Adicionando arquivos         Desenv.
7      a809379  Commit inicial               Desenv.

Você tenta seguir a dica anterior:

git rebase --onto HEAD~4 HEAD~1 master


Mas acaba em:

Um monte de erros antes...

error: Failed to merge in the changes.
Patch failed at 0001 Adicionando novidades
hint: Use 'git am --show-current-patch' to see the failed patch

Resolve all conflicts manually, mark them as resolved with
"git add/rm ", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort"
.

E agora????

Nem tudo está perdido. Antes rode o comando: "git rebase --abort",  "git reset --hard origin/master" e, rode este comando:

git rebase -i HEAD~4 


Vai aparecer várias linhas para fazer as alterações neste estilo:

pick 77b9b82 Corrigindo banco de dados
pick ae45fab Melhorando banco de dados
pick 93bf23d bla bla bla bla bla
pick 2c6a45b Adicionando novidades


Note que a ordem está inversa. Agora, de cima para baixo, troque, a partir da seguinda linha, a palavra pick por squash (ou s que o resultado é o mesmo). O resultado fica, mais ou menos assim:

pick 77b9b82 Corrigindo banco de dados
s ae45fab Melhorando banco de dados
s 93bf23d bla bla bla bla bla
s 2c6a45b Adicionando novidades

Salva e uma outra janela de edição aparece. Neste caso ele mostra todas as linhas dos commits. Comenta todas, menos a que você deseja manter. Isso não altera no resultado final. Mas, como você quer se livrar dos commits indesejáveis, comentar faz todo sentido.

Daí só salva e os commits antigos foram devidamente eliminados quando foi feito a unificação. Mas isso só vale se fez a devida correção no seu commit. Caso contrário faça alguns reverts antes e siga a mesma dica, mudando apenas o número das linhas no HEAD, que aumentou com os reverts.

Mais informações em:

https://www.internalpointers.com/post/squash-commits-into-one-git


Tenham um bom domingo uma ótima semana.