Ubuntu
makedumpfile package

Ubuntu 16.10: kdump is not working in 4.8 kernel.

  1. Trusty (14.04)
  2. Bug #1626269
Bug #1626269 reported by bugproxy
16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
makedumpfile (Ubuntu)
Fix Released
Medium
Taco Screen team
Trusty
Confirmed
Medium
Unassigned
Xenial
Fix Released
Medium
Unassigned
Yakkety
Fix Released
Medium
Taco Screen team

Bug Description

[SRU justification]
makedumpfile fails to execute if executed on a 4.8 kernel

[Impact]
Unable to generate compressed kernel dumps on those platform

[Fix]
Backport commits 2c21d4656e8d3c2af2b1e14809d076941ae69e96 and
0c9dd01d8ee2e4ec1821a11f5e174fdba56012b8.

The second commit is required since, once the initial issue is fixed, it triggers a second issue fixed on Debian by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842019

[Test Case]
- Install kernel 4.8 along with the linux-crashdump metapackage
- Reboot to enable kdump
- Trigger a kernel panic with "echo c > /proc/sysrq-trigger"

Without the patch, the following message will appear and makedumpfile will fail :

 get_mem_map: Can't distinguish the memory type.

With the fix, makedumpfile completes correctly.

[Regression]
None expected. The modification keeps the initial structure when kernels before 4.8 are used.

[Original description of the problem]

== Comment: #0 - PAVITHRA R. PRAKASH - 2016-09-21 00:50:22 ==
---Problem Description---

Ubuntu 16.10: kdump is not working in 4.8 kernel.

---Steps to Reproduce---

1) apt-get install linux-crashdump
2) increase crashdump size:
sudo vim /etc/default/grub.d/kexec-tools.cfg

GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M"

3) sudo update-grub ; reboot the machine
4) sudo sed -i 's/USE_KDUMP=0/USE_KDUMP=1/g' /etc/default/kdump-tools
5) kdump-config show
6) echo "c" > /proc/sysrq-trigger

Logs
====

root@ubuntu:/home/ubuntu# uname -a
Linux ubuntu 4.8.0-11-generic #12-Ubuntu SMP Sat Sep 17 19:58:16 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux

root@ubuntu:/home/ubuntu# kdump-config show
DUMP_MODE: kdump
USE_KDUMP: 1
KDUMP_SYSCTL: kernel.panic_on_oops=1
KDUMP_COREDIR: /var/crash
crashkernel addr:
   /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.8.0-11-generic
kdump initrd:
   /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.8.0-11-generic
current state: ready to kdump

kexec command:
  /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinux-4.8.0-11-generic root=UUID=7ea3831b-f4c3-4f69-8f77-79aefcda70e3 ro splash quiet irqpoll nr_cpus=1 nousb systemd.unit=kdump-tools.service" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
root@ubuntu:/home/ubuntu# cd
root@ubuntu:~# echo "c" > /proc/sysrq-trigger
[ 50.733424] sysrq: SysRq : Trigger a crash
[ 50.733437] Unable to handle kernel paging request for data at address 0x00000000
[ 50.733441] Faulting instruction address: 0xc0000000005af3f4
[ 50.733444] Oops: Kernel access of bad area, sig: 11 [#1]
[ 50.733446] SMP NR_CPUS=2048 NUMA pSeries
[ 50.733450] Modules linked in: rpadlpar_io rpaphp dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag pseries_rng sg rng_core binfmt_misc ghash_generic gf128mul vmx_crypto ip_tables x_tables autofs4 ext4 crc16 jbd2 fscrypto mbcache sr_mod cdrom sd_mod bnx2x ibmvscsi ibmveth scsi_transport_srp ptp pps_core mdio libcrc32c crc32c_generic crc32c_vpmsum
[ 50.733477] CPU: 2 PID: 1517 Comm: bash Not tainted 4.8.0-11-generic #12-Ubuntu
[ 50.733480] task: c0000004f7906880 task.stack: c0000004f7898000
[ 50.733482] NIP: c0000000005af3f4 LR: c0000000005b04d8 CTR: c0000000005af3c0
[ 50.733485] REGS: c0000004f789b990 TRAP: 0300 Not tainted (4.8.0-11-generic)
[ 50.733488] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28242422 XER: 00000001
[ 50.733496] CFAR: c0000000000087d0 DAR: 0000000000000000 DSISR: 42000000 SOFTE: 1
GPR00: c0000000005b04d8 c0000004f789bc10 c000000000f46700 0000000000000063
GPR04: c0000005ef78a9b8 c0000005ef79f7d8 c00000063fe82300 0000000000005970
GPR08: 0000000000000007 0000000000000001 0000000000000000 0000000000000001
GPR12: c0000000005af3c0 c000000007b31200 ffffffffffffffff 0000000022000000
GPR16: 0000000010170dc8 00000100111c0538 0000000010140f58 00000000100c7570
GPR20: 0000000000000000 000000001017dd58 0000000010153618 000000001017b608
GPR24: 00003ffff10b9624 0000000000000001 c000000000e9fd40 0000000000000004
GPR28: c000000000ea0100 0000000000000063 c000000000e528e8 0000000000000000
[ 50.733536] NIP [c0000000005af3f4] sysrq_handle_crash+0x34/0x50
[ 50.733539] LR [c0000000005b04d8] __handle_sysrq+0xe8/0x280
[ 50.733541] Call Trace:
[ 50.733544] [c0000004f789bc10] [c0000000009ff9e8] 0xc0000000009ff9e8 (unreliable)
[ 50.733548] [c0000004f789bc30] [c0000000005b04d8] __handle_sysrq+0xe8/0x280
[ 50.733552] [c0000004f789bcd0] [c0000000005b0c88] write_sysrq_trigger+0x78/0xa0
[ 50.733556] [c0000004f789bd00] [c0000000003a9a90] proc_reg_write+0xb0/0x110
[ 50.733560] [c0000004f789bd50] [c00000000030c27c] __vfs_write+0x6c/0xe0
[ 50.733564] [c0000004f789bd90] [c00000000030d784] vfs_write+0xd4/0x240
[ 50.733567] [c0000004f789bde0] [c00000000030f49c] SyS_write+0x6c/0x110
[ 50.733571] [c0000004f789be30] [c0000000000095e0] system_call+0x38/0x108
[ 50.733574] Instruction dump:
[ 50.733576] 38427340 7c0802a6 f8010010 f821ffe1 60000000 60000000 3d220019 3949cde0
[ 50.733582] 39200001 912a0000 7c0004ac 39400000 <992a0000> 38210020 e8010010 7c0803a6
[ 50.733589] ---[ end trace f58d72cacaada0df ]---
[ 50.735307]
[ 50.735313] Sending IPI to other CPUs
[ 50.736336] IPI complete
I'm in purgatory
 -> smp_release_cpus()
spinning_secondaries = 8
 <- smp_release_cpus()
[ 7.250999] sd 0:0:1:0: [sda] Assuming drive cache: write through
/dev/sda2: recovering journal
/dev/sda2: clean, 139510/1884160 files, 1253112/7531008 blocks
[ 8.263985] EXT4-fs (sda2): Cannot load crc32c driver.
mount: mounting /dev/sda2 on /root failed: No such file or directory
mount: mounting /dev on /root/dev failed: No such file or directory
mount: mounting /run on /root/run failed: No such file or directory
run-init: current directory on the same filesystem as the root: error 0
Target filesystem doesn't have requested /sbin/init.
run-init: current directory on the same filesystem as the root: error 0
run-init: current directory on the same filesystem as the root: error 0
run-init: current directory on the same filesystem as the root: error 0
run-init: current directory on the same filesystem as the root: error 0
run-init: current directory on the same filesystem as the root: error 0
No init found. Try passing init= bootarg.

BusyBox v1.22.1 (Ubuntu 1:1.22.0-19ubuntu2) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)
(initramfs)
(initramfs)
(initramfs) exit
mount: mounting /sys on /root/sys failed: No such file or directory
mount: mounting /proc on /root/proc failed: No such file or directory
/init: line 338: can't open /root/dev/console: no such file
[ 381.386973] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000200
[ 381.386973]
[ 381.386980] CPU: 0 PID: 1 Comm: init Not tainted 4.8.0-11-generic #12-Ubuntu
[ 381.386983] Call Trace:
[ 381.386988] [c000000026513c20] [c00000000888bb9c] dump_stack+0xb0/0xf0 (unreliable)
[ 381.386993] [c000000026513c60] [c00000000888832c] panic+0x144/0x308
[ 381.386997] [c000000026513cf0] [c0000000080ce298] do_exit+0xd08/0xd10
[ 381.387001] [c000000026513dc0] [c0000000080ce384] do_group_exit+0x64/0x100
[ 381.387005] [c000000026513e00] [c0000000080ce44c] SyS_exit_group+0x2c/0x30
[ 381.387008] [c000000026513e30] [c0000000080095e0] system_call+0x38/0x108
[ 381.390557] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000200
[ 381.390557]

== Comment: #5 - Kevin W. Rudd - 2016-09-21 16:26:35 ==
This appears to be similar to the issue noted in the following discussion:

https://lists.debian.org/debian-kernel/2016/04/msg00013.html

(from the kdump dmesg info attached):

[ 9.115577] call_modprobe: crypto-crc32c 2
[ 9.116170] call_modprobe: crypto-crc32c-all 2
[ 9.116709] EXT4-fs (sda2): Cannot load crc32c driver.

Forcing the crc32c module by adding it to /etc/initramfs-tools/modules got me past the initial EXT4-fs failure, but kdump then ran into a regression with makedumpfile:

[ 12.331294] kdump-tools[1546]: Starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/201609211609/dump-incomplete
[ 12.391902] kdump-tools[1546]: get_mem_map: Can't distinguish the memory type.
[ 12.392406] kdump-tools[1546]: The kernel version is not supported.
[ 12.392715] kdump-tools[1546]: The makedumpfile operation may be incomplete.
[ 12.392997] kdump-tools[1546]: makedumpfile Failed.
[ 12.393309] kdump-tools[1546]: * kdump-tools: makedumpfile failed, falling back to 'cp'

See original description
Revision history for this message
bugproxy (bugproxy) wrote : Sosreport after reboot

Default Comment by Bridge

tags: added: architecture-ppc64le bugnameltc-146571 severity-critical targetmilestone-inin---
Revision history for this message
bugproxy (bugproxy) wrote : dmesg from the initramfs shell

Default Comment by Bridge

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1626269/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

bugproxy (bugproxy)
Changed in ubuntu:
assignee: nobody → Taco Screen team (taco-screen-team)
Ubuntu Foundations Team Bug Bot (crichton)
tags: added: bot-comment
bugproxy (bugproxy)
affects: ubuntu → makedumpfile (Ubuntu)
Revision history for this message
Louis Bouchard (louis) wrote :

Hello,

I can confirm the issue with makedumpfile on amd64. However, the crc32c module issue does not appear on amd64 and the module is indeed present in the smaller initrd created for kdump (present in /var/lib/kdump/initrd.img-4.8.0-11-generic).

I will investigate the makedumpfile issue with 4.8 kernels.

Changed in makedumpfile (Ubuntu Yakkety):
status: New → Confirmed
importance: Undecided → High
Changed in makedumpfile (Ubuntu Xenial):
assignee: nobody → Louis Bouchard (louis-bouchard)
Changed in makedumpfile (Ubuntu Trusty):
assignee: nobody → Louis Bouchard (louis-bouchard)
Stefan Bader (smb)
tags: added: kernel-4.8
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2016-09-22 09:12 EDT-------
Hi Louis.

We are getting other bug reports against the missing crc32c module for ppc64le. Would it be better to open up a different LP for that specific issue to keep the missing module and makedumpfile issues separate?

Revision history for this message
Louis Bouchard (louis) wrote :

Hello,

This crc32 issue has been identified on s390x and resolved in the following bug :

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1625728

I'm checking if it will also apply to ppc64el and will comment back

Revision history for this message
Louis Bouchard (louis) wrote :

<email address hidden>, could you please test with the latest kernel package in yakkety-proposed ? The fix for the crc32 issue in the bug cited earlier is in that package.

The kernel version is 4.8.0-15.16.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2016-09-23 13:47 EDT-------
We are still seeing the crc32c issue with the 4.8.0-15, so I mirrored over a related bug to keep the two issues separate. The crc32c issue is being tracked in Bug 146645 / LP Bug 1627126

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2016-09-24 08:25 EDT-------
Dump filtering for kernels v4.7+ is failing because of kernel commit 0139aa7b7fa1
which changed _count to _refcount in struct page. The below makedumpfile tool
commit fixes this:

commit 2c21d4656e8d3c2af2b1e14809d076941ae69e96
Author: Vitaly Kuznetsov <email address hidden>
Date: Fri Jun 17 18:41:26 2016 +0900

[PATCH v2] Support _count -> _refcount rename in struct page
_count member was renamed to _refcount in linux commit 0139aa7b7fa12
("mm: rename _count, field of the struct page, to _refcount") and this
broke makedumpfile. The reason for making the change was to find all users
accessing it directly and not through the recommended API. I tried
suggesting to revert the change but failed, I see no other choice than to
start supporting both _count and _refcount in makedumpfile.
Signed-off-by: Vitaly Kuznetsov <email address hidden>
--

Makedumpfile filtered dump successfully when the above commit is applied on top
of makedumpfile_1.6.0-2

# ./makedumpfile -l -d 31 /var/crash/201609230347/vmcore.201609230347 dump
The kernel version is not supported.
The makedumpfile operation may be incomplete.
Copying data : [100.0 %] /

The dumpfile is saved to dump.

makedumpfile Completed.
#
--

Thanks
Hari

Revision history for this message
Louis Bouchard (louis) wrote : Re: [Bug 1626269] [NEW] Ubuntu 16.10: kdump is not working in 4.8 kernel.

Hello,

Le 21/09/2016 22:42, Launchpad Bug Tracker a écrit :
> You have been subscribed to a public bug:
>
> == Comment: #0 - PAVITHRA R. PRAKASH - 2016-09-21 00:50:22 ==
> ---Problem Description---
>
> Ubuntu 16.10: kdump is not working in 4.8 kernel.
>
> ---Steps to Reproduce---
>
> 1) apt-get install linux-crashdump
> 2) increase crashdump size:
> sudo vim /etc/default/grub.d/kexec-tools.cfg
>
> GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=2G-
> 4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M"
>
> 3) sudo update-grub ; reboot the machine
> 4) sudo sed -i 's/USE_KDUMP=0/USE_KDUMP=1/g' /etc/default/kdump-tools
> 5) kdump-config show
> 6) echo "c" > /proc/sysrq-trigger
>

The Launchpad site having difficulties, I don't know if the email bridge will be
sufficient to reach you.

The kernel team has asked to see if you could test the kernel in the following PPA :

  ppa:canonical-kernel-team/unstable

The kernel version is 4.8.0-17.19 and it is the kernel which may potentially
make it to the image. So if you can verify if the crc32c issue is present or not
on the ppc64el, this would be very helpful.

Kind regards,

...Louis

--
Louis Bouchard
Software engineer, Cloud & Sustaining eng.
Canonical Ltd
Ubuntu developer Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63 B9C4 8B3D 867C 823E 7A61

Revision history for this message
Louis Bouchard (louis) wrote :

Hello,

Yes I have found that and included it into the upcoming makedumpfile package. But there are more issues wollowing the addition of this commit that I need to identify and fix.

http://lists.infradead.org/pipermail/kexec/2016-September/017300.html

bugproxy (bugproxy)
tags: added: targetmilestone-inin1610
removed: targetmilestone-inin---
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2016-09-28 02:21 EDT-------
Hi,

Tested with "4.8.0-17-generic" kernel. After crash machine did not hang and 7.6G vmcore got captured.
but dmesg.201609270619 is not generated.

Logs
===
root@ubuntu:/var/crash/201609270619# uname -a
Linux ubuntu 4.8.0-17-generic #19-Ubuntu SMP Sun Sep 25 06:35:40 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux

root@ubuntu:/var/crash/201609270619# ls -lhrt
total 2.0G
-r-------- 1 root root 7.6G Sep 27 06:20 vmcore.201609270619

# makedumpfile -l -d 31 /var/crash/201609270619/vmcore.201609270619 dump1
The kernel version is not supported.
The makedumpfile operation may be incomplete.
get_mem_map: Can't distinguish the memory type.

makedumpfile Failed.

With given makedump file
----------------------------
# ./makedumpfile -l -d 31 /var/crash/201609270619/vmcore.201609270619 dump1
The kernel version is not supported.
The makedumpfile operation may be incomplete.
Copying data : [100.0 %] -

The dumpfile is saved to dump1.

makedumpfile Completed.

Revision history for this message
bugproxy (bugproxy) wrote : Sosreport after reboot

Default Comment by Bridge

Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2016-10-19 14:44 EDT-------
(In reply to comment #19)
> Hello,
>
> Yes I have found that and included it into the upcoming makedumpfile
> package. But there are more issues wollowing the addition of this commit
> that I need to identify and fix.
>
> http://lists.infradead.org/pipermail/kexec/2016-September/017300.html

Hi Louis,

Any ETA for the updated makedumpfile package with fix
commit 2c21d4656e8d3c2af2b1e14809d076941ae69e96

Thanks
Hari

Revision history for this message
Louis Bouchard (louis) wrote :

Hello,

Not at the moment : simply adding this commit allow makedumpfile to run but it generates many other error messages that are currently investigated. There is an incompatibility between makedumpfile and 4.8 kernels that make the result of makedumpfile unreliable.

I am currently working with upstream on identifying and fixing the issue.

Kind regards,
Louis

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2016-10-20 15:21 EDT-------
(In reply to comment #38)
>
> Hello,

Hello Loius,

>
> Not at the moment : simply adding this commit allow makedumpfile to run but
> it generates many other error messages that are currently investigated.

I couldn't reproduce it on powerpc. I tried on Ubuntu's 4.8.0-15 & 4.8.0-22 kernels.
Maybe arch specific - in which case, it would be good to get an update for
makedumpfile package with this fix first?

Thanks
Hari

Revision history for this message
bugproxy (bugproxy) wrote : Sosreport after reboot

Default Comment by Bridge

Revision history for this message
bugproxy (bugproxy) wrote : dmesg from the initramfs shell

Default Comment by Bridge

Revision history for this message
Louis Bouchard (louis) wrote :

Hello,

Here is an update on the situation.

I completed a kernel bisection between 4.7.8 and 4.8-rc1 (15 kernel builds) and identified the kernel commit that causes the problem :

commit 021182e52fe01c1f7b126f97fd6ba048dc4234fd
Author: Thomas Garnier <email address hidden>
Date: Tue Jun 21 17:47:03 2016 -0700

    x86/mm: Enable KASLR for physical mapping memory regions

    Add the physical mapping in the list of randomized memory regions.

    The physical memory mapping holds most allocations from boot and heap
    allocators. Knowing the base address and physical memory size, an attacker
    can deduce the PDE virtual address for the vDSO memory page. This attack
    was demonstrated at CanSecWest 2016, in the following presentation:

      "Getting Physical: Extreme Abuse of Intel Based Paged Systems":
      https://github.com/n3k/CansecWest2016_Getting_Physical_Extreme_Abuse_of_Intel_Based_Paging_Systems/blob/master/Presentation/CanSec2016_Presentation.pdf

    (See second part of the presentation).

    The exploits used against Linux worked successfully against 4.6+ but
    fail with KASLR memory enabled:

      https://github.com/n3k/CansecWest2016_Getting_Physical_Extreme_Abuse_of_Intel_Based_Paging_Systems/tree/master/Demos/Linux/exploits

    Similar research was done at Google leading to this patch proposal.

    Variants exists to overwrite /proc or /sys objects ACLs leading to
    elevation of privileges. These variants were tested against 4.6+.

    The page offset used by the compressed kernel retains the static value
    since it is not yet randomized during this boot stage.

    Signed-off-by: Thomas Garnier <email address hidden>
    Signed-off-by: Kees Cook <email address hidden>

As you can see, this modification is specific to the x86 architecture which is why you don't see the issue.

In parallel to that, a patch to fix this situation has been published yesterday to the makedumpfile mailing list and is currently under review by the main developper :

 https://<email address hidden>/msg16628.html

There is a debian bug opened for this issue :
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842019

While I understand your concern, I cannot push a modification that will trigger makedumpfile to generate dozen of error messages and a potentially unusable vmcore to all of the x86 world in order to satisfy only one architecture.

It is important to remember that, while makedumpfile fails, the kernel dump capture mechanism reverts to using 'cp' to copy /proc/vmcore uncompressed so this vmcore file is still usable for analysis.

Hopefully, we should get an ACK for the upstream bug soon, so I can push a new package to Debian. I will then proceed with the synchronization to Zesty and SRU to the other stable releases.

I hope that this clarifies the situation.

Kind regards

Changed in makedumpfile (Ubuntu):
status: Confirmed → In Progress
importance: High → Medium
Changed in makedumpfile (Ubuntu Yakkety):
importance: High → Medium
Changed in makedumpfile (Ubuntu Trusty):
status: New → Confirmed
Changed in makedumpfile (Ubuntu Xenial):
status: New → Confirmed
Changed in makedumpfile (Ubuntu Trusty):
importance: Undecided → Medium
Changed in makedumpfile (Ubuntu Xenial):
importance: Undecided → Medium
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2016-10-27 02:54 EDT-------
(In reply to comment #42)
> Hopefully, we should get an ACK for the upstream bug soon, so I can push a
> new package to Debian. I will then proceed with the synchronization to Zesty
> and SRU to the other stable releases.
>
> I hope that this clarifies the situation.
>

Thanks for clarifying that, Louis.
That does help in appreciating the situation..

Regards,
Hari

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2016-11-06 22:53 EDT-------
*** Bug 147804 has been marked as a duplicate of this bug. ***

Louis Bouchard (louis)
Changed in makedumpfile (Ubuntu):
status: In Progress → Fix Released
Changed in makedumpfile (Ubuntu Yakkety):
status: Confirmed → In Progress
Changed in makedumpfile (Ubuntu Xenial):
status: Confirmed → In Progress
Revision history for this message
Louis Bouchard (louis) wrote :

Hello,

The fix for this issue has been uploaded for Xenial and Yakkety and is awaiting SRU approval.

description: updated
Revision history for this message
Timo Aaltonen (tjaalton) wrote : Please test proposed package

Hello bugproxy, or anyone else affected,

Accepted makedumpfile into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/makedumpfile/1:1.6.0-2ubuntu1.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in makedumpfile (Ubuntu Yakkety):
status: In Progress → Fix Committed
tags: added: verification-needed
Changed in makedumpfile (Ubuntu Xenial):
status: In Progress → Fix Committed
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Hello bugproxy, or anyone else affected,

Accepted makedumpfile into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/makedumpfile/1:1.5.9-5ubuntu0.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2016-11-28 18:59 EDT-------
Version 1:1.5.9-5ubuntu0.3 validated for Xenial.

tags: added: verification-done-xenial verification-needed-yakkety
removed: verification-needed
Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2016-11-29 12:26 EDT-------
Version 1:1.6.0-2ubuntu1.2 validated for yakkety

tags: added: verification-done-yakkety
removed: verification-needed-yakkety
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package makedumpfile - 1:1.5.9-5ubuntu0.3

---------------
makedumpfile (1:1.5.9-5ubuntu0.3) xenial; urgency=medium

  * d/p/0003-PATCH-v2-Support-_count-_refcount-rename-in-struct-p.patch,
    d/p/0004-fix-readpage_elf-attempt-to-read-non-existent-page.patch
    Fix makedumpfile failure on 4.8 kernels.
     - Makedumpfile will exit on error with the following message :
       get_mem_map: Can't distinguish the memory type. (LP: #1626269)
     - Fix readpage_elf: Attempt to read non-existent page errors after
       previous patch is applied

  [ Rinat ]
  * Fix double-quote handling in /proc/cmdline
    Parsing of the cmdline would fail if double-quotes are encountered
    in /proc/cmdine (i.e. like when things like "acpi_osi=!Windows 2012"
    are found in the cmdline). (LP: #1644771)

  * Fix spelling error in debian/control

 -- Chris J Arges <email address hidden> Wed, 19 Oct 2016 07:41:36 -0500

Changed in makedumpfile (Ubuntu Xenial):
status: Fix Committed → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote : Update Released

The verification of the Stable Release Update for makedumpfile has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package makedumpfile - 1:1.6.0-2ubuntu1.2

---------------
makedumpfile (1:1.6.0-2ubuntu1.2) yakkety; urgency=medium

  * d/p/0003-PATCH-v2-Support-_count-_refcount-rename-in-struct-p.patch,
    d/p/0004-fix-readpage_elf-attempt-to-read-non-existent-page.patch
    Fix makedumpfile failure on 4.8 kernels.
     - Makedumpfile will exit on error with the following message :
       get_mem_map: Can't distinguish the memory type. (LP: #1626269)
     - Fix readpage_elf: Attempt to read non-existent page errors after
       previous patch is applied

  [ Rinat ]
  * Fix double-quote handling in /proc/cmdline
    Parsing of the cmdline would fail if double-quotes are encountered
    in /proc/cmdine (i.e. like when things like "acpi_osi=!Windows 2012"
    are found in the cmdline). (LP: #1644771)

  * Fix spelling error in debian/control

 -- Louis Bouchard <email address hidden> Thu, 10 Nov 2016 16:46:39 +0100

Changed in makedumpfile (Ubuntu Yakkety):
status: Fix Committed → Fix Released
Louis Bouchard (louis)
Changed in makedumpfile (Ubuntu Xenial):
assignee: Louis Bouchard (louis) → nobody
Changed in makedumpfile (Ubuntu Trusty):
assignee: Louis Bouchard (louis) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.