Re: [FUG-BR] Cuidado na atualização no/pro FreeBSD 12 (problema, descrição e solução)
2017-06-06 1:40 GMT+02:00, Joao Rocha Braga Filho : > 2017-06-05 19:36 GMT-03:00 Otacílio : > >> Em 05/06/2017 11:23, Joao Rocha Braga Filho escreveu: >> >>> Em 5 de jun de 2017 11:03 AM, "Paulo Henrique" >>> escreveu: >>> >>> Em 5 de junho de 2017 10:37, Joao Rocha Braga Filho >>> escreveu: >>> >>> Em 5 de jun de 2017 2:17 AM, "Paulo Henrique" escreveu: Em 5 de junho de 2017 00:01, Joao Rocha Braga Filho 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 - Histórico: h
Re: [FUG-BR] Cuidado na atualização no/pro FreeBSD 12 (problema, descrição e solução)
2017-06-05 19:36 GMT-03:00 Otacílio : > Em 05/06/2017 11:23, Joao Rocha Braga Filho escreveu: > >> Em 5 de jun de 2017 11:03 AM, "Paulo Henrique" >> escreveu: >> >> Em 5 de junho de 2017 10:37, Joao Rocha Braga Filho >> escreveu: >> >> Em 5 de jun de 2017 2:17 AM, "Paulo Henrique" >>> escreveu: >>> >>> Em 5 de junho de 2017 00:01, Joao Rocha Braga Filho >>> 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. -- "Sempre se apanha mais com as menores besteiras. Experiência própria." http://jgoffredo.blogspot.com goffr...@gmail.com - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd 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 > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- "Sempre se apanha mais com as menores besteiras. Experiência própria." http://jgoffredo.blogspot.com goffr...@gmail.com - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cuidado na atualização no/pro FreeBSD 12 (problema, descrição e solução)
Em 05/06/2017 11:23, Joao Rocha Braga Filho escreveu: Em 5 de jun de 2017 11:03 AM, "Paulo Henrique" escreveu: Em 5 de junho de 2017 10:37, Joao Rocha Braga Filho escreveu: Em 5 de jun de 2017 2:17 AM, "Paulo Henrique" escreveu: Em 5 de junho de 2017 00:01, Joao Rocha Braga Filho 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. -- "Sempre se apanha mais com as menores besteiras. Experiência própria." http://jgoffredo.blogspot.com goffr...@gmail.com - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd 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 []'s -Otacilio - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cuidado na atualização no/pro FreeBSD 12 (problema, descrição e solução)
Em 5 de jun de 2017 11:03 AM, "Paulo Henrique" escreveu: Em 5 de junho de 2017 10:37, Joao Rocha Braga Filho escreveu: > Em 5 de jun de 2017 2:17 AM, "Paulo Henrique" > escreveu: > > Em 5 de junho de 2017 00:01, Joao Rocha Braga Filho > 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. > > > > -- > > "Sempre se apanha mais com as menores besteiras. Experiência própria." > > > > http://jgoffredo.blogspot.com > > goffr...@gmail.com > > - > > Histórico: http://www.fug.com.br/historico/html/freebsd/ > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > > > 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. > Os usuários hoje não fazem tanto arquivos como os programas em si. > > Att.! > > > -- :UNI>http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cuidado na atualização no/pro FreeBSD 12 (problema, descrição e solução)
Em 5 de junho de 2017 10:37, Joao Rocha Braga Filho escreveu: > Em 5 de jun de 2017 2:17 AM, "Paulo Henrique" > escreveu: > > Em 5 de junho de 2017 00:01, Joao Rocha Braga Filho > 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. > > > > -- > > "Sempre se apanha mais com as menores besteiras. Experiência própria." > > > > http://jgoffredo.blogspot.com > > goffr...@gmail.com > > - > > Histórico: http://www.fug.com.br/historico/html/freebsd/ > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > > > 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. Att. > Os usuários hoje não fazem tanto arquivos como os programas em si. > > Att.! > > > -- :UNI>http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cuidado na atualização no/pro FreeBSD 12 (problema, descrição e solução)
Em 5 de jun de 2017 2:17 AM, "Paulo Henrique" escreveu: Em 5 de junho de 2017 00:01, Joao Rocha Braga Filho 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. > > -- > "Sempre se apanha mais com as menores besteiras. Experiência própria." > > http://jgoffredo.blogspot.com > goffr...@gmail.com > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > 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. Os usuários hoje não fazem tanto arquivos como os programas em si. Att.! -- :UNI>http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cuidado na atualização no/pro FreeBSD 12 (problema, descrição e solução)
Em 5 de junho de 2017 00:01, Joao Rocha Braga Filho 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. > > -- > "Sempre se apanha mais com as menores besteiras. Experiência própria." > > http://jgoffredo.blogspot.com > goffr...@gmail.com > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > Agradecemos a dica João !! O lance de arquivos em um unico diretório não é com relação a arquivos de 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. Os usuários hoje não fazem tanto arquivos como os programas em si. Att.! -- :UNI>http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
