kdump-tools uses the wrong crashkernel command line parameter in ppc64le

[bugproxy]

== Comment: #0 - Thiago Jung Bauermann <email address hidden> - 2017-03-24 11:44:39 ==
---Problem Description---
kdump-tools uses the wrong crashkernel command line parameter in ppc64le:

u1704le?? grep crashkernel /boot/grub/grub.cfg
                linux /boot/vmlinux-4.10.0-13-generic root=UUID=2d6f73c7-b463-4f02-9ec4-8d4afed0635d ro crashkernel=384M-:128M

128M of reserved memory is too small for ppc64le.

That happens because /etc/default/grub.d/kdump-tools.cfg links to the wrong file:

u1704le?? ls -l /etc/default/grub.d/
total 8.0K
lrwxrwxrwx 1 root root 39 Mar 24 13:34 kdump-tools.cfg -> /etc/default/grub.d/kdump-tools.default
-rw-r--r-- 1 root root 80 Jan 5 08:07 kdump-tools.default
-rw-r--r-- 1 root root 137 Jan 5 08:07 kdump-tools..ppc64el
u1704le??

As can be seen, it should be pointing to kdump-tools..ppc64el but isn't.

Also, kdump-tools..ppc64el has two dots in it. That doesn't seem right.
Possibly just a cosmetic issue, but it would be nice if that was fixed.

Contact Information = <email address hidden>

---uname output---
Linux u1704le 4.10.0-13-generic #15-Ubuntu SMP Thu Mar 9 20:27:28 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux

Machine Type = Any ppc64le machine. In this case, a KVM guest hosted on an 8286-42A.

---Debugger---
A debugger is not configured

---Steps to Reproduce---
 sudo apt intall kdump-tools
Select 'Yes' when asked whether kdump should be enabled.

Userspace tool common name: kdump

The userspace tool has the following bit modes: 64 bit

Userspace rpm: kdump-tools

Userspace tool obtained from project website: na

*Additional Instructions for <email address hidden>:
-Attach ltrace and strace of userspace application.

[Louis Bouchard (louis)]

Hello,

Well, this is to be expected as the postinst script will only change the target of the symlink if the architecture is ppc64EL and not ppc64LE ( EL != LE).

Now if both are interchangeable (I must admit my ignorance of this architecture), I don't mind fixing the script to apply to both EL and LE.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-05-12 12:10 EDT-------
(In reply to comment #7)
> Now if both are interchangeable (I must admit my ignorance of this
> architecture), I don't mind fixing the script to apply to both EL and LE.

Yes, they are equivalent. My understanding is that everyone calls it ppc64le except Debian, who decided to call it ppc64el to keep consistency with mipsel.

[Dimitri John Ledkov (xnox)]

On 12 May 2017 at 15:30, Louis Bouchard <email address hidden> wrote:
> Hello,
>
> Well, this is to be expected as the postinst script will only change the
> target of the symlink if the architecture is ppc64EL and not ppc64LE (
> EL != LE).
>
> Now if both are interchangeable (I must admit my ignorance of this
> architecture), I don't mind fixing the script to apply to both EL and
> LE.
>

linux / GNU toolchain / etc use the names "le" for the little endian
architectures.

Debian / dpkg architecture tags use "el" as a tongue-in-cheeck pun
that it is endian little ordered.

Thus there must be a missmatch of values: dpkg vs toolchain architecture:

$ dpkg-architecture -appc64el
dpkg-architecture: warning: specified GNU system type
powerpc64le-linux-gnu does not match CC system type x86_64-linux-gnu,
try setting a correct CC environment variable
...
DEB_HOST_ARCH=ppc64el
DEB_HOST_ARCH_BITS=64
DEB_HOST_ARCH_CPU=ppc64el
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_ARCH_OS=linux
DEB_HOST_GNU_CPU=powerpc64le
DEB_HOST_GNU_SYSTEM=linux-gnu
DEB_HOST_GNU_TYPE=powerpc64le-linux-gnu
DEB_HOST_MULTIARCH=powerpc64le-linux-gnu
...

Note the ARCH tag which is dpkg tag, and the GNU_ tags which are what
are used by binutils/gcc/etc tooling. CPU tag is what kernel uses in
uname -a.

--
Regards,

Dimitri.

[dann frazier (dannf)]

fyi, I have a patch set prepared for this in the Debian bug. I'd like to see that uploaded in Debian before integrating it in Ubuntu because, if Debian chooses a different solution, it will be difficult to back that that out and resync. I've sent a ping to the Debian bug today.

[dann frazier (dannf)]

The fixed from Debian has now been merged into artful.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-08-18 13:50 EDT-------
Noticed that the offset for crashkernel is set to 32MB in
/etc/default/grub.d/kdump-tools..ppc64el file . Any specific reason
why this value is chosen? With the default offset on powerpc being
128MB, this seems way off (considering there is only so much real
memory available.) Can the offset (@32M) be stripped from
/etc/default/grub.d/kdump-tools..ppc64el file to fall back to the
kernel default..

Thanks
Hari

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-11-17 03:10 EDT-------
(In reply to comment #16)
> Noticed that the offset for crashkernel is set to 32MB in
> /etc/default/grub.d/kdump-tools..ppc64el file . Any specific reason
> why this value is chosen? With the default offset on powerpc being
> 128MB, this seems way off (considering there is only so much real
> memory available.) Can the offset (@32M) be stripped from
> /etc/default/grub.d/kdump-tools..ppc64el file to fall back to the
> kernel default..

The above concern seems to be addressed with the patch attached in bug 1658733.
I would rather prefer no offset though (letting the kernel to decide on the default offset)

btw, it is targeted for artful. Would that make it into 17.04 as well?

Thanks
Hari

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-11-20 04:10 EDT-------
(In reply to comment #18)
> (In reply to comment #16)
> > Noticed that the offset for crashkernel is set to 32MB in
> > /etc/default/grub.d/kdump-tools..ppc64el file . Any specific reason
> > why this value is chosen? With the default offset on powerpc being
> > 128MB, this seems way off (considering there is only so much real
> > memory available.) Can the offset (@32M) be stripped from
> > /etc/default/grub.d/kdump-tools..ppc64el file to fall back to the
> > kernel default..
>
> The above concern seems to be addressed with the patch attached in bug
> 1658733.

which is https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1658733

whose summary reads: "Ubuntu 16.04.2KVM:kdump fails to mount root file system when noirqdistrib is missing as dump kernel parameter "

> I would rather prefer no offset though (letting the kernel to decide on the
> default offset)

Hari, I think we should be opening a separate bugzilla-bug for this since it is a different issue. Can you please collate information and open a new one?

>
> btw, it is targeted for artful. Would that make it into 17.04 as well?
>

Louis,

Can you please comment on the above query also? Can we have the fix applied to 17.04 as well (more so because that was the original milestone for this bug)?

Thanks.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2018-02-19 20:11 EDT-------
Confirmed fixed in 17.10. Since 17.04 isn't supported anymore, closing bug.