O ASMLib v3 no Oracle Linux 8 deixou de ser opcional: a partir do OL8 ele passou a ser obrigatório. Quem faz o upgrade de OL7 para OL8 com o Leapp encontra um bloqueio que nem sempre é evidente: o pacote oracleasm-support da linha el8 depende do libbpf 0.6.0, que não está nos repositórios habilitados por padrão. Este post mostra como instalar o ASMLib v3 no Oracle Linux 8, subir o SO e deixar o ASM montado de volta, sem trocar o UEK6.
O cenário
O ambiente é um servidor single, com Grid Infrastructure 19c em Oracle Restart. São quatro disk groups (DATA, FRA, REDO1 e REDO2) sobre nove discos ASMLib, todos device sd direto, sem multipath. Esses discos guardam os datafiles, o redo e a área de recuperação, então o ASM precisa voltar integro depois da atualização de SO.
A origem é o Oracle Linux 7.9 com UEK R6, e o destino é o Oracle Linux 8.10 com o mesmo UEK R6. O upgrade do SO foi feito com o Leapp, pelo time de Sistema Operacional. A parte do DBA foi preparar o ASMLib antes, para o Leapp não travar, e remontar os discos depois.
O inventário inicial já mostra de onde vem o problema. O oracleasmlib já estava na linha el8 (v3), mas o oracleasm-support ainda era el7 (v2). No OL7 essa combinação funciona. A partir do OL8, a Oracle exige o ASMLib v3 completo, conforme o guia oficial de instalação do Oracle ASMLib, e é essa migração de v2 para v3 que gera o bloqueio.
Os comandos abaixo levantam o estado de partida: SO, kernel, pacotes ASMLib, módulo e discos.
cat /etc/oracle-release
uname -r
rpm -qa | grep -i oracleasm
modinfo oracleasm | egrep 'filename|vermagic'
oracleasm status
oracleasm listdisks
Vale também registrar a configuração do ASMLib: o usuário dono, o grupo e o scan order. Esses valores ficam em /etc/sysconfig/oracleasm e serão necessários para reconfigurar a v3 depois.
cat /etc/sysconfig/oracleasm
O problema
O Leapp roda em fases. Antes de mexer no sistema, ele faz um preupgrade e gera um relatório de inibidores, que são pendências a resolver para o upgrade continuar. Foi nessa etapa que ele parou.
O inibidor era o oracleasm-support. Para ir de OL7 para OL8, o Leapp tenta trocar o pacote el7 pela versão el8, e toda versão el8 depende de libbpf 0.6.0 ou superior (MOS 3058641.1). Esse libbpf não estava nos repositórios habilitados, então a dependência não fechava e o Leapp parava.
No leapp-report.txt dá para ver que todas as versões el8 do oracleasm-support, da 3.0.0-6 até a 3.1.1-5, falham pela mesma razão. Listando o libbpf nos repositórios habilitados, a maior versão é a 0.5.0, abaixo do exigido:
dnf list libbpf --showduplicates 2>/dev/null | tail -15
dnf list oracleasm-support --showduplicates 2>/dev/null | tail -10
Remover o oracleasm e seguir não era opção: ele é a camada que entrega os discos ao ASM. Sem ele, o ASM não monta os disk groups e o banco não abre. O pacote que travava o upgrade era o mesmo que o destino precisava ter.
Vale separar bem o que estava em jogo: não era incompatibilidade do ASMLib com o Oracle Linux 8, nem versão errada do pacote. O ASMLib v3 é a versão que o OL8 exige, e ele foi feito para rodar tanto no UEK6, pelo driver oracleasm, quanto no UEK7, pelo io_uring, com as duas interfaces no mesmo binário, conforme a introdução ao ASMLib v3 publicada pela Oracle. O que faltava era só uma dependência: o libbpf 0.6.0, que existe, mas num repositório desligado por padrão. Essa diferença muda onde se procura a solução: em vez de trocar a versão do ASMLib, basta fornecer a biblioteca que falta.
O desafio
O impasse, em resumo: o OL8 exige o ASMLib v3, o v3 depende de um libbpf mais novo do que o repositório padrão oferece, e esse pacote é essencial para o ASM voltar. O libbpf 0.6.0 existe, mas num repositório que vem desabilitado e está ligado ao kernel UEK7. Trocar o UEK6 de produção só para resolver uma dependência de instalação não era o que se queria.
A meta era instalar o ASMLib v3 e o libbpf certo sem puxar o UEK7, reconfigurar o ASMLib com o usuário correto e remontar os nove discos como estavam, mesmo com o Linux mudando a ordem dos devices no reboot.
Por que o ASMLib v3 no Oracle Linux 8 é obrigatório, e onde entra o libbpf
A obrigatoriedade do ASMLib v3 no Oracle Linux 8 vem da própria Oracle: o ASMLib v3 (oracleasmlib e oracleasm-support na linha 3.0.0 ou superior) em servidores com Oracle Linux 8 e kernels mais novos, conforme o guia de instalação do Oracle ASMLib. A linha el7 da v2 fica para trás.
A v3 trouxe o iofilter, uma proteção que usa BPF para impedir escrita acidental nos discos ASM por comandos como o dd. É esse recurso que liga o pacote ao libbpf 0.6.0. O iofilter só funciona em kernels UEK7 ou superiores, que largaram o módulo oracleasm e usam io_uring, conforme as notas do ASMLib v3. No UEK6, o driver oracleasm continua valendo, e o ASMLib v3 trabalha pela mesma interface da v2, mostrada como KABI_V2 no oracleasm status. Mesmo sem usar o iofilter, o pacote el8 carrega o binário que depende do libbpf, então a dependência precisa ser resolvida para instalar.
O libbpf 0.6.0 está disponível no Oracle Linux 8, no repositório ol8_UEKR7, que vem desabilitado. É o que falta para o Leapp e para a reinstalação.
A estratégia em três fases
A divisão que funcionou separa o trabalho do DBA do trabalho de quem cuida do SO:
- Antes do upgrade: preparar o ASMLib para o Leapp não travar.
- Durante: o upgrade do SO com o Leapp.
- Depois: reinstalar o ASMLib v3 e remontar o ASM.
Fase 1: preparar o ASMLib antes do upgrade
Antes de tudo, salve o mapeamento de cada label para o device físico. Esse registro serve para conferir a remontagem depois. Para levantar isso rápido, dá para usar o script de identificação de discos ASM, ASMLIB e SO e guardar a saída.
oracleasm configure
ls -l /dev/oracleasm/disks/
Depois, desabilite o Oracle Restart, para ele não subir no meio do upgrade, e remova o oracleasm-support v2 que trava o Leapp:
crsctl disable has
dnf remove -y oracleasm-support
A remoção guarda a configuração em oracleasm.rpmsave, e os labels continuam no header de cada disco. Nenhum dado é alterado.
Fase 2: o upgrade do SO com Leapp
Com o inibidor resolvido, o upgrade segue o fluxo normal do Leapp para Oracle Linux:
leapp preupgrade --oraclelinux
leapp upgrade --oraclelinux
rebootDepois do reboot, confira o destino. Aqui ficou OL 8.10 com UEK6, e o libbpf ainda na versão antiga, esperando ser resolvido:
Fase 3: reinstalar o ASMLib v3 e remontar o ASM
Resolver o libbpf habilitando o UEKR7 só na transação
O libbpf 0.6.0 está no repositório ol8_UEKR7. Dá para confirmar quem fornece a versão exigida antes de instalar:
dnf repoquery --whatprovides 'libbpf >= 0.6.0' --enablerepo='*'
Não deixe o ol8_UEKR7 habilitado de forma permanente. A nota MOS 3058641.1 resolve o erro habilitando esse repositório de forma fixa e rodando um dnf update geral, mas esse caminho pode acabar trazendo o kernel UEK7 num update seguinte. Para ficar no UEK6, ligue o repositório só nesta transação, com o --enablerepo, para trazer o libbpf 0.6.0 sem mexer no resto:
dnf install oracleasm-support --enablerepo=ol8_UEKR7Antes de confirmar, leia o resumo. Devem aparecer dois itens: a instalação do oracleasm-support v3 e a atualização do libbpf para 0.6.0. Nenhum kernel-uek pode estar na lista. Se estiver, pare e revise, para não subir para o UEK7 sem querer.
Configurar o ASMLib com o usuário do Grid
A v3 cria um serviço systemd, então o configure roda como root. Aponte o dono para o usuário que roda a instância ASM, em geral o grid:
oracleasm configure -i
O aviso de I/O filtering não suportado com UEK6 é esperado, não é erro. O iofilter é do UEK7 e não se aplica aqui.
Aplicar e reler os discos
Na v3, a configuração só passa a valer depois de reiniciar o serviço pelo systemd. Reinicie, confira o status e releia os discos:
systemctl restart oracleasm
oracleasm status
oracleasm scandisks
oracleasm listdisks
oracleasm status mostrando a interface KABI_V2 e a releitura dos discos
O scandisks releu os headers e remontou cada label. Os nove discos voltam a aparecer, mesmo com o Linux trocando a ordem dos nomes sd no reboot:
O KABI_V2 confirma que o ASMLib v3 usa o driver oracleasm, como esperado no UEK6. É onde o mapeamento da Fase 1 ajuda: confira label a label.
Validação
Suba o Oracle Restart e confira os recursos. O ASM e os quatro disk groups devem ficar ONLINE:
crsctl enable has
crsctl start has
crsctl stat res -t
crsctl stat res: a instância ASM e os quatro disk groups ONLINE depois de subir o Oracle Restart
Como grid, confirme os disk groups montados no asmcmd:
su - grid
srvctl status asm
asmcmd lsdg
asmcmd lsdg: os quatro disk groups montados, sem disco offline
Os quatro disk groups montados, sem disco offline, fecham a remontagem. O ASM voltou inteiro depois da troca de SO.
Riscos e avisos
Depois desse procedimento, o erro mais comum é deixar o ol8_UEKR7 habilitado. Ele serviu só para fornecer o libbpf. Se ficar ligado, um dnf update futuro pode trazer o kernel UEK7 e mudar o comportamento do ASMLib, que passaria a usar io_uring. Deixe o repositório desabilitado.
Faça backup e snapshot do boot volume antes do Leapp. Upgrade maior de SO tem volta cara, e o próprio Leapp recomenda isso. Teste em uma cópia antes de rodar em produção.
Depois de um upgrade maior de SO, os binários Oracle compilados no OL7 podem reclamar de biblioteca por causa da troca de glibc. O 19c em OL8 pede UEK6 e Release Update 19.7 ou superior (MOS 2668780.1). Se o Grid ou o banco pedirem relink, refaça o relink no Oracle Home correspondente.
Erros comuns
| Mensagem | Causa provável | Ação |
|---|---|---|
| libbpf >= 0.6.0 is needed by oracleasm-support | repositório ol8_UEKR7 desabilitado | instalar com –enablerepo=ol8_UEKR7 |
| I/O filtering not supported with UEK6 | iofilter é recurso de UEK7+ | ignorar, é esperado em UEK6 |
| Failed to setup iofilter map (UEK7 ou OL9) | io_uring desabilitado no kernel | habilitar io_uring |
Validação técnica
Confirmado na documentação oficial: o ASMLib v3 é obrigatório em Oracle Linux 8 e superiores, conforme o guia de instalação do Oracle ASMLib. O iofilter foi adicionado para kernels UEK7+ e protege contra escrita acidental nos discos ASM, conforme o changelog do oracleasm-support. O erro de dependência do libbpf 0.6.0 está na nota MOS 3058641.1. Os requisitos do 19c em OL8 (UEK6, RU mínimo 19.7) estão na nota MOS 2668780.1.
Referências oficiais
- Installing and Configuring Oracle ASMLIB Software: obrigatoriedade do ASMLib v3 no OL8.
- Oracle Linux ASMLib v3: configuração do I/O filter e do serviço.
- Oracle ASMLib Downloads for Oracle Linux 8: pacotes oracleasmlib e oracleasm-support.
- Oracle Linux 8: Upgrading Systems With Leapp: remover pacotes residuais que viram inibidores.
- MOS 3058641.1: erro de dependência do libbpf 0.6.0 no oracleasm-support.
- MOS 2668780.1: requisitos do Oracle Database 19c em OL8.
- MOS 1089399.1: política de suporte do ASMLib.
- Introduction to ASMLib v3 (blog Oracle Linux): por que a v3 funciona em UEK6 e UEK7 com o mesmo binário.
Conclusão
O bloqueio não era do Leapp, e sim da dependência do oracleasm-support v3 pelo libbpf 0.6.0, com o pacote certo num repositório desligado. Removendo o oracleasm-support antes, subindo o SO e reinstalando a v3 com o ol8_UEKR7 só na transação, o ASM voltou com os quatro disk groups montados e os nove discos no lugar, no mesmo UEK6. Esse é o procedimento de ASMLib v3 no Oracle Linux 8 que fechou o upgrade sem perder disco.
