[FUG-BR] Cuidado na atualização no/pro FreeBSD 12 (problema, descrição e solução)

[Vinícius Zavam]

2017-06-06 1:40 GMT+02:00, Joao Rocha Braga Filho <goffredo em gmail.com>:
> 2017-06-05 19:36 GMT-03:00 Otacílio <otacilio.neto em bsd.com.br>:
>
>> Em 05/06/2017 11:23, Joao Rocha Braga Filho escreveu:
>>
>>> Em 5 de jun de 2017 11:03 AM, "Paulo Henrique" <paulo.rddck em bsd.com.br>
>>> escreveu:
>>>
>>> Em 5 de junho de 2017 10:37, Joao Rocha Braga Filho <goffredo em gmail.com>
>>> escreveu:
>>>
>>> Em 5 de jun de 2017 2:17 AM, "Paulo Henrique" <paulo.rddck em bsd.com.br>
>>>> escreveu:
>>>>
>>>> Em 5 de junho de 2017 00:01, Joao Rocha Braga Filho
>>>> <goffredo em gmail.com>
>>>> escreveu:
>>>>
>>>> Oi pessoal.
>>>>>
>>>>> Eu uso no meu desktop o FreeBSD 12 e tive um problema para atualizar
>>>>>
>>>> ele.
>>>
>>>> Depois que subi o kernel em monousuário para instalar o resto do
>>>> sistema
>>>>> tudo
>>>>> o que eu fazia dava chamada ilegal de system call. Até o /bin/sh dava
>>>>>
>>>> este
>>>>
>>>>> erro.
>>>>> Fiquei meio empacado.
>>>>>
>>>>> Dei boot com o kernel anterior e fui fazer um make installworld, e
>>>>> mesma
>>>>> coisa.
>>>>>
>>>>> Alguma coisa importante mudou nas system calls.
>>>>>
>>>>> Depois de ficar empacado, e um pouco de RTFM, achei o que era e como
>>>>> contornar.
>>>>>
>>>>> O que aconteceu, e a solução, estão descritos no arquivo
>>>>>
>>>> /usr/src/UPDATING,
>>>>
>>>>> na anotação feita em 20170523 (23/05/2017). O FreeBSD aumentou o
>>>>> limite
>>>>> de arquivos e diretórios que um sistema de arquivo poderia ter, de um
>>>>> número
>>>>> muito grande para um número grande para ca... ca... caramba, trocando
>>>>> a
>>>>> representação de i-nodos para 64 bits, o que teve que mudar algumas
>>>>>
>>>> system
>>>>
>>>>> calls, gerando uma incompatibilidade.
>>>>>
>>>>> Para contornar, e poder fazer a atualização do sistema, foi criada a
>>>>>
>>>> opção
>>>>
>>>>> de
>>>>> kernel COMPAT_FREEBSD11 que tem que ser colocada no seu arquivo de
>>>>> configuração do kernel antes de compilar ele.
>>>>>
>>>>> options COMPAT_FREEBSD11
>>>>>
>>>>> Ela faz com que os formatos de chamada de system calls que envolvam
>>>>>
>>>> i-nodos
>>>>
>>>>> sejam aceitas no formato de i-nodo anterior.
>>>>>
>>>>> Aparentemente, depois do sistema instalado, ela possa ser eliminada,
>>>>> mas
>>>>> não
>>>>> quero experimentar isto agora.
>>>>>
>>>>> Um efeito colateral é que agora o meu kernel antigo, o que usei para
>>>>> me
>>>>> salvar
>>>>> quando deu problema, não deve mais aceitar todo o resto que está
>>>>>
>>>> instalado.
>>>>
>>>>> É uma forte suspeita, e não estou afim de testar isto agora.
>>>>>
>>>>> Achei que é uma mudança importante, que afetará quem faz atualização,
>>>>> e
>>>>>
>>>> que
>>>>
>>>>> me fez penar, então resolvi compartilhar para que outros não penem.
>>>>>
>>>>> E acho que ter mais de 4 bilhões de arquivos e diretórios em um
>>>>> sistema
>>>>>
>>>> de
>>>>
>>>>> arquivos algo extraordinariamente difícil, mas quem sabe no futuro,
>>>>>
>>>> daqui
>>>
>>>> a
>>>>
>>>>> 10 anos. Eu comparo com UFS2, que superou o limite de 2 TB de um
>>>>> sistema
>>>>> de aquivos. Isto faz mais de 10 anos, creio eu, e agora tenho discos
>>>>> de
>>>>>
>>>> 4
>>>
>>>> TB
>>>>> no meu desktop e de backup.
>>>>>
>>>>>
>>>>> Abraços a todos,
>>>>>      João Rocha.
>>>>>
>>>>> Agradecemos a dica João !!
>>>>
>>>> O lance de arquivos em um unico diretório não é com relação a arquivos
>>>> de
>>>>
>>>>
>>>> Em único sistemas de arquivos.
>>>>
>>>> usuários, mais sim arquivos de configurações e dependências de
>>>> aplicações.
>>>>
>>>> o ~/.cache por exemplo é facil ter ele com mais de 1G de arquivos.
>>>>
>>>>
>>>> Faz sentido. E cache de squid, por exemplo.
>>>>
>>>>
>>>>
>>>> Não é o cache do Squid, embora realmente ele pode chegar a isso fácil,
>>> coloco com relação ao cache do KDE, Firefox, que costumam manter muito
>>> cache de navegação.
>>>
>>>
>>> Tenho a impressão que o Chrome é por. Se tiver problema no sistema de
>>> arquivos ele pode causar um Panic.
>>>
>>>
>>> João.
>>>
>>>
>>> Att.
>>>
>>>
>>
>> Rolou este e-mail sobre este assunto na lista current tem pouco tempo.
>>
>> https://lists.freebsd.org/pipermail/freebsd-current/2017-May/066136.html
>
>
> Muito obrigado.
>
> Isto é mais completo do que as notas do /usr/src/UPDATING.
>
>
> Abraços,
>     João Rocha.
>
>
>
>>
>> []'s
>> -Otacilio

ACHO que vcs já contornaram o problema, mas gostaria de lembrar que
usar "include GENERIC" no arquivo de configuração do kernel de vcs
poderia ter ajudado um bocado, hein. além disso, não acompanhar
atualizações publicadas no UPDATING (com esse grau de mudanças na
base) dá dor de cabeça - apesar de ser divertido no final das contas.

5 centavos de contribuição:
http://fug.com.br/historico/html/freebsd/2009-August/038502.html

idem para "GENERIC-NODEBUG", é claro.

mantenho algumas máquinas com HEAD/CURRENT (duas delas são minhas
estações de trabalho. outras atuam em produção; sim) e nem senti
impacto quando foram atualizadas, justamente por seguir esse esquema
de inclusão do GENERIC e toda a resenha de atualização de base+kernel
como manda o figurino.

[ ]


-- 
Vinícius Zavam
keybase.io/egypcio/key.asc