Atualização do Solaris 11.3 - alterações no rpool após a atualização desaparecer após a reinicialização

Question

Eu tenho um servidor de teste executando o Solaris 11.2 (no hardware HP Proliant Gen8 Microserver). Em 31 de outubro, atualizei o sistema para o Solaris 11.3, conforme descrito no artigo de documentação do Solaris Atualizando um sistema para o Oracle Solaris 11.3 e tudo parecia correr bem. Depois de duas semanas, encerrei o servidor com

shutdown -y -i5 -g0

Após iniciar o servidor novamente, o estado do rpool foi revertido para o estado antes do upgrade. O login com ssh exibiu o último horário de login em 31 de outubro, mesmo que eu tenha feito logon em 14 de novembro. Correndo

uname -a

exibe

SunOS nas3 5.11 11.2 i86pc i386 i86pc

e todos os arquivos no rpool criado após 31 de outubro desaparecerem. O console mostra a mensagem

nas3 console login: Nov 15 18:11:34 nas3 genunix: NOTICE: /dev/chassis/.ca/Proliant-MicroServer-Gen8.CZ152300T4/SYS: cannot create shadow directory - error

Infelizmente, não há instantâneos do rpool. Perguntas:

1. O que poderia ter causado isso?
2. Existe alguma maneira de recuperar os dados salvos no rpool após a atualização?

O que tentei:

• googling (é claro) o Google não tem um único resultado para a consulta de pesquisa "não é possível criar o diretório de sombra".
• pesquisando a documentação do Solaris, por exemplo Problemas ao atualizar para o Oracle Solaris 11.3
• verificando instantâneos do ZFS. Infelizmente, nenhum foi feito (sim, isso não foi muito sábio)
• verificar o estado do rpool - é relatado como sendo saudável e sem erros

Atualizar

Rodando

beadm list

mostra

BE        Active Mountpoint Space   Policy Created
--        ------ ---------- -----   ------ -------
solaris   N      /          171.47M static 2015-08-16 17:51
solaris-1 R      -          14.72G  static 2015-10-31 21:52

Solução

Como apontado por Lambert, o ambiente de inicialização estava errado. Apenas reiniciando com

init 6

resolveu o problema. Ainda seria interessante descobrir o que causou isso.

Atualização 2:

aparentemente executando

beadm activate solaris-1

ativada permanentemente a nova partição. Consulte Como alterar o ambiente de inicialização padrão .

    

Answer 1

Qual é o resultado de beadm list ? Você deve ter vários ambientes de inicialização. Usando beadm activate <bename> você pode alternar entre eles (depois de ativar, você deve reiniciar).

Um ambiente de inicialização também pode ser escolhido no nível da cavidade. Talvez você tenha pressionado por engano a seta para baixo e pressionado enter e escolhido manualmente um ambiente de inicialização baseado no release anterior do Solaris.

    

Answer 2

Lambert resolveu seu problema principal.

A atualização provavelmente teria criado um novo BE. Se você precisa olhar para um velho BE, você sempre pode montá-lo.
ie: beadm mount solaris-1 /mnt montaria o conjunto BE inativo para a próxima reinicialização para ser montado em / mnt.

Historicamente, a LU (v10) não reproduzia bem a menos que você usasse os comandos init, e o BE na v11 é provavelmente o mesmo. Normalmente, após uma atualização, você fará um init 6 para reinicializar o novo BE. Seu comando shutdown emitiu um init 5 que deveria ter sincronizado tudo e configurar o novo BE para inicializar via grub.