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@xxxxxxxxxx > > > > > > https://www.redhat.com/mailman/listinfo/crash-utility > > > > > > > > > > -- > > > > > Crash-utility mailing list > > > > > Crash-utility@xxxxxxxxxx > > > > > https://www.redhat.com/mailman/listinfo/crash-utility > > > > > > > > -- > > > > Crash-utility mailing list > > > > Crash-utility@xxxxxxxxxx > > > > https://www.redhat.com/mailman/listinfo/crash-utility > > > > > > -- > > > Crash-utility mailing list > > > Crash-utility@xxxxxxxxxx > > > https://www.redhat.com/mailman/listinfo/crash-utility > > > > -- > > Crash-utility mailing list > > Crash-utility@xxxxxxxxxx > > https://www.redhat.com/mailman/listinfo/crash-utility > > -- > Crash-utility mailing list > Crash-utility@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/crash-utility -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
