Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-3289

Leapp can fail when /boot is a multipath

    • None
    • Moderate
    • rhel-sst-upgrades
    • None
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • If docs needed, set a value
    • None

      Description of problem:
      During the reboot step, Leapp is unable to mount /boot, it uses a wrong device name. After that, it is unable to proceed with the first actor (remove_grub_boot_entry).

      Version-Release number of selected component (if applicable):
      leapp-repository-0.14.0-4.el7_9.noarch

      How reproducible:
      Always for the customer.

      Actual results:
      ~~~~~~~~~
      [...]
      Sep 28 03:57:49 localhost upgrade[3457]: mount: /dev/sdk2 is already mounted or /boot busy
      Sep 28 03:57:49 localhost kernel: XFS (dm-17): Mounting V5 Filesystem
      Sep 28 03:57:49 localhost upgrade[3457]: mount: mount point /boot/efi does not exist
      Sep 28 03:57:49 localhost kernel: XFS (dm-17): Ending clean mount
      Sep 28 03:57:49 localhost kernel: XFS (dm-18): Mounting V5 Filesystem
      Sep 28 03:57:49 localhost kernel: XFS (dm-18): Ending clean mount
      Sep 28 03:57:49 localhost kernel: XFS (dm-15): Mounting V5 Filesystem
      Sep 28 03:57:49 localhost kernel: XFS (dm-15): Ending clean mount
      Sep 28 03:57:49 localhost kernel: XFS (dm-16): Mounting V5 Filesystem
      Sep 28 03:57:49 localhost kernel: XFS (dm-16): Ending clean mount
      Sep 28 03:57:54 localhost upgrade[3457]: ==> Processing phase `InitRamStart`
      Sep 28 03:57:54 localhost upgrade[3457]: ====> * remove_upgrade_boot_entry
      Sep 28 03:57:54 localhost upgrade[3457]: Remove boot entry for Leapp provided initramfs.
      Sep 28 03:57:54 localhost upgrade[3457]: Process Process-165:
      Sep 28 03:57:54 localhost upgrade[3457]: Traceback (most recent call last):
      [...]
      Sep 28 03:57:54 localhost upgrade[3457]: File "/usr/lib/python2.7/site-packages/leapp/libraries/stdlib/_init_.py", line 188, in run
      Sep 28 03:57:54 localhost upgrade[3457]: result=result
      Sep 28 03:57:54 localhost upgrade[3457]: CalledProcessError: Command ['/usr/sbin/grubby', '--remove-kernel=/boot/vmlinuz-upgrade.x86_64'] failed with exit code 1.
      Sep 28 03:57:55 localhost upgrade[3457]: ==========================================================================================================
      Sep 28 03:57:55 localhost upgrade[3457]: Actor remove_upgrade_boot_entry unexpectedly terminated with exit code: 1 - Please check the above details
      Sep 28 03:57:55 localhost upgrade[3457]: ==========================================================================================================
      [...]
      ~~~~~~~~~~~~~~

      Additional info:

      • The issue here is the fact /dev/sdk2 does not correspond to the boot partition
        ~~~
        sda 8:0 0 100G 0 disk
        `-<WWID> 253:9 0 100G 0 mpath
        -<WWID>p1 253:10 0 256M 0 part /boot/efi
        -<WWID>p2 253:11 0 500M 0 part /boot
        :
        sdk 8:160 0 100G 0 disk
        `-<WWID> 253:9 0 100G 0 mpath
        -<WWID>p1 253:10 0 256M 0 part /boot/efi
        -<WWID>p2 253:11 0 500M 0 part /boot
        ~~~
      • From my understanding, it's a timing issue with multipathd. The customer have lots of disks behind an Hitachi storage array, and only /boot and /boot/efi are not part of LVM.
      • Changing the fstab to use the /dev/mapper/path (with the wwids in this case) fixed the issue. The fstab entries have been reverted back once the system has been upgraded.

              leapp-notifications leapp-notifications
              rhn-support-cbesson Christophe Besson
              leapp-notifications leapp-notifications
              RHEL Upgrades QE Team RHEL Upgrades QE Team
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: