[Crash-utility] compiling statically?
J Freyensee
james_p_freyensee at linux.intel.com
Thu Aug 25 18:33:46 UTC 2016
On Thu, 2016-08-25 at 14:20 -0400, Dave Anderson wrote:
>
> ----- Original Message -----
> >
> > On Thu, 2016-08-25 at 13:41 -0400, Dave Anderson wrote:
> > >
> > >
> > > ----- Original Message -----
> > > >
> > > >
> > > > On Thu, 2016-08-25 at 09:45 -0700, J Freyensee wrote:
> > > > >
> > > > >
> > > > > On Wed, 2016-08-24 at 20:30 -0400, Dave Anderson wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, 2016-08-24 at 15:00 -0400, Dave Anderson wrote:
> > > > > > >
> > > > > > > That's not a problem -- crash just needs to be compiled
> > > > > > > with
> > > > > > > "make
> > > > > > > lzo",
> > > > > > > which will add these lines to the CFLAGS.extra and
> > > > > > > LDFLAGS.extra
> > > > > > > files:
> > > > > > >
> > > > > > > -DLZO in the CFLAGS.extra file
> > > > > > > -llzo2 in the LDFLAGS.extra file
> > > > > > >
> > > > > > > and will delete diskdump.o. The subsequent rebuild will
> > > > > > > recompile
> > > > > > > diskdump.c with lzo compression support. You only have
> > > > > > > to
> > > > > > > enter
> > > > > > > "make lzo" once, as it's effect is sticky.
> > > > >
> > > > > Thanks, this helped.
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > This also requires the lzo, lzo-minilzo and lzo-devel
> > > > > > > packages to
> > > > > > > be installed so that the lzo compression library can get
> > > > > > > compiled
> > > > > > > in.
> > > > > > > But in your case, you would need to have the static
> > > > > > > versions
> > > > > > > of
> > > > > > > the
> > > > > > > lzo and lzo-minilzo packages.
> > > > > >
> > > > > > Although -- unlike the zlib package which has a zlib-static
> > > > > > rpm
> > > > > > --
> > > > > > the
> > > > > > Red Hat lzo package set does not include static versions of
> > > > > > the
> > > > > > lzo
> > > > > > and
> > > > > > lzo-minilzo libraries. So I don't know how you can get
> > > > > > around
> > > > > > that.
> > > > > >
> > > > >
> > > > > I got around the liblzo2.a issue by just building from the
> > > > > sources:
> > > > >
> > > > > mkdir lzo2_temp
> > > > > cd lzo2_temp/
> > > > > yumdownloader --source lzo-devel
> > > > > pm2cpio lzo-2.08-8.fc24.src.rpm | cpio -idv
> > > > > tar xf lzo-2.08.tar.gz
> > > > > cd lzo-2.08/
> > > > > run ./configure if need-be
> > > > > make liblzo2.a
> > > > >
> > > > > Looks like all I need is liblzo2.a. Seems like a simple
> > > > > thing
> > > > > for
> > > > > the
> > > > > .rpm package to include since it's already been designed into
> > > > > the
> > > > > Makefile in the src.rpm.
> > > > >
> > > > > Anyways, I think I may have it working now, despite the same
> > > > > compiler
> > > > > warnings I mentioned at the beginning??:
> > > > >
> > > > > [~]$ ./crash src/linux/vmlinux crash.dump
> > > > >
> > > > > crash 7.1.5
> > > > > Copyright (C) 2002-2016 Red Hat, Inc.
> > > > > Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
> > > > > Copyright (C) 1999-2006 Hewlett-Packard Co
> > > > > Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
> > > > > Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
> > > > > Copyright (C) 2005, 2011 NEC Corporation
> > > > > Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
> > > > > Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux,
> > > > > Inc.
> > > > > This program is free software, covered by the GNU General
> > > > > Public
> > > > > License,
> > > > > and you are welcome to change it and/or distribute copies of
> > > > > it
> > > > > under
> > > > > certain conditions. Enter "help copying" to see the
> > > > > conditions.
> > > > > This program has absolutely no warranty. Enter "help
> > > > > warranty"
> > > > > for
> > > > > details.
> > > > >
> > > > > GNU gdb (GDB) 7.6
> > > > > Copyright (C) 2013 Free Software Foundation, Inc.
> > > > > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/li
> > > > > cens
> > > > > es/g
> > > > > pl
> > > > > .html>
> > > > > This is free software: you are free to change and
> > > > > redistribute
> > > > > it.
> > > > > There is NO WARRANTY, to the extent permitted by law. Type
> > > > > "show
> > > > > copying"
> > > > > and "show warranty" for details.
> > > > > This GDB was configured as "x86_64-unknown-linux-gnu"...
> > > > >
> > > > > crash: failed to read pageflag_names entry
> > > > > KERNEL: src/linux/vmlinux
> > > > > DUMPFILE: crash.dump [PARTIAL DUMP]
> > > > > CPUS: 8
> > > > > DATE: Tue Aug 23 15:12:26 2016
> > > > > UPTIME: 00:04:26
> > > > > LOAD AVERAGE: 0.20, 0.29, 0.13
> > > > > TASKS: 300
> > > > > NODENAME: nvmf-host03.jf.intel.com
> > > > > RELEASE: 4.8.0-rc3
> > > > > VERSION: #1 SMP Tue Aug 23 12:22:39 PDT 2016
> > > > > MACHINE: x86_64 (3600 Mhz)
> > > > > MEMORY: 7.8 GB
> > > > > PANIC: "sysrq: SysRq : Trigger a crash"
> > > > > PID: 10568
> > > > > COMMAND: "bash"
> > > > > TASK: ffff880282a58080 [THREAD_INFO:
> > > > > ffff88026c5e8000]
> > > > > CPU: 3
> > > > > STATE: TASK_RUNNING (SYSRQ)
> > > > > crash>
> > > > >
> > > > >
> > > >
> > > > If this looks right/reasonable, I captured all the steps here.
> > > > If
> > > > I
> > > > captured that correctly, i could submit a patch to README on
> > > > how to
> > > > do
> > > > this statically?:
> > >
> > > To be honest, I really don't want to publish it in the package
> > > because
> > > then I would be on the hook for supporting it, which I am
> > > definitely
> > > not
> > > interested in. (Not to mention that I couldn't even get it to
> > > build).
> > > And I don't recall anyone ever asking for it until you did. I'm
> > > curious
> > > as to why you can't easily run the crash session on a host where
> > > you
> > > could build it normally?
> >
> > The reason why is there is a break in kdump via 'makedumpfile' in
> > which
> > it broke for at least the 4.5 kernel on up (if not older). So
> > someone
> > wanting to produce a kernel crash file for say, the 4.8-rc3 kernel
> > won't be able to do it if their kdump.conf is setup to use
> > 'makedumpfile'.
> >
> > On top of that, there is a problem in older versions of crash which
> > you
> > will get this error:
> >
> > WARNING: kernels compiled by different gcc versions:
> > src/linux/vmlinux: (unknown)
> > crash.dump kernel: 4.8.2
> >
> > WARNING: kernel version inconsistency between vmlinux and dumpfile
> >
> > crash: incompatible arguments:
> > src/linux/vmlinux is not SMP -- crash.dump is SMP
> >
> > which is fixed starting in crash 7.1.4.
>
> Right, that kind of thing happens all of the time, both with
> makedumpfile
> and the crash utility. When you're dealing with a moving target,
> there's
> nothing you can do about it except continually update them. But I
> don't
> see what that has to do with making them statically compiled?
>
Well, what is interesting is 'makedumpfile's default build is actually
STATIC build. So by default, the maintainer has made it static.
> >
> >
> > As part of my role to develop Linux features for future customer
> > products,
> > if a customer has: *bleeding edge HW my dept provided as early
> > enablement
> > and *wants to use something just released in mainline via
> > kernel.org and
> > *a bug occurred that crashed the kernel and *we want some crash
> > file to
> > try and understand what is going on,
> >
> > there currently isn't any other alternative other than to provide a
> > compiled makedumpfile solution and crash solution. And the easiest
> > way
> > to deliver a solution to remote customers without intimately
> > understanding what all is installed on their computer setups is to
> > provide statically compiled exe's because then I know exactly what
> > they
> > have and I can test and use the exact same solution.
>
> Why can't you have the customer send the vmcore to you?
There is not vmcore to send without 'makedumpfile' fix. That is 1/2
the problem.
> Or are they
> doing their own analysis?
The could be, that is why I provided a crash exe that works with the
'makedumpfile' patch fix. But maybe a co-worker is on site which I'm
helping him, thus, again delivering a static compile of 'crash' that
works with the statically-built-by-default patched-up 'makedumpfile'.
In general I've always found static compiles very useful in quick work-
arounds and giving support independent of their Linux distro
environment.
> If so, why can't they set up an environment
> where they can be built normally?
> For example, have them buy a $200
> laptop, install some mainstream Linux, and do it there?
> It just seems
> that the hoops being jumped could easily be avoided, but obviously
> I'm
> not understanding the scenario.
Not understanding that, but when you are trying to win a customer's
business with a new potential product, you are willing to jump through
a couple of hoops that really aren't that bad ;-).
>
> But anyway, you've done a good job at least getting something up and
> running.
Thanks, you helped :-).
>
> Dave
>
>
> >
> > >
> > >
> > > That being the case, there will always be this discussion that I
> > > could
> > > point to for anybody in the future who might be interested.
> > >
> > > Dave
> > >
> > >
> > >
> > >
> > > >
> > > >
> > > >
> > > > -----------------
> > > >
> > > > Building 'crash' statically (w/lzo2 support)
> > > > ============================================
> > > >
> > > > To attempt to build 'crash' statically with pretty common lzo2
> > > > support
> > > > (used by 'makedumpfile'), the static library liblzo2.a is
> > > > needed. However, this is not available in Fedora 24 .rpm
> > > > packages
> > > > :-(.
> > > >
> > > > To build it yourself, try:
> > > >
> > > > mkdir lzo2_temp
> > > > cd lzo2_temp/
> > > > yumdownloader --source lzo-devel
> > > > pm2cpio lzo-2.08-8.fc24.src.rpm | cpio -idv
> > > > tar xf lzo-2.08.tar.gz
> > > > cd lzo-2.08/
> > > > run ./configure if need-be
> > > > make liblzo2.a
> > > >
> > > > Then after downloading the crash repo:
> > > > https://github.com/crash-utility/crash.git
> > > >
> > > > Specify to build it statically in the crash/ directory by
> > > > creating
> > > > a
> > > > file called LDFLAGS.extra with a couple of static flags:
> > > >
> > > > $ cat LDFLAGS.extra
> > > > -static -static-libgcc
> > > >
> > > > and in crash/gdb-X.Y/Makefile at TOPLEVEL_CONFIGURE_ARGUMENTS
> > > > variable
> > > > add:
> > > >
> > > > --enable-static=yes
> > > >
> > > > (example:
> > > > # The gcc driver likes to know the arguments it was configured
> > > > with.
> > > > TOPLEVEL_CONFIGURE_ARGUMENTS=./configure --with-separate-debug-
> > > > dir=/usr/lib/debug --with-bugurl= --with-expat=no --with-
> > > > python=no
> > > > --
> > > > disable-sim --enable-static=yes)
> > > >
> > > > and back in the top crash/ directory build
> > > > the whole thing with the lzo2 library:
> > > >
> > > > $ make lzo
> > > >
> > > > (adds to LDFLAGS.extra and creates CFLAGS.extra)
> > > >
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Dave
> > > > > >
> > > > > > --
> > > > > > Crash-utility mailing list
> > > > > > Crash-utility at redhat.com
> > > > > > https://www.redhat.com/mailman/listinfo/crash-utility
> > > > >
> > > > > --
> > > > > Crash-utility mailing list
> > > > > Crash-utility at redhat.com
> > > > > https://www.redhat.com/mailman/listinfo/crash-utility
> > > >
> > > > --
> > > > Crash-utility mailing list
> > > > Crash-utility at redhat.com
> > > > https://www.redhat.com/mailman/listinfo/crash-utility
> > >
> > > --
> > > Crash-utility mailing list
> > > Crash-utility at redhat.com
> > > https://www.redhat.com/mailman/listinfo/crash-utility
> >
> > --
> > Crash-utility mailing list
> > Crash-utility at redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
>
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
More information about the Crash-utility
mailing list