4.4.9. Mudanças na Coleção de Acidentes do Kernel (Kdump)

A diretiva net não é mais suportada. Os usuários deve agora definir explicitamente tanto o ssh como o nfs.

A opção blacklist não é mais suportada. Ao invés disso, os usuários podem especificar o rd.driver.blacklist como um parâmetro no arquivo /etc/sysconfig/kdump de seu kernel de captura.

A ação padrão mount_root_run_init , que era realizada se o despejo a um alvo pretendido falhasse, foi substituída pela ação dump_to_rootfs . Ao invés de montar o sistema de arquivos root real, executando scripts do init, e tentando salvar o vmcore quando o serviço kdump começasse, esta nova ação monta o sistema de arquivos root e salva o vmcore nele imediatamente.

Uma nova diretiva, dracut_args, permite que você especifique argumentos do dracut adicionais ao configurar o kdump.

A opção debug_mem_level não está mais incluída no kdump. Esta função foi movida para o dracut. Os usuários podem obter a mesma função, especificando rd.memdebug como um parâmetro no arquivo /etc/sysconfig/kump de seu kernel de captura.

A diretiva de options era usada anteriormente para incluir parâmetros específicos no módulo do kernel no sistema de arquivo ram inicial (initramfs). Este método não é suportado em Red Hat Enterprise Linux 7. Ao invés disso, os usuários podem especificar parâmetros relevantes no arquivo /etc/sysconfig/kdump de seu kernel de captura.

Os parâmetros link_delay e disk_timeout não são mais necessários ou suportados, pois o dracut contém o udev, que endereço o caso de uso para os parâmetros que foram requeridos anteriormente.

Todas as metas de despejo de back-end do sistema de arquivos devem ser montadas no kernel travado antes do serviço kdump ser iniciado e a imagem ramdisk inicial ser criada. Você pode conseguir isto, adicionando essas metas ao /etc/fstab para serem montadas automaticamente no momento da inicialização.

Se você especificar um caminho, mas não especificar um alvo, e qualquer diretório no caminho que você especificar for um ponto de montagem para um dispositivo separado, o vmcore é salvo no caminho, e não o dispositivo montado em algum lugar ao longo desse caminho. Portanto, quando o sistema for reinicializado, e os dispositivos forem montados, a vmcore ficará inacessível, pois o dispositivo foi montado em cima de sua localização. A Red Hat Enterprise Linux 7 agora adverte sobre esta questão quando você especificar um caminho sem especificar um alvo.