This bug was fixed in the package kexec-tools - 1:2.0.1-1ubuntu5
---
kexec-tools (1:2.0.1-1ubuntu5) lucid-proposed; urgency=low
* Backport changes to fix kdump functionality. LP: #828731.
- debian/kdump.initramfs: call /usr/bin/makedumpfile via a chroot command,
so that
This bug was fixed in the package kexec-tools - 1:2.0.2-1ubuntu4
---
kexec-tools (1:2.0.2-1ubuntu4) oneiric-proposed; urgency=low
* Backport changes to fix kdump functionality. LP: #828731.
- debian/kdump.initramfs: call /usr/bin/makedumpfile via a chroot command,
so that
@clint
I can confirm that the new kexec-tool package does work correctly on
Lucid, though this specific problem with dynamic makedumpfile did not
apply to Lucid.
So no regresssion on this one, everything works fine.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/785425
Title:
0_kdump uses dynamic makedumpfile(8) binary, which fails horribly
Hello Daniel, or anyone else affected,
Accepted kexec-tools into lucid-proposed. The package will build now and
be available in a few hours. Please test and give feedback here. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed. Thank you in
can somebody explain what happened to version 1:2.0.1-1ubuntu4 ? It is
not in lucid-proposed, but is sort of referenced in the upload of
1:2.0.1-1ubuntu5
?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
On Fri, Mar 09, 2012 at 07:09:26PM -, Clint Byrum wrote:
can somebody explain what happened to version 1:2.0.1-1ubuntu4 ? It is
not in lucid-proposed, but is sort of referenced in the upload of
1:2.0.1-1ubuntu5
Was removed from lucid-proposed to avoid accidental promotion given the
Hi Clint,
Le 09/03/2012 20:09, Clint Byrum a écrit :
can somebody explain what happened to version 1:2.0.1-1ubuntu4 ? It is
not in lucid-proposed, but is sort of referenced in the upload of
1:2.0.1-1ubuntu5
?
There was one issue specific to Lucid that made the -proposed version
fail. I
** Branch linked: lp:ubuntu/maverick-proposed/kexec-tools
** Branch linked: lp:ubuntu/lucid-proposed/kexec-tools
** Branch linked: lp:ubuntu/natty-proposed/kexec-tools
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hello Daniel, or anyone else affected,
Accepted kexec-tools into oneiric-proposed. The package will build now
and be available in a few hours. Please test and give feedback here. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed. Thank you in
** Branch linked: lp:ubuntu/oneiric-proposed/kexec-tools
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/785425
Title:
0_kdump uses dynamic makedumpfile(8) binary, which fails horribly
To manage
I see this is fixed with version kexec-tools 1:2.0.2-3ubuntu2. However,
Oneiric is stuck with kexec-tools 1:2.0.2-1ubuntu3. Any chance to have
this package updated?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@666f6f
You might want to have a look at bug LP: #828731 which has the request
for backporting this packages to all previous releases. Hopefully this
should become available soon.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Great, thank you Louis!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/785425
Title:
0_kdump uses dynamic makedumpfile(8) binary, which fails horribly
To manage notifications about this bug go to:
** Description changed:
+ SRU Request for Lucid/Maverick/Natty/Oneiric:
+
+ [Impact] - When a server is configured with the /boot as a separate
+ partition, which is the default configuration when LVM installation is
+ selected, the kdump mechanism fails systematically.
+
+ [Development/Stable
On Tue, Jan 03, 2012 at 09:25:25AM -, Louis Bouchard wrote:
I really wanted to get the whole kexec/kdump functionality working for
12.04 which will be LTS. thanks to Steve for helping me out on this.
Regarding the wording of the changelog, not sure if this can be changed.
Maybe Steve will
@daniel
I really wanted to get the whole kexec/kdump functionality working for
12.04 which will be LTS. thanks to Steve for helping me out on this.
Regarding the wording of the changelog, not sure if this can be changed.
Maybe Steve will want to comment.
--
You received this bug notification
This bug was fixed in the package kexec-tools - 1:2.0.2-3ubuntu2
---
kexec-tools (1:2.0.2-3ubuntu2) precise; urgency=low
* debian/kdump.initramfs: call /usr/bin/makedumpfile via a chroot command,
so that if makedumpfile is statically linked, we get proper library
Excellent! Thank you, Louis, for getting this in.
Just one nit---that should read ... so that if makedumpfile is
*dynamically* linked, we get ...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/785425
On Fri, Dec 02, 2011 at 07:29:50AM -, Louis Bouchard wrote:
Mouting the root filesystem Read/Write is required in order to save the
vmcore information on the root filesystem, which is the sole intent of
this script.
Yes, I understand that. I was referring to the reordering done in your
caribou silently makes note of not commenting before 3rd cup of coffee
in the morning...
You're right, there is no need to have it R/W in order to test existence
of those files. And I missed the panic calls altogether.
So this is officially my first Ubuntu patch :-D
--
You received this bug
@steve
Here is the new patch I've just tested on 32 64 bit Oneiric, which is
close to what you suggested. It does a chroot on makedumpfile and
verifies that the files are present in $rootmnt.
One difference with your exemple is the use of 'mount -n --bind' instead
of using -o move /proc as the
Hi Louis,
+
+log_begin_msg Saving vmcore from kernel crash
+
+mount $rootmnt -o remount,rw
+
# Make sure makedumpfile assumptions are satisfied.
-while ! test -e $INFO; do
+while ! test -e $rootmnt/$INFO; do
panic kdump: Missing $INFO
done
-while ! test -x $MAKEDUMPFILE; do
-
** Branch linked: lp:ubuntu/kexec-tools
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/785425
Title:
0_kdump uses dynamic makedumpfile(8) binary, which fails horribly
To manage notifications about
Hello Steve,
Mouting the root filesystem Read/Write is required in order to save the
vmcore information on the root filesystem, which is the sole intent of
this script.
This is not introduced by the patch, but is present in the original
script (Line 41). And panic is not called anywhere in
@steve
Agree, using chroot in that context makes much more sense simplify the
arch diffs.
I'll test a patch with that in mind shortly will try to post it here.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
On Thu, Nov 24, 2011 at 02:34:56PM -, Louis Bouchard wrote:
As a final note, if choosen, the LD_LIBRARY_PATH option needs to be
adapter to serve each architecture for which this can be used
(i386,x86_64, arm powerpc).
Yes, this is another reason that it would be simpler to mount /proc
@Steve
The reason why chroot is not possible, is that the intent of this script
is to copy the content of /proc/vmcore to the root filesystem. Using a
chroot would make things more complex as part of /proc would need to be
made visible.
Using $rootmnt is also my intent. This was only a quick
@Richard: mostly because makedumpfile can be used in other contexts than
from within the kdump realm. I've seen situation where it was used to
reduce the size of an existing vmcore file.
A longer term solution might also be to go back to one single package
with statically linked executable. I
Sure, the makedumpfile(8) program has other uses, but we're talking
about the dependencies of the linux-crashdump metapackage. There's
really only one usage context that's relevant for that.
I wouldn't suggest dropping the makedumpfile package altogether in favor
of makedumpfile-static, but
We have plenty of dynamically-linked executables in the initramfs
already. I don't see why we shouldn't just fix this one, rather than
introducing more static linkage (which is a maintenance pain). I agree
that there are problems here - dynamic linking just isn't intrinsically
one of them.
--
@cjwatson
thanks for clarifying this for me.
Indeed, when looking in the initramfs context I see this :
(initramfs) . /root/usr/bin/ldd /root/usr/bin/makedumpfile
linux-vdso.so.1 = (0x7fff0f9ff000)
libdw.so.1 = not found
libelf.so.1 = not found
libz.so.1 =
On Wed, Nov 23, 2011 at 01:39:47PM -, Louis Bouchard wrote:
So I've ran a new test by revoking both proposed patches and using the
following syntax in /usr/share/initramfs-tools/scripts/init-
bottom/0_kdump :
--- 0_kdump.orig2011-11-23 14:32:29.113580047 +0100
+++ 0_kdump
The following patch adds a dependency to the linux-crashdump metapackage
so the makedumpfile-static package is also installed.
This dependency is required in order for the previous patch to be
functional.
** Patch added: linux-crashdump_makedumpfile-static_LP785425.patch
The following patch uses the statically linked version of makedumpfile
as provided by the makedumpfile-static package.
The makedumpfile-static package which is currently in the Universe
archive will need to be included into the Main archive as well as its
makedumpfile counterpart.
** Patch
** Changed in: kexec-tools (Ubuntu)
Assignee: Canonical Kernel Team (canonical-kernel-team) = Canonical
Foundations Team (canonical-foundations)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Changed in: kexec-tools (Ubuntu)
Status: New = Triaged
** Changed in: kexec-tools (Ubuntu)
Importance: Undecided = Medium
** Changed in: kexec-tools (Ubuntu)
Assignee: (unassigned) = Canonical Kernel Team (canonical-kernel-team)
--
You received this bug notification because
The attachment kdump.initramfs_makedumpfile_static-LP785425.patch of
this bug report has been identified as being a patch. The ubuntu-
reviewers team has been subscribed to the bug report so that they can
review the patch. In the event that this is in fact not a patch you can
resolve this
On the second patch: Why not drop the makedumpfile package dependency?
No need to install two binaries of the same program, especially when one
of them isn't even fit for purpose.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This bug is still present in Oneiric.
** Attachment added: /var/crash/vmcore.log file produced by kernel crash dump
on Oneiric
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/785425/+attachment/2582481/+files/vmcore.log
--
You received this bug notification because you are a
The root cause for this issue is not related to kexec-tools, but is a
makedumpfile issue.
The upstream version of makedumpfile that was introduced with 11.04
Natty now uses a dynamically linked makedumpfile and set aside the
static version it its own separate package.
I will look to see if
Is your intent to get rid of the makedumpfile and makedumpfile-
static duo, replacing it with a single makedumpfile package
containing a statically-linked binary?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Since it was introduced upstream, it might be a longer route to take.
Right now, I am more inclined to ask for makedumpfile-static to be
included in main, installed by linux-crashdump and add the adequate call
in 0_kdump. But this is not my decision.
--
You received this bug notification
One thing I've been wondering is what purpose the dynamically-linked
makedumpfile(8) is intended to serve. The program only ever runs in a
Linux crash environment, where two kernels are loaded in memory, and
everything is running out of the second kernel's initrd---is the 800kB
difference in the
44 matches
Mail list logo
