Kernel panic on s390x after manual initramfs regeneration without zipl execution

Solution Verified - Updated

Environment

  • Red Hat Enterprise Linux 8
  • Red Hat Enterprise Linux 9
  • Red Hat Enterprise Linux 10
  • IBM Z(s390x)
  • zipl

Issue

  • After regenerating the initramfs using dracut -f without executing the zipl command, the system fails to boot and encounters a kernel panic with error:

    No filesystem could mount root, tried:
    Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
    

Resolution

  • zipl immediately after any use of dracut to regenerate the bootmap:

    # zipl
    
  • After applying the workaround or manually running zipl, verify timestamps:

    # ls -l /boot/initramfs-*.img /boot/bootmap
    

    Ensure that /boot/bootmap is newer than or equal to the latest initramfs files.

Root Cause

  • IBM Z (s390x) systems use zipl to generate a bootmap containing raw block addresses of the kernel and initramfs. When the initramfs is regenerated with dracut -f, the physical layout on disk may change. Since dracut does not automatically call zipl, the bootmap remains stale, leading to a bootloader mismatch and kernel panic.

Diagnostic Steps

  • Confirm if the initramfs was regenerated recently:

    # ls -l /boot/initramfs-*.img
    
  • Check if /boot/bootmap is older than the initramfs:

    # stat /boot/bootmap
    # stat /boot/initramfs-<kernel-version>.img
    
  • Check if zipl was executed recently (not guaranteed to log):

    # journalctl | grep zipl
    
Components
Category

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.