yast2 kdump error when updating grub (only on PowerPC configuring fadump)

This document (7023178) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 12 Service Pack 3 (SLES 12 SP3)

Situation

The issue affects only PowerPC (ppc64le) using 'fadump=on'.

Using 'yast2 kdump' to edit the settings is causing an 'Internal error' on 'OK' and 'save':

YaST2 - kdump @ linux

 Initializing kdump Configurationx   

Reading the config file... => Reading kernel boot options... - Calculating memory limits...
???????????????????????????????????????????????????????????????????????????????? ?Error ? ?Execution of command "[["/usr/sbin/grub2-install", "--target=powerpc-ieee1275"? ?Exit code: 1 ? ?Error output: Installing for powerpc-ieee1275 platform. ? ?/usr/sbin/grub2-install: error: the chosen partition is not a PReP partition. ? ? ? ? [OK] ? ????????????????????????????????????????????????????????????????????????????????

or

???????????????????????????????????????????????????????????????????????????????? ?Error ? ?Internal error. Please report a bug report with logs. ? ?Run save_y2logs to get complete logs. ? ?Details: Invalid loader device /dev/disk/by-id/dm-uuid-part1-mpath-1IBM_IPR-10? ?Caller: /usr/share/YaST2/lib/bootloader/mbr_update.rb:200:in `partition_to_ac? ? ? ? [OK] ? ????????????????????????????????????????????????????????????????????????????????


Notice the "Invalid loader device /dev/disk/by-id/dm-uuid-part1-mpath-1IBM_IPR-10_58C7ED0000000040" in the second error output.
The device is read from the /etc/default/grub_installdevice but 'YaST/libstorage' doesn't know about the device.

Resolution

The kdump update, kdump-0.8.16-7.8.1 released July/2018 includes the patch to avoid rewriting /etc/default/grub_installdevice when using 'yast2 kdump'.

The yast2-bootloader-3.2.27.1-2.6.4 and libstorage-2.26.12.2-3.3.2 update released August/2018 includes the fix correcting how udev ids with dm-uuid-names were handled.

Until the update can be installed, the below workaround,  editing the /etc/default/grub_installdevice, can be used.


Workaround:

After installing the kdump update and before using 'yast2 kdump', the content of the /etc/default/grub_installdevice needs to be reviewed.
If the /etc/default/grub_installdevice was already overwritten with the incorrect symlink/udev id, that /dev/disk/by-id/<symlink> needs to be changed.

# cat /etc/default/grub_installdevice

If it contains a symlink looking like this:
/dev/disk/by-id/*-partN-mpath-* ,
the symlink needs to be changed, setting -partN- at the end and preferably using the scsi- or wwn- ID, so it looks like this:
/dev/disk/by-id/scsi-*-partN or /dev/disk/by-id/wwn-*-partN.

For example:

# cat /etc/default/grub_installdevice
/dev/disk/by-id/dm-uuid-part1-mpath-1IBM_IPR-10_58C7ED0000000040
activate

This is incorrect and the symlink needs to be changed to either the scsi- or wwn- symlink and look like this:

# cat /etc/default/grub_installdevice
/dev/disk/by-id/scsi-1IBM_IPR-10_58C7ED0000000040-part1
activate

or when using the wwn-<ID>-part1 for that device like this:

# cat /etc/default/grub_installdevice
/dev/disk/by-id/wwn-0xIBM_IPR-10_58C7ED0000000040-part1
activate


The udev IDs are listed in the /dev/disk/by-id directory.

# ls -l /dev/disk/by-id/

will show all names for the mapped device dm-X, (the device grub is installed on). Search for the device's specific ID already set in the /etc/default/grub_installdevice in the /dev/disk/by-id/ line.
Then by looking at the content of /dev/disk/by-id, the other symlinks for the same LUN can be seen.
Either the scsi- or wwn- symlink for that ID can be selected to update the /etc/default/grub_installdevice /dev/disk/by-id/ with.
The symlink can be changed in the file directly with a text editor or by writing on a terminal to it:

# cat >/etc/default/grub_installdevice <<EOD
>  /dev/disk/by-id/scsi-1IBM_IPR-10_58C7ED0000000040-part1
> activate
> EOD


Once the "/dev/disk/by-id/" was changed accordingly, "yast2 kdump" can be used to configure fadump.

Cause

If 'fadump=on' is set, kdump calls perl-Bootloader to update and rewrites the configuration files including /etc/default/grub_installdevice.
It then takes the first by-id symlink in unspecified order which can result in a symlink of the unexpected dm-uuid-part1-mpath-* form, which is wrong in this case.

Additional Information


Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:7023178
  • Creation Date: 12-Jul-2018
  • Modified Date:03-Mar-2020
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback@suse.com

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Join Our Community

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.


SUSE Customer Support Quick Reference Guide SUSE Technical Support Handbook Update Advisories
Support FAQ

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.

Go to Customer Center